it guarantees delivery. It doesn't guarantee packet boundarys. String of bytes.s
On Sat, May 14, 2011 at 3:33 PM, steve ayer <[email protected]> wrote: > um, > > "standard tcp programming" practice has a clear understanding that the tcp > protocol guarantees delivery of its payload. > > On 05/14/2011 02:45 PM, Phil Reaston wrote: > >> Don't forget to consider the receiving end too. If you're on windows >> for instance and you use sockets for the receive rather than a BT COM >> port then you're going to get partial packets anyway. Standard tcp >> programming. >> >> Phil Reaston >> Sent from my iPad >> >> On May 14, 2011, at 9:44, Benjamin Kuris<[email protected]> wrote: >> >> Similar request went out to Roving Networks about 18 months ago from >>> another customer-- fell on ambivalent ears and there was no indication >>> of intent from RN to support at this level. In fact customer couldn't >>> even get an answer as to the size of the serial FIFO on the module. >>> >>> My understanding is that much of this functionality is defined by CSR >>> Bluecore implementation and RN is just running a command parser in the >>> measly virtual machine cycles they get. So the scheme is also quite >>> complex at the chip level... >>> >>> -Ben >>> >>> >>> On Sat, May 14, 2011 at 12:26 PM, Burns, Adrian<[email protected]> >>> wrote: >>> >>>> Don't disagree steve, the BT stack is overly complicated, and I think we >>>> came to the same conclusion before on the SPP MTU discussion(see attached) >>>> >>>> the RN-42 physical layer seems to send random transmission unit sizes >>>> and we assume the Shimmer Bluetooth driver is feeding it full payload bytes >>>> continuously without a significant delay between any of the payload >>>> bytes... >>>> so RN-42 should see the delay after the last payload byte received from >>>> MSP, parcel up app SPP data payload, add L2CAP framing and off it goes over >>>> the air in whatever baseband transmission unit is big enough to fit around >>>> the packet (they are defined in BT spec)....this aint happening obviously >>>> on >>>> RN-42 and im not 100% sure if it's actually a bug or not >>>> I think the only hope to fix this would be if Roving Networks changed >>>> their virtual machine firmware to hold its bytes until a programmed >>>> transmission unit size is met, then flush out a packet at a time rather >>>> than >>>> just random chunks >>>> >>>> I might get ping Roving Networks on this next week if I get a chance, >>>> they should be able to get to the bottom of it, otherwise I think this >>>> issue >>>> may pop its head up again and again :-0 >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: steve ayer [mailto:[email protected]] >>>> Sent: Saturday, May 14, 2011 3:28 PM >>>> To: Burns, Adrian >>>> Cc: Nicholas Hosein; [email protected] >>>> Subject: Re: [Shimmer-users] Bluetooth packet fragmentation >>>> >>>> hi adrian, >>>> >>>> that may be, but the bottom line is that the bluetooth physical layer >>>> apparently (go ahead, what's the bluetooth mtu?) has no concept of its >>>> own transmission units, unlike other wireless protocols like 802.11 and >>>> 802.15.4. depending upon payload-transport protocols to keep your bytes >>>> together is a pretty taudry way to conduct stateful wireless >>>> communications, imho... >>>> >>>> but as you point out, this is nothing (independent of the os) that a >>>> couple of lines of python won't cure. it's just too bad that those >>>> lines have to be carted around in middleware, or worse, in applications. >>>> >>>> $0.02, >>>> >>>> steve >>>> >>>> On 05/14/2011 07:44 AM, Burns, Adrian wrote: >>>> >>>>> gents, Just to add here that what you are seeing is normal for SPP as >>>>> its just a serial interface type profile supporting streams of bytes.. >>>>> If it were OBEX for example then you would have full re-assembly of >>>>> application level packets, but that's different profiles(OPP and FTP..) >>>>> >>>>> L2CAP has segmentation and reassembly to allow transfer of larger >>>>> packets than lower layers support but this is link level stuff not >>>>> application level....the chunks of data you see on the host are what the >>>>> baseband radio segmented and then transferred over the air >>>>> So as you know, the chunks will arrive at the host in sequence and you >>>>> have to wait on the host for a few segments until it adds up to 122 bytes, >>>>> then you have a packet...Not ideal I know as I have had to do the very >>>>> same >>>>> on android hosts >>>>> >>>>> cheers >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto: >>>>> [email protected]] On Behalf Of steve ayer >>>>> Sent: Friday, May 13, 2011 9:40 PM >>>>> To: Nicholas Hosein >>>>> Cc: [email protected] >>>>> Subject: Re: [Shimmer-users] Bluetooth packet fragmentation >>>>> >>>>> yup, >>>>> >>>>> that's bluetooth for you. for all of the protocol's complexity, you >>>>> still have to frame your own packets. >>>>> >>>>> -steve >>>>> >>>>> On 05/13/2011 04:38 PM, Nicholas Hosein wrote: >>>>> >>>>>> So i noticed when i send a packet from bluetooth (122 bytes / packet) >>>>>> it >>>>>> comes to the host broken up into multiple packets. This is an example >>>>>> of >>>>>> what the host receives when i send 4x122byte packets from the mote: >>>>>> >>>>>> ** >>>>>> >>>>>> *Data Size: 1 * >>>>>> >>>>>> *Data Size: 64 * >>>>>> >>>>>> *Data Size: 57 * >>>>>> >>>>>> Data Size: 1 >>>>>> >>>>>> Data Size: 66 >>>>>> >>>>>> Data Size: 55 >>>>>> >>>>>> *Data Size: 4 * >>>>>> >>>>>> *Data Size: 67 * >>>>>> >>>>>> *Data Size: 51 * >>>>>> >>>>>> Data Size: 11 >>>>>> >>>>>> Data Size: 54 >>>>>> >>>>>> Data Size: 57 >>>>>> >>>>>> >>>>>> Is this normal or am i doing something wrong? It would be much easier >>>>>> if >>>>>> i just got one packet instead of having to send a payload and append >>>>>> multiple packets together. >>>>>> >>>>>> >>>>>> Much thanks guys, >>>>>> >>>>>> >>>>>> Nick >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Shimmer-users mailing list >>>>>> [email protected] >>>>>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >>>>>> >>>>> _______________________________________________ >>>>> Shimmer-users mailing list >>>>> [email protected] >>>>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >>>>> ------------------------------------------------------------- >>>>> Intel Ireland Limited (Branch) >>>>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >>>>> Registered Number: E902934 >>>>> >>>>> This e-mail and any attachments may contain confidential material for >>>>> the sole use of the intended recipient(s). Any review or distribution >>>>> by others is strictly prohibited. If you are not the intended >>>>> recipient, please contact the sender and delete all copies. >>>>> >>>>> ------------------------------------------------------------- >>>> Intel Ireland Limited (Branch) >>>> Collinstown Industrial Park, Leixlip, County Kildare, Ireland >>>> Registered Number: E902934 >>>> >>>> This e-mail and any attachments may contain confidential material for >>>> the sole use of the intended recipient(s). Any review or distribution >>>> by others is strictly prohibited. If you are not the intended >>>> recipient, please contact the sender and delete all copies. >>>> >>>> _______________________________________________ >>>> Shimmer-users mailing list >>>> [email protected] >>>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >>>> >>>> >>>> _______________________________________________ >>> Shimmer-users mailing list >>> [email protected] >>> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >>> >> _______________________________________________ >> Shimmer-users mailing list >> [email protected] >> https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users >> > _______________________________________________ > Shimmer-users mailing list > [email protected] > https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users > -- Eric B. Decker Senior (over 50 :-) Researcher
_______________________________________________ Shimmer-users mailing list [email protected] https://lists.eecs.harvard.edu/mailman/listinfo/shimmer-users
