Unusual UDP Behavior

General
1

I am working on a program that communicates with a mixing console using OSC (Open Sound Commands) via a network UDP connection. I sub-classed the Xojo UDP control and added a bit of functionality for sending and receiving commands. It all works fine until there is a big burst of data. This occurs when a user does a reset or loads a preset and there is a lot of data flying back and forth. That is when packets seem to get “lost”.

Here is the odd bit. If I add a line to refresh the main window, it works better. So I added a timer that simply calls Window.Refresh every second. Now the program responds as it should very quickly and no packets are dropped. My question is: Why does calling a seemingly unrelated function fix the problem? And is there a better way to do this?

2

  1. UDP IS inherently lossy and actually losing packets is perfectly normal for UDP
    It’s not intended to be “reliable” just “fast as heck” - if you want reliable then use TCP

  2. You do realize that “data available” means “theres SOME data available” not “a whole packet or message has arrived”
    YOU have to write code to impose some kind of “protocol” on top of the UDP transport

3

This is because it’s UDP.
Unlike TCP, UDP doesn’t do congestion control.
UDP is very fast but that’s because it’s lacking things like this. It doesn’t guarantee delivery (nor delivery in the same sequence). The sender just drops it on the wire and hopes it ends up well. If the receive buffers are getting full, packets get dropped and the transmitter isn’t notified.
I don’t think you can increase the receive buffer size (maybe MBS?).
Or you could try to use a very fast timer that keeps polling so the receive buffer stays as empty as possible.

But I think that if your application layer cannot handle dropped packets, you’re probably better off using TCP.

4

I’m just curious: does this still hold true if you leave the timer but remove the call to refresh?

5

Is this on a Mac? Could it be AppNap?

AppNap could be started if it’s not the foreground App or “It hasn’t recently updated content in the visible portion of a window”

6

Thanks for the replies. After posting I tried a few more things and it’s working okay now. I had already placed code to prevent the dreaded app nap. I removed the Refresh command and instead placed a label on the window. In my loop, I added
“Label1.Text = Label1.Text”. The label is transparent on a black background so it is invisible to the user. I don’t know why it works but it does. It must have something to do with the message pump. It’s just one of those quirks I guess.