6 ms·

> What they mostly should know: TCP provides a bidirectional stream of bytes on the application level. It does NOT provide a stream of packets. > That means

> What they mostly should know: TCP provides a bidirectional stream of bytes on the application level. It does NOT provide a stream of packets. > That means whatever you pass to a send() call is not necessarily the same amount of data the receiver will observe in a single read() call. Yes, this. For god's sake, listen to them. I had to fight a coworker on this. I had quickly created some client code just to validate that the server was working. Due to some quirk, all the messages were arriving in full in every read call. He told me to ship it. I said no! "I need to check if there's more data and if so add a loop to read again" "But it is working, release it". That went on for a while, to no avail. Wouldn't look at documentation either. Eventually he head to leave for the day, and I took the time to implement it correctly. I started including basic TCP questions on interviews. Not many people even get past the TCP handshake (if they even know about that).

Ididntdothis 6y ago
"But it is working, release it". Famous last words :-)
- austincheney 6y ago
  Sounds like how most software handles security until it’s audited.
scott_s 6y ago
The problem here was not a lack of knowledge of a particular subject. The problem is that this person was unwilling to learn about a thing they thought they knew.
- draw_down 6y ago
  That's correct.
SilasX 6y ago
Stupid question: why would you be writing code that works at the level of TCP? Don't you usually want to use the OS's (or some popular library's) TCP software stack?
- jfkebwjsbx 6y ago
  It seems to me GP is talking about using TCP, not implementing it.
  - SilasX 6y ago
    Right, I mean I thought that the TCP protocol implementation itself handled that issue, and your calls to such a library abstracted away from that.
    - jacobolus 6y ago
      No, it does not, by design. When you use any standard TCP implementation the abstraction provided at both ends is just a stream of bytes. The guarantee TCP makes is that the bytes received at one end will be in the same order as the bytes that were sent at the other end. If you want to use TCP to implement some (higher-level) message-based protocol, you need to parse those out for yourself.
      - SilasX 6y ago
        The original question didn't refer to such issues of parsing, just checking for whether the full message was received, which, I would think, would be handled by the TCP library read() (or whatever) call. It sounded like the OP (outworlder) was delving into lower-level TCP details that should have been abstracted away -- my thinking is that the TCP caller shouldn't have to concern itself with details about checking whether the full message has been received, at least not as a separate step. That is, it just wouldn't return anything until the full message is received, or would include some data structure that indicates it's not complete. Does that make sense? Edit: On second thought, I guess OP meant that all of the results were coming back "complete" which doesn't obviate the issue of needing to do a check that handles the "not done" case.
caseymarquis 6y ago
I feel like I can Google all the syn/ack/packetsniffing bits when those come up during troubleshooting (Why is this disconnecting? What do you mean the gateway sends out rst packets when there's no activity for 5 minutes?!?). Seems a bit harsh to start with those. The guarantees about the protocol are the important part, the rest seems kind of superfluous unless there's an unusual problem or you're pushing the limits of a network.
- dharmab 6y ago
  I've personally been on many outage troubleshooting calls that cost hundreds of thousands of dollars precisely because engineers believed they could ignore the underlying details and corner cases of TCP. My favorite common mistake is that developers assume they can open a single connection with no retries and that connection will be reliable as long as the handshake succeeds.
lalaland1125 6y ago
Unless you are writing TCP drivers I don't see how knowing the exact TCP handshake is useful for software development.
Dylan16807 6y ago
> the rest of the conversation seemed to be assuming that "whether you have received the full message" is well-defined at the level of TCP I don't see anything in the comment you linked that implies that. Sorry you got confused, but there's no need for anyone to go reply to that comment to say so.

Ididntdothis 6y ago

"But it is working, release it". Famous last words :-)

austincheney 6y ago
Sounds like how most software handles security until it’s audited.

scott_s 6y ago

The problem here was not a lack of knowledge of a particular subject. The problem is that this person was unwilling to learn about a thing they thought they knew.

draw_down 6y ago
That's correct.

SilasX 6y ago

Stupid question: why would you be writing code that works at the level of TCP? Don't you usually want to use the OS's (or some popular library's) TCP software stack?

jfkebwjsbx 6y ago
It seems to me GP is talking about using TCP, not implementing it.
- SilasX 6y ago
  Right, I mean I thought that the TCP protocol implementation itself handled that issue, and your calls to such a library abstracted away from that.
  - jacobolus 6y ago
    No, it does not, by design. When you use any standard TCP implementation the abstraction provided at both ends is just a stream of bytes. The guarantee TCP makes is that the bytes received at one end will be in the same order as the bytes that were sent at the other end. If you want to use TCP to implement some (higher-level) message-based protocol, you need to parse those out for yourself.
    - SilasX 6y ago
      The original question didn't refer to such issues of parsing, just checking for whether the full message was received, which, I would think, would be handled by the TCP library read() (or whatever) call. It sounded like the OP (outworlder) was delving into lower-level TCP details that should have been abstracted away -- my thinking is that the TCP caller shouldn't have to concern itself with details about checking whether the full message has been received, at least not as a separate step. That is, it just wouldn't return anything until the full message is received, or would include some data structure that indicates it's not complete. Does that make sense? Edit: On second thought, I guess OP meant that all of the results were coming back "complete" which doesn't obviate the issue of needing to do a check that handles the "not done" case.

caseymarquis 6y ago

I feel like I can Google all the syn/ack/packetsniffing bits when those come up during troubleshooting (Why is this disconnecting? What do you mean the gateway sends out rst packets when there's no activity for 5 minutes?!?). Seems a bit harsh to start with those. The guarantees about the protocol are the important part, the rest seems kind of superfluous unless there's an unusual problem or you're pushing the limits of a network.

dharmab 6y ago
I've personally been on many outage troubleshooting calls that cost hundreds of thousands of dollars precisely because engineers believed they could ignore the underlying details and corner cases of TCP. My favorite common mistake is that developers assume they can open a single connection with no retries and that connection will be reliable as long as the handshake succeeds.

lalaland1125 6y ago

Unless you are writing TCP drivers I don't see how knowing the exact TCP handshake is useful for software development.

Dylan16807 6y ago

> the rest of the conversation seemed to be assuming that "whether you have received the full message" is well-defined at the level of TCP I don't see anything in the comment you linked that implies that. Sorry you got confused, but there's no need for anyone to go reply to that comment to say so.