Hi Fred, Dino, |>> Patently nonsense. Packet reassembly in hardware is very much |>> straightforward if one is willing to burn large buffers to do so. |>> Imagine |> |>The willing part is the impossible part.
Well, that sounds like a personal problem. ;-) |I'm not convinced as to how "large" the buffers need to |be? AFAICT, the size depends on the number of simultaneous |reassemblies in progress plus the degree to which the |network mis-orders packets plus the degree to which stale |reassemblies are garbage-collected. This, plus SEAL puts |a firm cap of 2KB as the largest size an ETR will ever |have to reassemble. Obviously you can optimize, but even a naïve implementation has to have a bound on the number of reassemblies that it can have in progress at any given time. Again a trivial implementation is to provide a max sized buffer for each such reassembly. If folks want to do a more sophisticated implementation, then it wouldn't be too hard to use sparse matrix techniques and/or cell techniques to segment incoming fragments into cells and then reassemble the fixed sized cells. This reduces the problem to one that's previously been solved. Tony -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
