Problems sending multiple messages

[Guni]

Hi, I have some really simple code that sends 10 consecutive numbers.

Sender:

int main()
{
        std::cout << "Sending\n";
        sf::UdpSocket socket;
        socket.bind(8041);
        socket.setBlocking(true);
       
        sf::IpAddress loopback("127.0.0.1");
        for(int i = 0; i < 100; i++)
        {
                sf::Packet packet;
                packet << sf::Int32(i);
                socket.send(packet, loopback, 8040);
        }
        std::cout << "Done sending\n";
}

Receiver:

int main()
{
        std::cout << "Ready\n";
        sf::UdpSocket socket;
        socket.setBlocking(true);
        socket.bind(8040);
        while(1)
        {
                sf::Packet packet;
                sf::IpAddress address;
                unsigned short port;
                socket.receive(packet, address, port);
                std::cout << "Packet received from " << address.toString() << " port: " << port << "\n";
                sf::Int32 i;
                packet >> i;
                std::cout << "Message: " << i << "\n";
        }
}

When I turn on the receiver, then run my sender, I get this output on the receiver's console:

Ready
Packet received from 127.0.0.1 port: 8041
Message: 0

instead of 100 messages from 0 to 99, which is what I expect.

When I add this line of code to add a slight delay in the sender

sf::sleep(sf::Time(sf::milliseconds(1)));

right after this line:

socket.send(packet, loopback, 8040);

I get every message, except the 2nd message ("Message: 1"), gets mysteriously lost most, but not all of the time. Why do I need this delay here? And any clues on why only the second message keeps getting lost consistently?

[Guni]

It seems if I send 1 packet, sleep for 1ms, then send 100 more packets, without any delay in between, all 101 packets get delivered. However, if I do not add that 1ms delay after the first packet is sent, only that first packet gets sent.

So, I tried something else, send 1000 packets without delay. Interestingly enough, the first packet gets sent, the next 130-140 get dropped, then the rest come normally. (I am pretty sure I am not overflowing the send or receive buffers with only 1000 packets).

It seems as though after the first packet gets sent, there is a "warmup period", during which no packet can be sent. Perhaps something is happening at the hardware/OS level that is causing this behavior.

The only experiments I've been able to do on the actual Internet (rather than just using a loopback address), is the code that is in the original post. I get the same results. If I post 100 packets with no delay in between, only the first packet gets sent. If I post 100 packets with a 1ms delay between each packet, every packet gets sent (maybe the 2nd packet, "Message: 1" gets frequently dropped, I don't remember).

[mimipim]

As far as I know the UDP socket do not care if all packages gonna be delivered.
Instead you can try with TCP.

[Guni]

As far as I know the UDP socket do not care if all packages gonna be delivered.
Instead you can try with TCP.

Yeah I know, I'm just wondering about this odd behavior of UDP packets.

[Laurent]

As far as I know the UDP socket do not care if all packages gonna be delivered.
Instead you can try with TCP.

I don't think it explains this issue

But yeah, you can try the exact same code with TCP. If I can, I'll try to test your code.

[binary1248]

This is not odd behavior. In fact this is pretty standard behavior. You might not think that 100 packets containing 4 bytes each can fill any buffers along the way. However there are multiple buffers involved. The OS socket buffer probably has enough space in it. The buffer on your NIC (if there is one present) might only have several KB of space. Considering that a full IP packet is 32 bytes in your case, if you push too much data into it before it can send any of it (has to wait for diverse reasons I will not go into here) it will tail-drop data from the buffer. This means it drops the oldest data that hasn't been sent yet, in your case the 2nd packet. Your NIC doesn't tell your OS that it dropped anything because L2 doesn't guarantee delivery at all. The only mechanism that guarantees delivery (sort of) can be found at L3 and higher, TCP etc. This is done by the OS network stack. For this you need a connection and UDP is a connectionless protocol.

Your observations only emphasize the fact that UDP is an unreliable (not necessarily bad) protocol and this is part of the standard. The "unreliability" is not well-defined and is different depending on the systems involved.

[Guni]

Thanks for the insight, binary1248. From what you're saying, it seems like what's happening in my case is that the OS buffer doesn't "turn on" until after I send one packet, and no packets can be sent during this "warmup phase". Then again, this behavior is probably undefined and dependent on hardware.

Practically, I guess this means I cannot make the assumption that if you send a large number of packets, at least one will make it to the other side.