6 ms·

> remember, all of the following statements are false at least some of the time, but for some of these, perhaps not very often > 5. There is a such thing as a

• deathanatos 2y ago
  Yeah, I agree with you here. I think the thing most related to that that I see people thinking is that send(2) & recv(2) calls translate 1:1 with packets send/recv. I.e., that they don't understand that the interface TCP exposes to applications is a byte stream. Which then results in things like thinking recv(2) will receive a complete "message" for some definition of message in the application protocol (i.e., the mistake belief that fragmentation won't happen).
• abnry 2y ago
  My only guess how this could make sense is if there is some ambiguity in the definition of a TCP packet.
• o11c 2y ago
  What it really means is: Packets have well-defined boundaries between sufficiently-adjacent nodes. They are not guaranteed to keep those boundaries end-to-end over arbitrary middleware.
• marcosdumay 2y ago
  It's about your abstraction level and the kinds of problem you are ignoring. It's true at the same time that you can't ignore the problems of stream communication nor the problems of package-based communication.
• jpollock 2y ago
  If I had to guess, it would be an assumption that TCP was edge to edge with no translation in the middle. My guess is that this is talking about systems in the middle of the network, changing (for example) their sizes by combining and splitting packets to fit through various transits.
• fracus 2y ago
  5 and 6 are mutually exclusive. They don't make sense logically. And most of the list was never explained at all.
  • ordu 2y ago
    > They don't make sense logically In practice such situations can arise in one of two cases: 1. some non-sense creeped in 2. logic is applied to a self-contradictory set of axioms and definitions. (1) is not very interesting, but (2) happens frequently enough because people often do not try to formalize their definitions and axioms. As a consequence they are using some vague concepts and their statements are true in some cases but not in others. With all that said, I can propose the way how this logical non-sense could be right. (NB. I don't know if it applies to TCP, I'm just thinking generally, and just as an example to all that abstract words above) The notion of "existence" of the mistaken programmer can be wrong. If we accept their definition of existence, then TCP packets doesn't exist, but they exist in some other sense.
    • astrobe_ 2y ago
      Yes. If one applies correctly the rules of logic on inconsistent axioms, the conclusions will be inconsistent. If one incorrectly applies logic to inconsistent axioms, the conclusions may or may not be consistent. It happens IRL sometimes; "being right for the wrong reasons". That being said, I suspect the game of the author is to play with leaky abstractions. TCP is a stream-oriented protocol, but is implemented on top of frames etc.
  • alephnerd 2y ago
    The point is that a lot of stuff in Networking (and Computer Engineering in general) is very context dependent, and that you cannot be extremely opinionated about this stuff.
    • fracus 2y ago
      No context was ever provided.
  • 2y ago
• ooterness 2y ago
  Pedantically: TCP has segments, IP has packets, and Ethernet has frames. They are one-to-one in simple cases, but not always. https://networkengineering.stackexchange.com/questions/50083/ https://networkengineering.stackexchange.com/questions/50083... In particular, fragmentation by intermediate routers means that the server and receiver may disagree about the frame and packet boundaries. TCP is expected to make a "reliable" pipe-like service out of whatever happens, and the application layer doesn't have (shouldn't need?) visibility into that process.
  • LudwigNagasena 2y ago
    Falsehoods programmers believe: TCP/IP can be coherently mapped to the OSI model.
    • Rauchg 2y ago
      Falsehoods programmers believe: the OSI model
      • fanf2 2y ago
        Yep. https://dotat.at/@/2024-03-26-iso-osi-usw.html https://dotat.at/@/2024-03-26-iso-osi-usw.html
      • devman0 2y ago
        Falsehoods programmers believe: the OSI model is useless
        • akira2501 2y ago
          It's useful. It's not controlling.
        • jerf 2y ago
          Sure, it's misleading, needs a lot of "interpretation" doing a non-trivial amount of the lifting to make it map to anything in the real world, mismatches things that happen in the real world while leaving no room for other things that happen in the real world a lot, and will lead anyone who tries to use it to understand the real world deeply astray, but it isn't always wrong about absolutely everything so it has some non-zero "utility". Fine. It's not wrong about absolutely everything all the time. It isn't bereft of all truth. It's just something that is of net negative value. I see no value in insisting on trying to "rescue" a net-negative value model of the world. I suppose you could say ultimately I agree with you though. The OSI model isn't useless. It's worse than useless. You're better off trying to understand networking from basic first principles than through the lens it provides.
• gwbas1c 2y ago
  > 6. There is no such thing as a TCP packet Because the software abstraction is a stream of bytes; and it's up to the application to decide where the "packets" begin and end. For example, I might write to a TCP socket: 100 bytes, 50 bytes, and then 125 bytes. BUT, the receiver could get: A single event with 275 bytes. Or it could get an event with 75 bytes and then an event with 200 bytes. Or it could get 11 events of 25 bytes. > 5. There is a such thing as a TCP packet This one I struggle with. I think the author is talking about connection set up, acking, and connection teardown.
  • sixfiveotwo 2y ago
    If you have a look at the underlying network traffic, you'll see IP packets carrying TCP data, ie. The protocol field in the IP packet header will be set to TCP; this could be assimilated to a TCP packet.
    • sixfiveotwo 2y ago
      Well, maybe...
• Terr_ 2y ago
  Perhaps it could be rescued by rephrasing them as "is always" versus "is never"?
  • saghm 2y ago
    This doesn't really change my reading of those statements; the issue to me is that "there is such a thing as X" sounds to me like an existential proposition, i.e. "X exists". The idea that an abstract descriptive concept only sometimes exists doesn't really make sense to me; it sounds like saying that addition only "sometimes" exists because there are equations that only use division and not addition.
• fanf2 2y ago
  I guess it’s talking about how the TCP data stream is segmented into IP packets. From the IP point of view, there are packets; from the application point of view there is a data stream; but it’s more complicated than that. Applications have some control over when TCP’s PSH flag is set, roughly speaking, at the end of each write(); and that in turn affects segmentation because small pushed writes cause small packets. But if the sender can’t send straight away then buffered data doesn’t preserve write() boundaries and will be sent with large packets.
  • paulddraper 2y ago
    I think we're talking about different things. TCP is a protocol that most certainly has packets ("segments"). You are taking about a SOCK_STREAM-like programming interface, which can be used to create TCP connections.
• loopdoend 2y ago
  It exists but more as a TCP stream, which is broadcast as packets...
  • Ekaros 2y ago
    Unicast. Unless we are talking about wifi... Which gets to very similar context based mess.
• strken 2y ago
  This one feels like the list-maker is struggling to communicate with me rather than telling me a surprising truth. I can't tell whether it's meant to mean "a TCP segment won't always fit 1:1 into an IP packet (but in the real world they mostly do)", "TCP has segments instead of packets (but everyone knows what you mean when you say TCP packet)", or something else entirely.
  • saghm 2y ago
    Yeah, that's basically the takeaway I had (and I failed to summarize as concisely, ironically enough). It seemed like there was some insight there, but I had absolutely no clue what it was.
• theandrewbailey 2y ago
  It sounds like TCP is totally fucked and useless. It needs to be depreciated immediately and replaced with something better and more intuitive from a programming perspective. Maybe someone at Apple or Google is working on it lol.
• m3047 2y ago
  If what was originally a packet is fragged, the TCP headers may (likely) not be in all the frags. So if you're looking with wireshark and you think you can filter with TCP flags good for you, 90% of the world feels that way. I work with DNS a lot and when a protocol which is datagram-oriented is translated to a stream-oriented medium and somebody wants to potentially handle multiple requests in that stream because "efficiency"... it's so important... they need a way to distinguish those embedded datagrams: "we should do it they way they did in HTTP, with a Content-Length: header, yea THAT's the ticket!" I'm sure that's what they were thinking. Then along come the 90% and when they try to process DNS requests in TCP streams it's "what's this two bytes in front of the request? I dunno, but I just skip over it" and I suppose it works well enough, because with frags they'll drop the tail of the requests because "corruption" anyways, and who on earth sends multiple requests in a single packet, amiright? You may think I'm kidding, but here's some really clever (really!) eBPF code: https://gist.github.com/oghie/b4e3accf1f87afcb939f884723e2b462#file-final_code_ebpf_dns-py-L304 https://gist.github.com/oghie/b4e3accf1f87afcb939f884723e2b4... If you want more on this topic: http://consulting.m3047.net/dubai-letters/dnstap-vs-pcap.html http://consulting.m3047.net/dubai-letters/dnstap-vs-pcap.htm...
• dathinab 2y ago
  It's a typical problem of this lists they don't always point to the underlying issue they want to list. 5.,6. are likely about how all kinds of things infer with your packages mainly merging/splitting but also potentially messing with them in other ways (and in general the package->frame mapping). So if you want to build anything which relies on TCP packages being a thing it likely will not work, at the same time you can't always ignore package size either (e.g. for flushing byte streams, higher level protocol chunking etc.). Through as long as you don't create transport protocols write a network stack or fine tune your TCP stack or similar you likely don't have to care about it. I mean you also probably shouldn't use TCP directly but something more high level in most situations (e.g. HTTP, gRPC, etc.).