2

I have programmed a plugin in Lua for a game that sends player information via a UDP packet (512 bytes) to a remote server that reads the data from the packet and aggregates all player information into an xml file (which can then be viewed on the web by all players so they can see eachother's current state).

I have programmed the server in Java using a DatagramSocket to handle the incoming packets, however I noticed some strange behavior. After a certain period of time, the DatagramSocket appears to temporarily stop accepting connections for about 10-12 seconds, then resumes normal behavior again (no exceptions are thrown that I can see). There is definitely a relationship between how often packets are sent by the clients and how quickly this behavior occurs. If I increase the update frequency of the clients, the DatagramSocket will "fail" sooner.

It may be worth mentioning, but each packet received spawns a thread which handles the data in the packet. I am running the server on linux if it makes a difference!

Does anyone know what could be causing this sort of behavior to occur?

Andrew

Andrew
  • 245
  • 2
  • 9
  • 2
    My conjecture would be that you're running out of receive buffer space on the server end. – NPE Nov 29 '11 at 16:28
  • Too little detail (for example, what Linux flavor, JVM and version of Java are you using), and some code would help; for sure spawning a new thread for each packet is a __bad__ idea (use a thread pool and/or a queue). In any case, consider that UDP is meant to be non reliable. – Viruzzo Nov 29 '11 at 16:29
  • I was incorrect in saying a thread was spawned. I am using a cachedThreadPool and ExecutorService to handle the packets. While I know UDP is non-reliable, it is suspicious that it would suddenly stop dropping packets, especially when I am testing the implementation on localhost. I will look more into the receive buffer size. – Andrew Nov 29 '11 at 16:43
  • @Andrew can we do anything with the buffer size, like clear it after each packets are received. – George Thomas Sep 02 '16 at 04:57

3 Answers3

3

UDP is a network protocol with absolutely no delivery guarantee. Any network component anywhere along the way (including the client and server PC itself) can decide drop the packets for any reason, such as high load or network congestion.

This means you'll have to spelunk a bit to find out where the packet loss is happening. You can use something like wireshark to see whether packets are arriving at the server at all.

If reliable delivery is more important than lower latency, switch to TCP. If you stick to UDP you'll have to allow for packets getting lost, regardless of whether you fix this particular issue at this particular time.

Barend
  • 17,296
  • 2
  • 61
  • 80
  • While reliable delivery isn't necessarily an important requirement, I ended up switching to TCP and the problem seems to have taken care of itself. The main reason for using UDP was because the client program had a nice wrapper for sending UDP packets, but I was able to createa nice solution using LuaSocket. – Andrew Nov 30 '11 at 13:28
3

My conjecture would be that you're running out of receive buffer space on the server end.

You might want to revisit your design: spawning a thread is a pretty expensive operation. Doing so for every incoming packet would lead to a system with relatively low throughput, which could easily explain why the receive queue is building up.

Also, see Specifying UDP receive buffer size at runtime in Linux

P.S. I am sure you already know that UDP does not guarantee message delivery, so I won't labour the point.

Community
  • 1
  • 1
NPE
  • 486,780
  • 108
  • 951
  • 1,012
  • can we do the same in android, is there any way that we could clear the buffer if it fill after long operations. My problem is the listeners stops after it works for long time – George Thomas Sep 02 '16 at 04:54
1

Starting a thread for each UDP packet is a Bad IdeaTM. UDP servers are traditionally coded as simple receive-loops (after all you only need one socket). This way you avoid all the overhead of threads, synchronization, and what not.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • +1. This is what I would have answered if I had done a better job reading the original question :-/. – Barend Nov 29 '11 at 16:33