Hi
Attached a patch on packet-wtp.c to handle reasssembly.
It's a bit dodgy because "fragment_add()" works with offsets in the packet
and WTP works with packet sequence numbers. I'm therefore not happy with
the
solution (which won't work in certain situations).
Would it be a good idea to have a 'fragment_add_seq()" function that does
the same but with sequence numbers instead of offsets (lot of
code-duplication though) or change the current "fragment_add()" to accept
sequence-numbers as well?
Yes, I think that would make sense.
in the fragment_data structure there is a flag where there still are lots of
unused bits.
Perhaps one could do something like the following:
define a new bit for the flags in fd_head
#define FD_SEQUENCED_BLOCKS 0x0100
Then change all functions in reassemble.c (like fragment_add() and
fragment_set_tot_len(), possibly others as well)
to check this flag in fd_head.
If the flag is 0, everything is normal, as it always has been.
If the flag is set to 1, then:
fragment_set_tot_len() is changed so that the total length specified
is number of blocks instead of number of bytes.
fragment_add() is changed so that it assumes pos is the block index
and not the position in the reassembled datagram.
there will be a number of changes to this function but not too
intrusive or obscure ones.
However, some things need some thought before implementation.
Say the functions in fragment_add() which handles overlapping fragments
and which indicates conflicts with previous data by FD_OVERLAPCONFLICT
would need to be changed.
Perhaps a workable semantic for this whren dealing with blocks would be
FD_OVERLAPCONFLICT would be set IF there already exists a block with
that sequence number but the previous block had a different size or
different data (memcmp()).
With these changes I think that the framgent_add() infrastructure could
handle your cases just fine. (might be wrong)
The changes should be quite straightforward to implement unless i have
forgotten something.
If you dont feel like adding this yourself to reassemble.c, just reply
to this mail indicating that you would want me to add it instead,
and I would be happy to implement the required changes for you.
Furthermore, I think that "fragment_add()" does not allow for
insertion of
re-transmitted packets (or did I miss something)?
Oh yes it does, unless someone has removed that functionality.
fragment_add() handles duplicates/complete-/partial-overlaps just fine.
If is sees a "duplicate" during retransmission but the retransmitted
"duplicate" contains different/conflicting data it will
even tell you so by setting FD_OVERLAPCONFLICT in fd_head.
Neat eh?
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
