I'm writing a class library on UWP platform that is going to be used from a mobile UWP application.
The library needs to talk with an external device through a proprietary protocol TCP-based. The protocol requires Receive or Send operation to be waited for an exact amount of time.
I've actually implemented the communication layer with ReceiveAsync and SendAsync, "await"ing for them, as the TPL pattern suggets.
After a lot of reading on the argument, I discover there's no way to set natively a timeout on read/write operations. Some tricks can be used to implement the timeout process (es: .WaitAny or timeoutable tokens) but all my readings brings me to this fact:
A ReceiveAsync or SendAsync task can be interrupted only closing the socket
My question is: is this true? A timeout'd Receive/Send can be blocked only closing/disposing the socket?
If this is true, as the protocol I'm implementing doesn't allow me to open/close the socket hundreds of time, I need to revert back to the sync Receive/Send version of the command that actually handle graceful timeout.
I have read a lot on the arguments and I'm quite sure of what I have written, but honestly I hope there's a way to handle the timeout using the TPL pattern without needing to close the socket...
Thanks.
Yes, that is correct. Timeouts don't apply to asynchronous socket methods. The proper way to cancel an existing async read/write is to close the socket.
I disagree. Timeouts in protocol definitions are only advisory; they cannot be enforced. Or put another way, it doesn't have to be a literal Receive or Send timeout; it can be a logical "receive" or "send" timeout.