No, the model for data transfer is:
- send "packet" from phone to device via WiFi (in one thread)
- wait for response/ack (at protocol, not TCP) layer (in a different thread)
- repeat until done
The socket remains open during the entire transmission of data. Data transmission is all TCP from the application's point of view.
Wireshark says that Windoze got the response data from the device and that it was well-formed. Part of my question concerns the boundary - in the simulator environment - between RIM-supplied networking code and host-O/S-supplied code.
The reading thread is definitely hanging on the equivalent of:
myReadIt (InputStream is, int n, byte[] buf) {
in.read(buf, 0, n); // hang is on the read
}
I've left out the fact that the in.read() is in a loop and try/catch (standard practice) for clarity.
What happens is I detect a timeout over in the writer thread because the protocol requires the response from the reader thread. When the writer thread forces an explicity close() on the socket, the hung read throws an exception, which is caught in myReadIt().
I've only been doing networking stuff for 25 years, though, so I could be missing something. (My BlackBerry time, however, is far shorter - just about a year now...)
