Quote:Original post by SiCrane
Simpler design: don't do packet switching in your protocol. Instead start a new socket connection for a file transfer and just have the sender send() and the receiver recv(). Then you get to use the buffers and packet switching and congestion handling routines of the TCP/IP stack.

Where can I learn more about congestion?

It seems that if the receiving end lags behind a bit, then the sender will overflow the receiver.

I did a test where I sent packets 64.000 bytes in size, and ocasionally the receiver would receive more or less than 64.000.

Now, because my protocol has a header in the first few bytes of the packet, weird stuff might occur.

hdddd (header + data)

If there is overflow and the packet gets broken in two:
hdd <--- things might go wrong, but at least I have the header
dd <--- things will definitly go wrong here, as I expect a header

So, how to get around this congestion/ overflow issue? I've reduced errors to a minimum by reducing the packet size to 1.000 bytes, and doing this:
1. send
2. wait for receiver to say it has received the packet
3. send another

...but this feels like hacking, and with this method there is a lot of wait time going on, and I feel I'm losing a lot of transmission speed...

I think I found a solution, when I realised that even though the packets might not arrive fully, they will at least arrive in order.

So, I changed the algorithms so that data will only be processed once we have a full packet. It goes more or less like this:

1. Packet "h3dd" arrives. The header states that the data is 3 units long. As you can see we only received two units (dd).

2. Packet "dh1dh" arrives. Now, the previous packet wasn't complete, so we add the previous one to this one, we get "h3dddh1dh". If we break it up we get "h3ddd h1d h". This means I can process the first two headers already as the 3rd hasn't yet completely arrived, we still don't have all the data for it to be correctly processed.

Comments are welcome...