melbareena / tinyos-main

Automatically exported from code.google.com/p/tinyos-main
0 stars 0 forks source link

[patch] BLIP fragment handling leaves last fragment buffer unused #117

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Note the configured value of N_FRAGMENTS in IPDispatch.h
2. Send the largest packet you can from TinyOS
3. Observe that the number of fragments on the air is really N_FRAGMENTS-1, 
even though memory has been set aside for N_FRAGMENTS.

What is the expected output? What do you see instead?

All the memory reserved by the N_FRAGMENTS sized array of message_t should be 
available for use. Currently, IPDispatchP uses a round-about way of working out 
whether there are more fragments to send, and allocates a fragment buffer even 
if there are no fragments left to send, effectively wasting an entire message_t 
worth of RAM. The attached patch introduces a very small helper function in 
lib6lowpan_frag.c, and IPDispatchP is tweaked to check whether there are more 
fragments _before_ allocating a fragment buffer. This allows BLIP to send 
packets using N_FRAGMENTS fragments, up from N_FRAGMENTS-1.

What version of the product are you using? On what operating system?

TinyOS 2.x, trunk/r5884

Please provide any additional information below.

Some fuzz possible, as we're using BLIP with an RF212 radio here and as such 
our tree has diverged slightly from trunk. Hand-merge should be trivial if it 
doesn't apply automatically.

Original issue reported on code.google.com by jmatts...@dius.com.au on 9 Feb 2012 at 10:36

Attachments:

GoogleCodeExporter commented 9 years ago
Agreed this is bad (and old iirc).  We just tagged for 2.1.2 so I'll have to 
get this in the next release rather than retesting everything.

Original comment by sdh...@gmail.com on 15 Feb 2012 at 8:07