Properly handling network timeouts on Windows CE

Question

I'm trying perform a relatively basic TCP socket send/receive operation on Windows CE using the .NET Compact Framework. I'm trying set the timeout value so that reads/writes on a slow connection timeout instead of blocking forever. On the full framework I'm able to simply set the ReceiveTimeout and SendTimeout properties on the Socket object. Unfortunately, setting these properties on the compact framework immediately results in a SocketException about using an unsupported socket option.

After digging a little further, I came across this page that says the following:

    The following table shows BSD options not supported for setsockopt:

    Value            Type       Description
    SO_ACCEPTCONN    BOOL       Sets socket listening.
    SO_RCVLOWAT      int        Sets recv low watermark.
    SO_RCVTIMEO      int        Sets time-out for recv.
    SO_SNDLOWAT      int        Sets send low watermark.
    SO_SNDTIMEO      int        Sets time-out value for send.
    SO_TYPE          int        Sets socket type.

So it doesn't look like Windows CE supports timeouts. A timeout will eventually occur on an unresponsive connection but it seems to take about a minute (must be hardcoded somewhere in WinCE). So now I'm trying to figure out how to implement this manually. My first thought is to use asynchronous IO which allows me to WaitOne(timeout). However, this won't stop the asynchronous thread that will be stuck on EndSend() or EndReceive(). So even if I can timeout my main thread there will still be threads lingering around until the hardcoded timeout is hit. During this time my application won't shut down properly. The only way I can think of working around this problem would be to abort the asynchronous thread but this seems like a very bad idea and would I like to avoid it.

So what is the correct way to handle this? There must be a simple way since other applications (e.g. IE on WinCE) don't seem to have any trouble timing out or canceling pending network operations and they seem to be able to shutdown without trouble as well.

Answer 1

I found a clean way to do this. Basically I am doing the sending and receiving in a separate thread and then waiting on an event (manual or auto reset event should work). If the wait times out then simply closing (or disposing) of the socket will cancel the blocking read/write in the other thread causing a graceful (an exception is thrown on the Send()/Receive() call) exit on that thread. Hopefully this will be helpful to someone else...