Marco, Thanks for the reply. With my test applications, the connection remains open after the data has been sent. So that wasn't the problem. But after reading your email, I updated OS X to the latest version, 10.2.6 and the update fixed the problem. I guess it was a known bug that has now been fixed. Keith From: Marco Pontil <mpontil@apple.com> To: Keith Phu <kphu@hotmail.com> Subject: Re: Dropped data packets with an RFCOMM connection Date: Thu, 15 May 2003 10:02:15 -0700 Hi Keith, RFCOMM is a protocol build over the L2CAP protocol, the L2CAP data consistency is ensured by the hardware where packets are sent with a crc based error detection, I recall the crc being 16 bits for 2712 bits of payload (2 bytes every 339 bytes), so it is kind of little and may not catch everything. So the answer to your last question is no, 100% reliability is not achieved. That said I think your problem is something different, you did not send enough data to make it likely to hit the crc weaknesses. Can you tell me more about your setup ? What kind of Bluetooth hardware are you using and which version of MacOS X are you running in and which side closes the connection. Do you know which packet are missed ? (You know what you sent so you should know what you did not receive). How do you close the connection ? Is it possible that you are shutting down the connection before all the data is sent ? If this is the case it should be easy to figure out, after one minute instead of closing everything wait and see if all the data arrived, or add a sleep(5) before the close. ... Marco On Wednesday, May 14, 2003, at 12:41 PM, Keith Phu wrote: Hi, I'm using an RFCOMM connection to transmit data from one powerbook to another. The application on the transmitting powerbook repeatedly uses the 'write:length:sleep' function to transmit a block of data (of about 10 bytes) to the other receiving powerbook every 10 ms. After running for about 1 minute (that's a total of 6000 blocks transmitted), a small number of blocks will not have arrived at the receiver. The transmitter will will have successfully (as returned by 'write:length:sleep') transmitted 6000 blocks, but the receiver will only have received say 5997 blocks. Some of the blocks have gone missing. Does anyone have an idea of where these missing blocks have gone? And a way to make the RFCOMM connection more reliable (without needing to add my own error correction algorithm to my application)? Can we not assume that an RFCOMM connection provides 100% reliability in a typical situation? Thanks Keith _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus _______________________________________________ bluetooth-dev mailing list | bluetooth-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored. _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ bluetooth-dev mailing list | bluetooth-dev@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.