search

rdavisau / sockets-for-pcl

Cross-platform socket API for Xamarin iOS/Android/Forms, Xamarin.Mac/MonoMac, Windows Phone 8/8.1, Windows Store and Windows Desktop.
MIT License
223 stars 72 forks source link

Reading from disconnected socket #49

Open vbisbest opened 9 years ago

vbisbest commented 9 years ago

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!

vbisbest commented 9 years ago

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.

vbisbest commented 9 years ago

And actually, when read returns 0, can I assume that means I am disconnected? If so, that would be fine as well.

rdavisau commented 9 years ago

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!

vbisbest commented 9 years ago

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?

rdavisau commented 9 years ago

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>.

vbisbest commented 8 years ago

Thank you. Do you have an ETA on the next version?

rdavisau commented 8 years ago

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.

rdavisau commented 8 years ago

(getting there, more slowly than anticipated)