In the forums there have been complaints that OBEX on the Widcomm stack on WindowsMobile devices didn’t work in particular cases (e.g. PDF to a mobile phone).  I’ve been doing some testing to see if I can reproduce any faults.

I’ve been running a test of OBEX sending 5MB files repeatedly from a Windows XP PC with Widcomm to a PC running an XP with the Microsoft stack.  Two faults in Widcomm behaviour have been seen, both after many reps, e.g. about 60 of, that is after about 300MB of data.  Both result in data transfer stopping (I’m glad to report however that we see no data corruption).

Firstly we see sometimes that Widcomm stops sending its “buffer empty, you can now send some more” events.  When we have new data to send we call Widcomm’s CRfCommPort.Write(void *p_data, UINT16 len_to_write, UINT16 *p_len_written) method with the buffer of data we have.  As can be seen from the method signature this method can return having read only part of the data; in that case we store the data ourselves and wait for an indication that we can write again.  We use the TXEMPTY event for this, in the case here, the event never comes.  We see e.g.

... ...
m_port.Write: len in: 16384, len out: 8820
HandleEvent: 0x10000=FC
HandleEvent:  0x4000=TXCHAR
HandleEvent:  0x4000=TXCHAR
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x34004=TXEMPTY, TXCHAR, FC, FCS
m_port.Write: len in: 7564, len out: 7564
HandleEvent: 0x10000=FC
HandleEvent:  0x4000=TXCHAR
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x10000=FC
HandleEvent: 0x34000=TXCHAR, FC, FCS
HandleEvent: 0x34004=TXEMPTY, TXCHAR, FC, FCS
HandleReceive: len: 3
m_port.Write: len in: 16384, len out: 8820
HandleEvent: 0x10000=FC

So there we are progressing as normal, sending any remaining data on TXEMPTY, and then we do send which accepts only part of the data but no TXEMPTY then occurs.  In fact we see only one event an FC (Flow Control) event which means that the peer has sent a “stop” message.  It’s hard to know whether that’s truly what occurs, or whether something has gone wrong in the Widcomm stack locally.

Secondly I’ve seen a case where the call to the Widcomm Write method simply never returns.  Yikes!  That’s a really nasty one, and we’d have to have clever code to stop that causing a deadlock.  Anyway, both of these could cause the observed problems, we stop sending data due to these faults, the server has a timeout on its side and closes the connection and thus we see the EndOfStreamException or IOException.

I’ll try the same test on Windows Mobile and see what occurs.

Advertisements