0

If wanting to use UDP for performance over TCP, is there something which can act as an intermediary on the sender side and receiver side where packets are fed to it and it sends them over UDP but also handles error correction / retransmission?

The idea here is to be able to use an existing UDP-based protocol without having to program error correction / retransmission at the application level. For example start this intermediary software on the local endpoint and the remote endpoint and the traditional application connects to localhost and a port which that software is listening on, and then it gets transmitted to the other end.

g491
  • 973
  • 1
    If you add TCP features, then you get TCP performance. The speed of getting data from one side to the other is the same for TCP and UDP, but it is things like acknowledgement and retransmission of lost data, the reordering of out-of-order data before presenting it to the application, and congestion control to try to minimize lost data that make TCP reliable, and TCP is tuned very well for that. If you add that back into the path, then you have gained nothing. UDP seems fast because it sends data with no expectation that it is ever received. The sender is unaware of path problems, just sends. – Ron Maupin Nov 06 '19 at 23:36
  • If you move the TCP features further out in the path, then the sender may finish sending sooner, but the receiver gets it no faster than with TCP. Programmers often try to recreate TCP using UDP, but usually fail miserably because decades of experience have TCP running very efficiently. – Ron Maupin Nov 06 '19 at 23:39
  • 1
    "The idea here is to be able to use an existing UDP-based protocol without having to program error correction / retransmission at the application level." That's what TCP does, takes the burden of that off the application. The features do not come free, they can give you a performance hit, but you get that hit, either from TCP, or from whatever else you use to replace it. – Ron Maupin Nov 06 '19 at 23:41

1 Answers1

2

UDP just blindly sends datagrams. It does not have congestion control, retransmission, or the concept of a stream. Any implementation of those features would be effectively reimplmenting TCP and have to solve the same problems. There would be at least some overhead.

Other transports than TCP or UDP exist. SCTP for example. However, its not clear these would have any performance advantage. Further, support by network and software stacks is not nearly as ubiquitous as TCP.

Several transports over UDP have been invented. QUIC being a popular one.

Define how you find TCP to be a performance hit by studying your TCP flows in detail. TCP is mature and well studied. Take advantage of that experience and tooling to either optimize it, or learn what you actually want from your transport.

John Mahowald
  • 33,256
  • 2
  • 21
  • 39