TCP or UDP with Java

Question

Sorry for such the long post. I have done lots and lots of research on this topic and keep second guessing myself on which path I should take. Thank you ahead of time for your thoughts and input.

Scenario:

Create a program in Java that sends packets of data every .2-.5 seconds that contain simple "at that moment" or live data to approximately 5-7 clients. (Approximately only 10 bytes of data max per packet). The server can be connected via wifi or ethernet. The clients however are restricted to only using Wifi. The client(s) will not be sending any packets to the server as it will only display the data retrieved from the server.

---

My Thoughts:

I originally started out creating the server program using TCP as the transport layer. This would use the ServerSocket class within Java. I also made it multithreaded to accept multiple clients.

TCP sounded like a great idea for various reasons.

1. With TCP, the message will always get sent unless the connection fails.
2. TCP rearranges the order of packets sent.
3. TCP has flow control and requires more time to set up when started.

So, perfect! The flow control is crucial for this scenario (since the client wants the most concurrent information), the setup time isn't that big of a deal, and I am pretty much guaranteed that the message will be received. So, its official, I have made my decision to go with TCP....

Except, what happens when TCP gets behind due to packet loss? "The biggest problem with TCP in this scenario is its congestion control algorithm, which treats packet loss as a sign of bandwidth limitations and automatically throttles the sending of packets. On 3G or Wi-Fi networks, this can cause a significant latency."

After seeing the prominent phrase "significant latency", I realized that it would not be good for this scenario since the client needs to see the live data at that moment, not continue receiving data from .8 seconds ago. So, I went back to the drawing board.

After doing more research, I discovered another procedure that involved UDP with Multicasting. This uses a DatagramSocket on the server side and a MulticastSocket on the client side.

UDP with Multicasting also has its advantages:

1. UDP is connectionless, meaning that the packets are broadcasted to anyone who is listening.
2. UDP is fast and is great for audio/video (although mine is simple data like a string).
3. UDP doesn't guarantee delivery - this can be good or bad. It will not get behind and create latency, but there is no guarantee that all client(s) might receive the data at that moment.
4. Sends one packet that gets passed along.

Since the rate of sending the packets will be rather quick (.2-.5 sec), I am not too concerned about losing packets (unless it is consistently dropping packets and looks to be unresponsive). The main concern I have with UDP above anything is that it doesn't know the order of which the packets were sent. So, for example, lets say I wanted to send live data of the current time. The server sends packets which contain "11:59:03", "11:59:06", "11:59:08", etc. I would not want the data to be presented to the client as "11:59:08", "11:59:03", "11:59:06", etc.

---

After being presented with all of the information above, here are my questions:

• Does TCP "catch up" with itself when having latency issues or does it always stay behind once the latency occurs when receiving packets? If so, is it rather quick to retrieving "live" data again?

• How often do the packets of data get out of order with UDP?

And above all:

• In your opinion, which one do you think would work best with this scenario?

Thanks for all of the help!

Answer 1

Does TCP "catch up" with itself when having latency issues or does it always stay behind once the latency occurs when receiving packets?

TCP backs its transmission speed off when it encounters congestion, and attempts to recover by increasing it.

If so, is it rather quick to retrieving "live" data again?

I don't know what that sentence means, but normally the full speed is eventually restored.

How often do the packets of data get out of order with UDP?

It depends entirely on the intervening network. There is no single answer to that.

NB That's a pretty ordinary link you're citing.

• UDP stands for 'User Datagram Protocol', not 'Universal Datagram Protocol'.
• UDP packets do have an inherent send order, but it isn't guaranteed on receive.
• 'UDP is faster because there is no error-checking for packets' is meaningless. 'Error-checking for packets' implies retransmission, but that only comes into play when there has been packet loss. Comparing lossy UDP speed to lossless TCP speed is meaningless.
• 'UDP does error checking' is inconsistent with 'UDP is faster because there is no error-checking for packets'.
• 'TCP requires three packets to set up a socket connection, before any user data can be sent' and 'Once the connection is established data transfer can begin' are incorrect. The client can transmit data along with the third handshake message.
• The list of TCP header fields is incomplete and the order is incorrect.
• For TCP, 'message is transmitted to segment boundaries' is meaningless, as there are no messages.
• 'The connection is terminated by closing of all established virtual circuits' is incorrect. There are no virtual circuits. It's a packet-switching network.
• Under 'handshake', and several other places, he fails to mention the TCP four-way close protocol.
• The sentences 'Unlike TCP, UDP is compatible with packet broadcasts (sending to all on local network) and multicasting (send to all subscribers)' and 'UDP is compatible with packet broadcast' are meaningless (and incidentally lifted from an earlier version of a Wikipedia article). The correct term here is not 'compatible' but supports.

I'm not fond of this practice of citing arbitrary Internet rubbish here and then asking questions based on it.

Answer 2

UDP packets will may get out of order if there are a lot of hops between the server and the client, but more likely than getting out of order is that some will get dropped (again, the more hops the more chance of that). If your main concern with UDP is the order, and if you have control over the client, then you can simply have the client discard any messages with an earlier timestamp than the last one received.