0


I have searched but I could not find the following:
Process1 transmits data over TCP socket. The code that does the transmission is (pseudocode) 

//Section 1
write(sock,data,len);//any language.Just write data
//Section 2

Process1 after the write could continue in section 2, but this does not mean that data has been transmitted. TCP could have buffered the data for later transmission.
Now Process2 is running concurrently with Process1. Both processes try to send data concurrently. I.e. both will have code as above.
Question1: If both processes write data to TCP socket simultaneously how will the data be eventually transmitted over the wire by IP/OS?
a) All data of Process1 followed by all data of Process2 (or reverse) i.e. some FIFO order?
or
b) Data from Process1 & Process2 would be multiplexed by IP layer (or OS) over the wire and would be send "concurrently"?
Question2: If e.g. I added a delay, would I be sure that data from the 2 processes were send serially over the wire (e.g. all data of Process1 followed by all data of Process2)?
UPDATE:
Process1 and Process2 are not parent child. Also they are working on different sockets
Thanks

Cratylus
  • 52,998
  • 69
  • 209
  • 339

4 Answers4

4

Hmm, are you are talking about single socket shared by two processes (like parent and child)? In such a case the data will be buffered in order of output system calls (write(2)s).

If, which is more likely, you are talking about two unrelated TCP sockets in two processes then there's no guarantee of any order in which the data will hit the wire. The reason for that is sockets might be connected to remote points that consume data with different speeds. TCP flow control then makes sure that fast sender does not overwhelm slow receiver.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
2

Answer 1: the order is unspecified, at least on the sockets-supporting OS's that I've seen. Processes 1 & 2 should be designed to cooperate, e.g. by sharing a lock/mutex on the socket.

Answer 2: not if you mean just a fixed-time delay. Instead, have process 1 give a go-ahead signal to process 2, indicating that process 1 has done sending. Use pipes, local sockets, signals, shared memory or whatever your operating system provides in terms of interprocess communication. Only send the signal after "flushing" the socket (which isn't actually flushing).

Community
  • 1
  • 1
Fred Foo
  • 355,277
  • 75
  • 744
  • 836
  • @larsmans: So write, flush, signal.Flushing is guaranteed to transmit all data to destination, or is like e.g. in C++ I/O operations? Only a signal to OS to flush. Not guarantee to happen yet – Cratylus Nov 18 '10 at 22:37
  • That might depend on your OS, but in any case, the data is in the kernel buffer before process 2 starts writing, so that will likely push the data over the wire. – Fred Foo Nov 18 '10 at 22:40
  • @user384706, no, many don't, they just wait for the OS to send data. Enabling TCP_NODELAY (prevent some buffering) is sometimes done to improve performance, though it doesn't always help. – Fred Foo Nov 18 '10 at 22:46
  • @user384706, please read the post I linked to, it explains that there is no flush operation on sockets. – Fred Foo Nov 18 '10 at 22:53
  • @larsmans:I read the link. What do you mean "it explains that there is no flush operation on sockets"? It says that using flush, data in buffer not yet send, are send. How TCP_NODELAY fits in? It does not mention this – Cratylus Nov 19 '10 at 20:21
0

A TCP socket is identified by a tuple that usually is at least (source IP, source port, destination IP, destination port). Different sockets have different identifying tuples.

Now, if you are using the same socket on two processes, it depends on the order of the write(2) calls. But, you should take into account that write(2) may not consume all the data you've passed to it, the send buffer may be full, causing a short write (write()'ing less than asked for, and returning the number of bytes written as return value), causing write() to block/sleep until there is some buffer space, or causing write() to return an EAGAIN/EWOULDBLOCK error (for non-blocking sockets).

ninjalj
  • 42,493
  • 9
  • 106
  • 148
  • I am talking about different socket per process. You mean the process could block, the second start writing and occur the interleaving? – Cratylus Nov 18 '10 at 22:39
  • @user384706: If they are different sockets, it doesn't really matter. Every TCP segment contains the source and destination ports, so even if your TCP/IP stack was sending 1 byte of data at a time there is no possible confussion. – ninjalj Nov 18 '10 at 22:43
  • I know that they can not be mixed. My question is what is the message flow I will see over the wire.Multiplexing or serial transmission? – Cratylus Nov 18 '10 at 22:45
  • @user384706: You never really know. Depends on lots of things, mainly network conditions and OS's TCP/IP stack. – ninjalj Nov 18 '10 at 22:53
0
  1. write() is atomic; ditto send() and friends. Whichever one executed first would transmit all its data while the other one blocks.
  2. The delay is unnecessary, see (1).

EDIT: but if as I now see you are talking about different sockets per process your question seems pointless. There is no way for an application to know how TCP used the network so what does it matter? TCP will transmit in packets of up to an MTU each in whatever order it sees fit.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • You are saying that if Process1 calls write at e.g. timestamp 1:00:00 and Process2 calls write 2 seconds later, it is still not certain if the packets will be multiplexed or the transmission of Process1 would have finished? – Cratylus Nov 19 '10 at 20:08
  • Obviously there is a point with short transmissions or long intervals where the question becomes ridiculous. I still don't know why it matters to you. In a sense the question is *inherently* ridiculous. – user207421 Nov 19 '10 at 23:26