3 ms·

I see why it appears that way, but I wasn't trying to suggest that reliability was the only distinction. However, I'm not sure I see such a fundamental distinct

I see why it appears that way, but I wasn't trying to suggest that reliability was the only distinction. However, I'm not sure I see such a fundamental distinction between the two that requires these to be two separate protocols. I can imagine parameters like "max wait time allowed before packet is skipped", "max contiguous packets allowed to be skipped", "whether to deliver packets that arrive out of order", stuff like that. Because ultimately TCP is at the extreme of retrying forever until every byte is received in order (or, well, until a timeout happens and we give up), and UDP is at the extreme of not retrying at all. It shouldn't be that bad to interpolate between the two I think?

busterarm 10y ago
The tunability aspect of your idea scares me a little. When you choose TCP or UDP, you are making some guarantees about how the connection is going to behave. My fear here is that you lose those guarantees once you allow configuration of the connection using your one protocol. ...And while sure, you can have that negotiated when the connection is set up, there would be nothing from preventing one side of the connection from fudging/cheating/outright lying. I wouldn't put that past people at all -- especially networking hardware vendors. Any attempt you would implement to mitigate this just adds unnecessary data transmission overhead.
- wfunction 10y ago
  > When you choose TCP or UDP, you are making some guarantees about how the connection is going to behave. Huh? With UDP, the thing missing is a guarantee about how the connection is going to behave (assuming you call it a "connection" in the first place). I'm just talking about interpolating between guarantees and no guarantees.
  - djrogers 10y ago
    > With UDP, the thing missing is a guarantee Not so - with UDP I know that the endpoint won't discard packets that arrive out of order, and won't bother me with retrans requests for stale packets that didn't arrive... different priorities, different kinds of 'guarantees'
nrjdhsbsid 10y ago
You can configure retries in TCP. There's a ton of differences in how they're implemented underneath, merging them might be possible but you would probably end up with something that was worse for streams than TCP and worse for datagrams than UDP even if it could do both. There's three different retry strategies in TCP I know of. Like 7 or 8 popular congestion control algorithms, many types of queuing disciplines. Some fundamental differences like the SYN/ACK handshake, SYN cookies, state table conntrack, packet sequencing stuff. Tcp slow start and windows. Tons of optional features. The TCP stack of any newer OS is monstrous. A lot of kernel devs would cringe at the thought of adding more to that :)
- wfunction 10y ago
  > You can configure retries in TCP. There's a ton of differences in how they're implemented underneath, merging them might be possible but you would probably end up with something that was worse for streams than TCP and worse for datagrams than UDP even if it could do both. I don't think that's the same kind of retry as the one I'm talking about. In TCP, no matter what the retry algorithm is, TCP has to deliver data in order. Whereas I'm talking about being able to tune how much you're willing to retry receiving the data until you give up and return it to the caller out of order. It's not about the algorithm so much as the resulting semantics.

busterarm 10y ago

The tunability aspect of your idea scares me a little. When you choose TCP or UDP, you are making some guarantees about how the connection is going to behave. My fear here is that you lose those guarantees once you allow configuration of the connection using your one protocol. ...And while sure, you can have that negotiated when the connection is set up, there would be nothing from preventing one side of the connection from fudging/cheating/outright lying. I wouldn't put that past people at all -- especially networking hardware vendors. Any attempt you would implement to mitigate this just adds unnecessary data transmission overhead.

wfunction 10y ago
> When you choose TCP or UDP, you are making some guarantees about how the connection is going to behave. Huh? With UDP, the thing missing is a guarantee about how the connection is going to behave (assuming you call it a "connection" in the first place). I'm just talking about interpolating between guarantees and no guarantees.
- djrogers 10y ago
  > With UDP, the thing missing is a guarantee Not so - with UDP I know that the endpoint won't discard packets that arrive out of order, and won't bother me with retrans requests for stale packets that didn't arrive... different priorities, different kinds of 'guarantees'

nrjdhsbsid 10y ago

You can configure retries in TCP. There's a ton of differences in how they're implemented underneath, merging them might be possible but you would probably end up with something that was worse for streams than TCP and worse for datagrams than UDP even if it could do both. There's three different retry strategies in TCP I know of. Like 7 or 8 popular congestion control algorithms, many types of queuing disciplines. Some fundamental differences like the SYN/ACK handshake, SYN cookies, state table conntrack, packet sequencing stuff. Tcp slow start and windows. Tons of optional features. The TCP stack of any newer OS is monstrous. A lot of kernel devs would cringe at the thought of adding more to that :)

wfunction 10y ago
> You can configure retries in TCP. There's a ton of differences in how they're implemented underneath, merging them might be possible but you would probably end up with something that was worse for streams than TCP and worse for datagrams than UDP even if it could do both. I don't think that's the same kind of retry as the one I'm talking about. In TCP, no matter what the retry algorithm is, TCP has to deliver data in order. Whereas I'm talking about being able to tune how much you're willing to retry receiving the data until you give up and return it to the caller out of order. It's not about the algorithm so much as the resulting semantics.