I'm using the dll to try and communicate with a custom device.  The device sometimes needs to restart without my knowledge.  This can cause an IrDA Read to hang.  Is there some way to configure a timeout associated with the read operation?

Well this is not really a 32feet issue, one is just using the network comms facilities that .NET provides itself: IrDAClient.GetStream is a bog standard System.Net.NetworkStream and IrDAClient.Client is a bog standard System.Net.Sockets.Socket, and each provides ways to handle timeouts/disconnection.

For instance, you could set ReadTimeout on NetworkStream -- assuming you're using .NET v2.  If a Read takes too long, it throws.  (Note that one should then discard that connection (which is probably what you'd want to do in this case anyway), see http://blogs.msdn.com/mflasko/archive/2006/02/20/535655.aspx)

Similar setting are available on Socket.  And of course one can do the Read asynchronously and cancel it from another thread if it has taken too long.

The only IrDA specific point is that is the IrDA protocol continually checks that both devices are still present and alive.  So if the device itself stops responding then the connection will be aborted eventually (with socket error 10054, IIRC).  However if only the application level connection has hung then it won't...

Alan,

     Thanks for the response.  Unfortunately, I'm limited to CF 1.1.  I tried putting the read in a separate thread and then killing it after a timeout, but that didn't work for some reason.  I'll review what I did.  In the meantime, is there a way to set a timeout in cf 1.1 without delving into the implementation of the socket mechanism?

Thanks,

Jeff Stewart

Well I was thinking along the lines of:

            IAsyncResult ar = strm.BeginRead(buf, 0, buf.Length, null, null);

            bool completed = ar.AsyncWaitHandle.WaitOne(60 * 1000, false);

            if (!completed)

            {

                // Read timed-out.  So close the connection.  This will cause the

                // async op to complete, and EndRead will throw a suitable exception.

                strm.Close();   // EndRead throws ObjectDisposedException

                //cli.Close();    // EndRead throws IOException

            }

 

            int bytesRead = strm.EndRead(ar);

            //... do stuff with the bytes ...

            // Or maybe, if was !completed, handle the expected exception.

 

I'm hoping that CF 1.1 supports that scenario...

     Thanks, the AsyncWaitHandle did the trick, but only in CF 2.0 (not supported in 1.1)!

Also, timeouts for Read and Write are not supported in CF 2.0.  I've convinced the client to move to CF 2.0 based on the AsyncWaitHandle support.

 

 

 

Hmm, MSDN (http://msdn2.microsoft.com/en-us/system.iasyncresult.asyncwaithandle.aspx) says

.NET Compact Framework

Supported in: 2.0, 1.0

 

Anyway glad to have helped.

Asyncwaithandle IS supported in CF 1.1, but not the overload that supports setting timeouts.