4 ms·

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 s

• jfkebwjsbx 7y ago
  It seems to me GP is talking about using TCP, not implementing it.
  • SilasX 7y 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 7y 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 7y 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.
        • Nursie 7y ago
          > which, I would think, would be handled by the TCP library read() You would be wrong.
          • SilasX 7y ago
            Thanks for the explanation, but I don't see why a library utility function wouldn't do that.
            • anonymoushn 7y ago
              Most TCP libraries simply do not come with a function that does "read, but only give me 0 bytes or n bytes, and if you get some other number please hang on to the leftovers until next time". I guess I could follow your advice, but the first step of doing that would be to write such a function again.
              • userbinator 7y ago
                They do... with an option called MSG_WAITALL. That naturally leads to the question of why it's not the default, which can be answered by understanding the history of TCP and computer networking; and more interestingly, how might things have been different if MSG_WAITALL was the default from the beginning.
                • anonymoushn 7y ago
                  I don't think this gets you nonblocking all-or-nothing recv.
            • spydum 7y ago
              But if the goal is to process or retrieve a string of bytes, how do you know when you've got them all? That is the root of the problem: tcp isn't built to exchange messages, it's just the stream transport layer. If you want messages you have to encode and decide that yourself.
    • bavell 7y ago
      If you're using a library, then sure. But if you're just reading from a raw TCP socket, it's just a stream of bytes. It's up to your application to parse those bytes (e.g. into a http request). The OS will buffer bytes received from TCP packets for you until you read from the socket again to drain the buffer. Your application needs to determine how to semantically chop those bytes up into the protocol it's expecting (e.g. http request). My low-level networking chops are a little rusty so please correct my understanding if I'm off-base somewhere.
• deleted 7y ago
  [deleted]