5 ms·
> IP does not bother with buffering Did you mean UDP? But even if so, this description overall seems way off in the weeds.
by sk5t 7y ago
> IP does not bother with buffering
Did you mean UDP? But even if so, this description overall seems way off in the weeds.
- detaro 7y agoTCP is not based on UDP, so that would not make sense at all. The parent describes it quite accurately: IP makes no guarantee on delivery and allows dropping packets, TCP promises to fix that on a higher level for applications that need it.
- sk5t 7y agoNobody's claiming TCP/IP to be based on UDP/IP. I mean to suggest that buffering isn't a proper feature distinction between TCP and unreliable protocols. Separately, it seems a tad obscure to use IP as the exemplar here--doesn't most everyone want UDP features on top?
- ncmncm 7y agoHardly anybody relies on any of the extras UDP provides, so they are typically just wasted overhead. But user-level libraries offer UDP, so that is what people use.
- kragen 7y agoI've never seen a UDP application that didn't depend on port numbers, which are an extra UDP provides.
- MaxBarraclough 7y ago> the extras UDP provides Like what? UDP is lightweight and bare-bones, no?
- ncmncm 7y agoIt adds source and destination ports and a checksum. Computing the checksum is a nuisance, and it is usually inadequate, so it is allowed to be zero in IPV4, but not IPV6. Normally, if you need a checksum, you need one that cannot be forged, and you need more than 16 bits. So the L3 one is just overhead. I have never seen an actual use of UDP that looked at the port numbers, although firewalls often use them for filtering.
- detaro 7y agoName a few UDP-based protocols whose implementations do not listen to only a specific port number, or a rely on port numbers established as part of the protocol flow, then?
- MaxBarraclough 7y ago> Computing the checksum is a nuisance, and it is usually inadequate, so it is allowed to be zero in IPV4, but not IPV6. If IPv6 disallows simpy zeroing the field, that sounds like it's not just a nuisance. > I have never seen an actual use of UDP that looked at the port numbers, although firewalls often use them for filtering. I don't know what you're saying here. UDP's ports model isn't optional in any sense, it's just like TCP's. If you run several UDP-based services on your server, port numbers are how the server knows which packets are destined for which processes.
- ncmncm 7y agoOK. Too much time spent in kernel-bypass coding. But the checksum is very anemic, inadequate when correctness matters.
- ncmncm 7y agoUDP copies IP behavior up the chain. To be clear: every intermediate router is expected to implement only IP, and completely ignore UDP or TCP. Each discards packets freely. (Router buyers have taken up violating the design, and meddling with TCP along the route. Yet, the point stands.)
- sk5t 7y agoIt's the word "buffer" that threw me. Like, the buffer is a concept on the sending or receiving system and a separate concern from the protocol. That said I am certainly open to learning something new about TCP/IP today.
- codebje 7y agoThe buffer you're thinking of is a packet-level queue to allow mismatches between physical transmission rates and processing rates, and is separate from the protocol. The buffer the original comment is talking about is likely the TCP receive buffer, which is used both to allow the application layer to process bytes at its leisure rather than as they arrive, and to allow out-of-order data to be reassembled correctly rather than retransmitted in-order every time. The receive buffer is documented at the protocol level. Well, honestly I don't recall if the buffer is ever documented in the spec or just common implementation practice. There is a documented "receive window" though, which is how many bytes the receiver is comfortable having "in flight" - sent but not acknowledged. The existence of this window implies the existence of a buffer at least as large as that window on the receiver.