Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Problems sending multiple messages  (Read 4616 times)

0 Members and 1 Guest are viewing this topic.

Guni

  • Newbie
  • *
  • Posts: 20
    • View Profile
Problems sending multiple messages
« on: July 04, 2012, 07:02:33 am »
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

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Problems sending multiple messages
« Reply #1 on: July 04, 2012, 09:00:23 am »
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).
« Last Edit: July 04, 2012, 10:14:49 am by Guni »

mimipim

  • Newbie
  • *
  • Posts: 49
    • View Profile
Re: Problems sending multiple messages
« Reply #2 on: July 04, 2012, 09:42:44 am »
As far as I know the UDP socket do not care if all packages gonna be delivered.
Instead you can try with TCP.

Guni

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Problems sending multiple messages
« Reply #3 on: July 04, 2012, 10:13:25 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Problems sending multiple messages
« Reply #4 on: July 04, 2012, 12:04:10 pm »
Quote
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.
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Problems sending multiple messages
« Reply #5 on: July 04, 2012, 12:09:19 pm »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Guni

  • Newbie
  • *
  • Posts: 20
    • View Profile
Re: Problems sending multiple messages
« Reply #6 on: July 04, 2012, 09:21:56 pm »
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.