Using UDP vs TCP

Firmware
1

I’ve been building electronic race timers for about 4 years now. I developed the system using UDP because:
PROS:

  1. better broadcasting (to exchange IP addresses
  2. unitary send (the message makes it or not; never receive part of a message
  3. If things get gummed up, it’s easier to clean up programmatically

CONS:

  1. a single message can get lost - no resend

Anyone see a reason for me to change from UDP to TCP?

2

If it aint broke don’t fix it :wink:

1 Like
3

Hi,
is that impacting your product in some way? If so, I would run a test with TCP and if it gets fixed, it's a winner.
Cheers

4

If you want to stay with UDP then consider building in an acknowledge/retransmit requirement into your application layer. One side sends data, the other side acknowledges. If an ack is not received within a specified time limit, the sender sends it again. After a few retries, the sender declares the link down.

2 Likes
5

Hello,

Depending on your project, you may need UDP for speed vs TCP for reliability. To Muskie’s point, TCP does have a variety of provisions. Whereas UDP does not have any type of sequencing, acknowledgement, etc.

So, if you’re encountering slow speeds with TCP, UDP may be an alternative but with limitations. It’s a good idea to perhaps map out what you’re trying to do and the potential responses (if any) are needed.

1 Like
6

Thanks all. This reinforced what I was thinking.

The project is a timer. I use a photon to detect a broken IR beam and then send a UDP message to the controller that does the timing and display. So, you are right, the message only has value if it is sent immediately. That favors UDP over TCP. TCP does guarantee message delivery, but at a penalty of time that would not be appropriate for a timer. I could add some UDP response, but since it’s better to absolutely know the message has been lost as the human can tell the timer didn’t start or stop than it is to get an arbitrary delayed message, I’m just going to leave things as they are

One interesting thing is that WiFi isn’t optimized to work outdoors without reflections. The WiFi signal can be blocked by a human body and since there are no reflections in a open field, the timer may not work

7

Would it be possible to synchronise (at start up) the clocks (or at its simplest a usec counter) between main controller and Photon and time stamp message from Photon to controller? Then you could use TCP with its nice built-in retry and acknowledge setup and you would know exactly when the event occurred irrespective of comms retrys or momentary loss.

8

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.