sockets-for-pcl
sockets-for-pcl copied to clipboard
rdavisau
Reading from disconnected socket
I sometimes get into a situation where stream Read returns 0 repeatedly when asking bytes. I think its happening when you call read on a socket that has been disconnected from the server. So for instance. Connect to a server successfully, then have the server disconnect. When you call read, it just returns with 0 bytes read when asking for 1. Also, is there any way to know if the connection is still alive. An "IsConnected" properly would be great. Thanks!
And I should add, I would expect reading from a disconnected socket should either Timeout (based on the ReadStream Timeout property) or throw an error. Either one would be great.
And actually, when read returns 0, can I assume that means I am disconnected? If so, that would be fine as well.
Hey there - take a look at #9 for some previous discussion on some considerations regarding testing for socket connection etc., as well as a wrapper class that you can use to be informed more reliably about disconnection (it proactively performs the reads ahead of time in order to know that disconnection occured). In general, receiving 0 bytes back after a request for some other number of bytes is a good indication that the socket was disconnected (but I won't put my name to that in case there is the existence of some obscure unknown scenario in which that is not the case!).
With sockets-for-pcl, the streams that are exposed are the same streams that you would be using were you using a .NET TcpClient or WinRT StreamSocket directly. Because of that, you should just get the standard platform behaviours. As a design decision I haven't tried to do any connection monitoring in the core library, but the wrapper in the referenced issue should be a good starting point.
Let me know if you need anything more!
Thanks! And yes. Would be great to be able to specify a timeout on ConnectAsync. I know I can use Task.Wait, but that holds up the thread. There doesnt seem to be a way to pass in a CancellationTokenSource either. Other ideas?
Happily, timeout for ConnectAsync is coming in the next release! (#48) :star2:
In the meantime, you could adapt this extension method to work with Task rather than Task<T>.
I'll be working on it this weekend, so there will either be something ready in prerelease, or I'll have an idea of how much there is to go. I will let you know here.