IPV4 reassembly algorithm QB style

If you have questions about any aspect of QBasic programming, or would like to help fellow programmers solve their problems, check out this board!

Moderators: Pete, Mods

Post Reply
Posts: 41
Joined: Wed Oct 16, 2019 11:28 am

IPV4 reassembly algorithm QB style

Post by mikefromca »

I'm making my own webserver that is to handle multiple connections, and one thing I am trying to figure out is how to reassemble IP packets that come in without wasting memory or resources.

Various websites including this one: https://www.heise.de/netze/rfc/rfcs/rfc815.shtml have an RFC815 that state that making large "holes" and filling them in is the way to go and if they were all filled in then a packet is said to be received.

This is my Qbasic code but it isn't quite finished because I don't understand the algorithm perfectly the way its written in the RFC. Maybe someone with Qbasic and networking experience can shed some light.

Here's my code:

Code: Select all

DECLARE SUB setfrag (d$, ofs%, mf%)
DECLARE SUB firsthole ()
DECLARE SUB addhole (first%, last%)

'Hole descriptors
    first AS INTEGER
    last AS INTEGER
    set AS INTEGER 'If non-zero, it means this index has an entry

    first AS INTEGER
    last AS INTEGER
    more AS INTEGER
    dat AS STRING * 4000 'data in our fragment
CONST maxhole = 1000  'Assume we deal with 1000 holes?
DIM SHARED bigbuf AS STRING * 4000 'Our space of data after defragmentation is complete
DIM SHARED hole(maxhole) AS hd, frag AS d

'highest index in hole descriptor
'increments when new entries are added

nhs% = 0
CALL firsthole
'our fragment (will need more of these eventually)
CALL setfrag("TEST", 0, 1)

'run through each hole (this kills efficiency I think...)
FOR hs% = 0 TO maxhole - 1
    IF hole(hs%).set <> 0 THEN 'dont go through a hole if its not setup as a hole
        hf% = hole(hs%).first
        hl% = hole(hs%).last
        IF frag.first <= hl% AND frag.last >= hf% THEN 'This satisfies steps 2 and 3 of the algorithm
            hole(hs%).set = 0 'This satisfies step 4
            mf = frag.more
            IF frag.first > hf% THEN CALL addhole(hf%, frag.first - 1) 'This satisfies step 5
            IF frag.last < hl% AND mf% = 1 THEN CALL addhole(frag.last + 1, hl%) 'This satisfies step 6
            hs% = -1 'redo count
        END IF
    END IF
'All hole descriptors are processed so we jam in the data I guess??
MID$(bigbuf, frag.first + 1, frag.last - frag.first) = getfrag$
'then what???

'Here we add a hole to the new index and set it as a hole
SUB addhole (first%, last%)
nhs% = nhs% + 1
hole(nhs%).set = 1
hole(nhs%).first = first%
hole(nhs%).last = last%

'We setup the first hole per algorithm as 0 to length of output data space
SUB firsthole
'first hole = all space
hole(0).first = 0
hole(0).last = LEN(bigbuf)
hole(0).set = 1

'We load our fragment
FUNCTION getfrag$
getfrag$ = LEFT$(frag.dat, frag.last - frag.first)

'We setup our fragment. 2nd parameter is offset of fragment the "remote" host reports it to be.
'3rd parameter if non-zero means remote host has set the MF (more fragments) flag.
SUB setfrag (d$, ofs%, mf%)
frag.dat = d$
frag.first = ofs%
frag.last = ofs% + LEN(d$)
frag.more = 0
IF mf% <> 0 THEN frag.more = 1
Am I beating around the bush with the way I written my code?

I want to receive the remote fragments but I don't want huge spaces in my output data if all the fragments come in an awkward order. (like say first fragment is offset 100, and second at offset 10 and third at offset 200 etc).
Post Reply