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.
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.
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
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.