lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #6861] Pimp ip_frag.c


From: Simon Goldschmidt
Subject: [lwip-devel] [task #6861] Pimp ip_frag.c
Date: Mon, 23 Jul 2007 21:03:09 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

Follow-up Comment #16, task #6861 (project lwip):

I'm attaching a patch and the file ip_frag.c with my changes.

I did have to work a little on it to make it presentable and test it a
little, still I'm not really convinced it is bug-free since testing this is a
little hard.

What the new code should do is the following:
- move the global variables into a struct to support multiple simultaneously
arriving IP packets to be reassembled at the same time (say, struct
ip_reassdata)
- those structs should come from a (new) memp pool (maybe chain them on a
queue to keep track of the current packets)
- instead of a reassbuf, the incoming pbufs should be used, chaining them
together when the whole packet is received. This way we a) prevent copying
the data and b) don't have to provide the memory for it all the time
- the maximum simultanously reassembled packets are limited by the memp pool
the ip_reassdata struct comes from
- the maximum number of pbufs being queued for reassembly has also be limited
in order to prevent queueing all the PBUF_POOL pbufs, which could deadlock the
stack because no more packets can be received since the pbuf pool is empty
(timeout also works, but may lead to 'nearly-deadlocking')


I moved from the bitmap algorithm to chaining the pbufs and remembering their
offset & length (I use the space of the IP header that is not used after
receiving).

What doesn't work yet is trimming pbufs if fragments don't exactly fit to
each other (i.e. overlap) (e.g. due to retransmission using a different path
over the internet).

BTW: the code size stays roughly the same on my embedded target (old: 1346
bytes vs. new: 1364 bytes).

(file #13444, file #13445)
    _______________________________________________________

Additional Item Attachment:



    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6861>

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]