Missing are the exact use cases. For Twine (general purpose IoT monitor from way back), we used UDP for the steady monitoring stream, serving the purposes of a dashboard data stream and keeping the connection open, while saving power. Used TCP just for the events we wanted to be sure got received, but with UDP, Twine still got several 9s of packets getting delivered over the internet.
There are situations where packet loss can be an issue.
In the configurations I have implemented, LAN packet loss is rare. Operations are idempotent and thus can be repeated.
Everybody has their preferences. Personally, I avoid having too many layers and too many intervening abstractions. In my designs, keeping it lean maximizes throughput and simplicity means that I can debug it without tearing out too many hairs. In many projects that I have worked on we spent more time debugging third party modules than the stuff that we designed and implemented.
Comments
Do you do anything to handle packet loss, or operate under the assumption it should be minimal on a LAN?
Missing are the exact use cases. For Twine (general purpose IoT monitor from way back), we used UDP for the steady monitoring stream, serving the purposes of a dashboard data stream and keeping the connection open, while saving power. Used TCP just for the events we wanted to be sure got received, but with UDP, Twine still got several 9s of packets getting delivered over the internet.
There are situations where packet loss can be an issue.
In the configurations I have implemented, LAN packet loss is rare. Operations are idempotent and thus can be repeated.
Everybody has their preferences. Personally, I avoid having too many layers and too many intervening abstractions. In my designs, keeping it lean maximizes throughput and simplicity means that I can debug it without tearing out too many hairs. In many projects that I have worked on we spent more time debugging third party modules than the stuff that we designed and implemented.