3 ms·

TCP is like automated driving or a taxi. you get in your car, tell it the destination, and it takes you there. UDP is driving yourself. you have to adjust the

by em-bee 3y ago

TCP is like automated driving or a taxi. you get in your car, tell it the destination, and it takes you there. UDP is driving yourself. you have to adjust the speed and direction as you go. if you go to fast accidents can happen. so obviously, when using UDP you have to add safeguards against attacks, but, you get more flexibility to adjust things along the way. you are not locked into the way TCP does it, and that is the benefit of creating a UDP based protocol instead of just using TCP. TCP is not built on top of UDP, but i think it could be: https://stackoverflow.com/questions/10680592/can-tcp-be-implemented-via-udp https://stackoverflow.com/questions/10680592/can-tcp-be-impl... and it is a good idea to not just use UDP blindly, but implement the necessary saveguards on top of it. but claiming that all UDP based protocols are bad because of UDP is like saying, cars are bad because of bad drivers. (well, they are, but that's a different topic) so UDP based protocols aren't bad. only using UDP without safeguards is bad.

rixrax 3y ago
This is a bit similar to roll your own crypto conversation. It is fun, and a great way to learn. And once done, you should do well to never deploy your own crypto in any real life application. Friends don't let (or shouldn't at least) friends roll their own protocol over UDP either (or IP; I mean why not?). There are very few apps that have such an explicit requirements that they can't do away with TLS over any number (==2) of existing, and well known transport protocols (e.g. TCP, maybe QUIC). For presentation layer, instead of implementing their own spec, most should probably stick to Protobuf[0] (or some of it's derivatives[1]), and encode the application data into JSON. Check. Protocol design done. [0] https://protobuf.dev https://protobuf.dev [1] https://capnproto.org https://capnproto.org
- em-bee 3y ago
  i don't quite agree because there are legitimate uses for UDP, but there are no legitimate uses for hand rolled crypto (except learning). also the issues with UDP mentioned in the article can easily be mitigated, which is not at all true for issues with hand rolled crypto. and there is one important use for UDP that is not well served with TCP or QUIC, which is tunneling. tunneling TCP over TCP does not work very well. also, the feature of mosh to keep a connection alive over network changes may not be easy to implement over TCP, i am not sure.

by em-bee 3y ago

rixrax 3y ago

This is a bit similar to roll your own crypto conversation. It is fun, and a great way to learn. And once done, you should do well to never deploy your own crypto in any real life application. Friends don't let (or shouldn't at least) friends roll their own protocol over UDP either (or IP; I mean why not?). There are very few apps that have such an explicit requirements that they can't do away with TLS over any number (==2) of existing, and well known transport protocols (e.g. TCP, maybe QUIC). For presentation layer, instead of implementing their own spec, most should probably stick to Protobuf[0] (or some of it's derivatives[1]), and encode the application data into JSON. Check. Protocol design done. [0] https://protobuf.dev https://protobuf.dev [1] https://capnproto.org https://capnproto.org

em-bee 3y ago
i don't quite agree because there are legitimate uses for UDP, but there are no legitimate uses for hand rolled crypto (except learning). also the issues with UDP mentioned in the article can easily be mitigated, which is not at all true for issues with hand rolled crypto. and there is one important use for UDP that is not well served with TCP or QUIC, which is tunneling. tunneling TCP over TCP does not work very well. also, the feature of mosh to keep a connection alive over network changes may not be easy to implement over TCP, i am not sure.