131–140 of 247 posts
Earlier quoted context omitted.
> That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format. Neither TCP nor Ethernet provide for forward error correction. Ethernet frames include a 32-bit CRC while TCP segments use the so called "internet checksum".
Cunningham's law at work!
> 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 TCP packet > 6. There is no such thing as a TCP packet I don't understand this at all. Either the concept of a TCP packet exists, or the concept does not exist. Even it's not being used in certain scenarios, I don't see how you can argue that "there's no such t…
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... 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 ap…
This reminds me of a very particular problem that we tried to solve when I worked at VKontakte. It was about instant messaging and flaky mobile data connections. The problem: you're on a subway train and you send a message as it departs a station. The request does get to the server, but by the time the response arrives, the train is already in the tunnel and you don't have a signal any more. So the client thinks that…
> because you don't know the ID of your message yet Wouldn't the client know the ID if they randomly generated it? (honest question)
Earlier quoted context omitted.
Yep, I work on low level networking software professionally and this post is largely meaningless dribble and is probably motivated by grandstanding. It’s like an engineer who says “how does a screen show black” and then says “nope” to every response. It’s maybe a way to make people think, but beyond that the negativity and grandstanding of it is ultimately a turn off for many receivers which eventually either then ha…
Uhhh....how does the screen show black?
I find this "falsehoods programmers believe" format of making pointed claims that you intentionally don't clarify to be unhelpful and obnoxious
I believe the article that started it all is https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-... - crucially every entry is self-explanatory, which is a point that a lot of the subsequent “Falsehood…” list authors miss.
Maybe he’s referring to the fact that some last names are two words (e.g. Marine Le Pen), but I don’t think that’s very common…
Anyway, it could be anything, so I wish he’d said!
> 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 TCP packet > 6. There is no such thing as a TCP packet I don't understand this at all. Either the concept of a TCP packet exists, or the concept does not exist. Even it's not being used in certain scenarios, I don't see how you can argue that "there's no such t…
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.
Earlier quoted context omitted.
5 and 6 are mutually exclusive. They don't make sense logically. And most of the list was never explained at all.
They are not mutually exclusive statements, because they don't exist in isolation: they are both potentially true and false depending on the context of discussion.
Either way, this stuck out to me because usually these type of lists have very simple, understandable statements that just happen to surprise some people by not being true; in this case, the statements themselves are confusing, so I can't really say for certain whether I believe them or not because I don't even know what truth they're asserting to try to negate it.
> 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 TCP packet > 6. There is no such thing as a TCP packet I don't understand this at all. Either the concept of a TCP packet exists, or the concept does not exist. Even it's not being used in certain scenarios, I don't see how you can argue that "there's no such t…
Perhaps it could be rescued by rephrasing them as "is always" versus "is never"?
Has this author never heard of error correcting codes? The whole point of them is to assume there's lossiness and add bytes to allow correction (or at least detection) of tampered or missing bytes. That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format. Additionally, I'm sure they're aware that HTTP over TLS has encrypted data frames, which would be unreceivable in a lot of cases if…
> That's why TCP (or maybe it's Ethernet?) frames include FEC bytes in their message format. Neither TCP nor Ethernet provide for forward error correction. Ethernet frames include a 32-bit CRC while TCP segments use the so called "internet checksum".