how to handle fragmented packets

[mark smit]

Hello...

What is the proper way to handle TCP packet fragmentation? If a packet does become fragmented, will this issue two or more %FD_READ messages?

A thousand thank you's in advance!

-------------
Cheers

[Lance Edmonds]

Mark, I'd suggest you research Winsock and TCP/IP... the TCP/UDP functions in PowerBASIC simply "encapsulate" the Winsock API, so it's behavior should duplicate the behavior of Winsock itself.

Please let us know what you discover! Thanks!


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[mark smit]

OK...

Do you know of any good books on TCP/IP? I understand that my questions are becomming irritating to you (or so it seems). How else do you start learning about things, I always thought that asking questions was the very first thing that should be done.



------------------
Cheers

[Enoch S Ceshkovsky]

Mark,
I don't think Lance is irritated, he is just very busy.
Have you read the help file's section on TCP/IP Communication?

Unlike UDP, TCP does not reassemble fragmented datagrams into the original data packet. It simply extracts the data portion of the datagram and adds it to the incoming data stream. This can be problematic if a source has sent 20 bytes of data that gets fragmented into two datagrams with 10 bytes each. TCP will give the first 10 bytes to the client without waiting for the next 10 bytes to arrive. UDP will give all 20 bytes of the data, or nothing.

The proper way is to create a IN buffer for each connection. Figuring out what to do with that buffer depends on the protocol. Some protocols use a fixed length header followed by a variable length block of data. Some use entirely fixed length blocks.

Perhaps if you were more specific on what you are trying to do with TCP, more specific hints can be given on what to do.

Enoch Ceshkovsky

------------------

[Mike Joseph]

If you're sending text commands and data, then you can probably use a delimiter. If im not mistaken, HTTP 1.1 uses a CR LF pair as a delimiter. (someone correct me if im wrong)

Alternately, you can use a prefix. Each recv you can check to see if the first X bytes represent the start of a new packet. If not, you can assume the data should be appended to the previous data.

In both cases, you need to make sure the prefix or delimiter is something that will never appear in the regular data.

Using a prefix or delimiter makes it easier to recover from unexpected data from the client (e.g. the packet header indicates a 100 byte data block follows, but you wind up receiving only 99 which causes you to erroneously append the first byte of the next packet to the previous packet) But using delimiters is a bit slower since you have to scan each packet for the delimiter/prefix.

You could probably use a hybrid approach. Packets with headers and variable length blocks along with a prefix. This way you wouldnt have to check each incoming packet for a prefix, only when you expected to be receiving a new packet. Then if the prefix doesnt exist on the next bit of data, you can assume an error has occured and you can throw out all the previous data instead of processing it and you can throw out the next set of data until you find the start of a new packet at which point you've recovered. You could even add code to disconnect the client (and maybe ban them) if a bunch of "odd" data keep coming from them.

Its important to be able to recover from unexpected data from the client because you can never tell if someone is trying to hack the server via a hacked client or a custom client.

-Mike

------------------

[Paul Noble]

Mark,

Have a look at "Windows Sockets Network Programming" by Bob Quinn & Dave Shute (Oct 1999), ISBN 0201633728, available from Amazon. I found it truly excellent, and it covers data handling in detail.

Also you might want to check out http://www.clarksoft.com/ , where they sell a really good WinSock package, just loaded with information and working PowerBASIC code. In particular, the code shows you how to deal with fragmentation.

Regards,

Paul


------------------