For TCP, does returning from "write()" mean that the peer app has "read()" the data?

pynexj Source

I'm writing a C/S program and both the client and server may send data to peer (without explicit ack) at arbitrary time. I'm wondering if it could possibly deadlock if the client and server coincidentally write to the peer at the same time.

So does returning from write() mean that the peer application has already read() the data? Or it only means the peer's kernel has got the data and would deliver to the app on next read()?


(EJP's answer fixed my totally wrong understanding about write()/send()/.... To add some authoritative info I found this in the POSIX standard about send:

Successful completion of a call to send() does not guarantee delivery of the message. A return value of -1 indicates only locally-detected errors.

Linux's man page about send() is not very clear:

No indication of failure to deliver is implicit in a send(). Locally detected errors are indicated by a return value of -1.

Or it's because I cannot fully understand the first sentence as a non native English speaker. )

csocketstcpnetwork-programming

Answers

answered 3 months ago paxdiablo #1

No. If you think of it as a data pipe, returning from write means that your data has entered the pipe, not that it has exited the pipe at the other end.

In fact, since the pipe is one where the data may take any of hundreds of different pathways, you're not even guaranteed that it will reach the other end :-) If that happens, you'll be notified about it at some later date, probably by a subsequent write failing.

It may be blocked:

  • trying to exit your machine due to a broken cable,
  • at a bottleneck in the path somewhere,
  • by the networking stack at the destination,
  • by a networking stack at some device in the networking path, more intelligent than a simple hub,
  • because the application at the other end is otherwise tied up,
  • and so on.

A successful return from write means that your local network stack has accepted your data and will process it in due course.

answered 3 months ago EJP #2

I'm wondering if it could possibly deadlock if the client and server coincidentally write to the peer at the same time.

It can't, unless one or both of the peers is very slow reading and has closed its receive window. TCP is full-duplex.

So does returning from write() mean that the peer application has already read() the data?

No.

Or it only means the peer's kernel has got the data and would deliver to the app on next read()?

No.

It means the data has reached your kernel, and is queued for transmission.

the returning from write() means the TCP ACK has already been received.

No it doesn't.

u mean returning from write() only means the data has reached the sender's kernel?

That is not only what I meant, it is what I said.

I'd think the sender's already received the TCP ACK so reached the peer's kernel.

No.

comments powered by Disqus