ansaurus

Question

Answer 1

A:

No. And you don't need to do this.

Steven Sudit 2010-07-08 17:11:58

So if I send a large packet and then a smaller one, will tcp send the small while it is still sending the large one?

2010-07-08 17:14:10

TCP is just a stream, if you do one send() call, it might take multiple recv() calls to read that data on the other side. Conversely, several send() calls might be merged, and read with one recv() calls. You have to build your own protocol on top of TCP if you want to send "packets", or get a reply when a packet/message has been received.

nos 2010-07-08 17:16:27

Are you sure? I thought the point of tcp is that it does that kind of management for you. I have never had a time were sending multiple packets at once will get merged into 1 when being received.

2010-07-08 17:29:44

Ben's suggestion is right: With two connections, one will not be significantly blocked due to traffic on the other. With just one, the short message will not be received until the long one is.

Steven Sudit 2010-07-08 17:30:19

send calls will never be merged; one call to recv will only read as much as was sent with one call to send.

brone 2010-07-08 17:36:21

@brone: I've seen what nos explains in action. What is sent is both merged with other `send` s and split into several `recv` s

Default 2010-07-08 17:46:56

@brone: `send` calls definitely can be merged, it's called Nagle's algorithm. http://en.wikipedia.org/wiki/Nagles_algorithm

Ben Voigt 2010-07-08 18:00:23

@high6: Michael suggested a reasonable way to make this stream protocol work a bit more like one that respects packets, but you could also use UDP instead of TCP. Even then, things can happen en-route.

Steven Sudit 2010-07-08 18:09:09

@brone, you are wrong, TCP does not preserve write/send boundaries. TCP provides a byte stream, not packets/messages.

nos 2010-07-08 19:37:54

@nos: Do you have an example of this happening? Cause I tried sending a ton of 1 byte packets and it still received them 1 at a time even when the buffer was large enough to fit them all.

2010-07-08 21:15:16

My evidence was http://msdn.microsoft.com/en-us/library/ms740121(VS.85).aspx -- see comment for the MSG_PEEK flag, though it's not exactly a model of clarity. I was under the impression this was standard SOCK_STREAM behaviour, and not some Winsock thing, because it's potentially useful, but http://www.opengroup.org/onlinepubs/009695399/functions/recv.html suggests not. (The docs imply that send may not send all of the data anyway, though maybe that's only for non-blocking sockets -- that's probably why.)

brone 2010-07-08 23:11:28

Multiple send() calls CAN be merged together into larger transmission blocks (Nagle), it MAY take multiple send() calls to send a large amount of data, and it CAN take multiple recv() calls to read a single block of data. You definately DO need an application-level protocol in your data to detect the boundaries between messages (which are an appliation-level concept anyway, not a socket concept - at least for TCP). I have also seen this in action many times before. Most major socket libraries I have seen are coded to account for both conditions, because they DO happen.

Remy Lebeau - TeamB 2010-07-13 01:33:53

Answer 2

A:

I am not sure what we would acheive with this.. Mixing traffic on TCP stream won't server any purpose.. Can you explain what exactly u need to do.. Above all, we can never be sure in TCP that the other application has actually received the pkt (it might just be in their tcp buffers)...

Krishna 2010-07-08 17:16:21

Answer 3

+2 A:

Just use two separate TCP connections. They can even connect to the same host and port, the port number at your end will be different.

Stop-and-wait handshaking over any network (i.e. not loopback) would be miserably slow.

Ben Voigt 2010-07-08 17:25:22

+1 for pointing out the two-connection solution.

Steven Sudit 2010-07-08 17:30:51

or maybe _n_ separate connections.. :) +1 for multiple connections however

Default 2010-07-08 17:48:55

Answer 4

+1 A:

You could send the size of your packages instead

struct MyNetworkPackage {
    int size;
    char* data;
};

if you begin by sending the size, you can deduce on the other side what data belongs to what package.
I've tried to explain winsock in this answer as well.

Default 2010-07-08 17:36:04

Answer 5

A:

It seems that 'send' will block if there is a previous packet still being sent.

2010-07-09 10:40:24

ansaurus

tags:

views:

answers:

Have winsock's send function block?

related questions