ChannelDirectTcpip incorrectly waits for EOF

Jul 9, 2013 at 5:58 PM
In ChannelDirectTcpIp.cs, there are the following lines after the receive loop:
//  Channel was open and we MUST receive EOF notification, 
//  data transfer can take longer then connection specified timeout
//  If listener thread is finished then socket was closed       
System.Threading.WaitHandle.WaitAny(new WaitHandle[] { this._channelEof });
However, I don't understand the justification. A "channel closed message" will only be received if the remote end closes the connection. If the local end is expected to close it, WaitAny will block indefinitely (at least until a timeout occurs), which is the case I'm encountering right now. Commenting this line makes everything work fine: however I suppose it's here for a reason.

I also changed a few things related to ChannelDirectTcpip:
  • Added a using directive for the channel variable, line 56 of ForwardedPortLocal, so that the channel is always closed even if there is an exception. I suppose it's simply an omission.
  • CanRead and CanWrite extensions, as they are used in the .NET framework build, seem weird. Polling with SelectRead means that data should be available immediately, which isn't always the case. If data isn't immediately available on the socket, the read loop in ChannelDirectTcpip will stop rather than waiting! I changed CanRead to only check for socket.Connected, as the Silverlight method do. In fact, I think those methods should be removed and just replaced by socket.IsConnected. What do you think?
I didn't submit a patch so that we can discuss these issues first and find the appropriate solution.
Jul 9, 2013 at 6:22 PM
Please attach a diff.
IHMO its easier to discuss with a diff ;)
Jul 9, 2013 at 6:35 PM
Jul 9, 2013 at 7:22 PM
Edited Jul 9, 2013 at 7:23 PM
This to answer the CanRead-Method:

http://stackoverflow.com/questions/2661764/how-to-check-if-a-socket-is-connected-disconnected-in-c

(don't know why silverlight is different here..)
Jul 9, 2013 at 7:55 PM
Edited Jul 9, 2013 at 7:56 PM
Thanks, that makes sense. I should have read the documentation about Poll more thoroughly, I didn't realize it was blocking until data is available without a timeout, so this concern wasn't valid. Silverlight doesn't have a Poll method so only Connected is used.

The WaitAny part is the real problem though.