> >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.
I presume there will still be a separate call to add sequenced blocks
though, you cannot indicate that in the current fragment_add()-call (as the
fragment-structure may not exist yet).
> 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()).
I'd propose to skip the OVERLAP-checking in that case as overlapping is
impossible with sequence-blocks. As for receiving an existing
sequence-block, that could be a re-transmission and then the size could
differ.
> 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.
As I won't be able to do anything significant for the next month or so and
am not really comfortable with that part of the code, you doing the changes
would be very much appreciated.
Thanks & thanks in advance.
Regards,
Tom Uijldert Email: Tom.Uijldert@xxxxxx
