0

I screen my linux server program log and I find that some send() function calls return 0.I wanna to know how it happened?And What factors will cause that other than massive data transfers where the other end is not keeping up.

lojunren
  • 139
  • 1
  • 9

1 Answers1

1

What factors will cause that other than massive data transfers where the other end is not keeping up.

That's not one of the factors at all.

I know it usually causes by massive data transfers where the other end is not keeping up.

No it isn't. That only happens in non-blocking mode, and it causes send() to return -1 with 'errno' set to EAGAIN/EWOULDBLOCK.

You are mistaken about this.

send() will return zero if and only if you provide a zero length.

That's what the man page says, and has said since about 1983, and it is mandated by the Posix and Winsock specifications.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • http://stackoverflow.com/questions/3081952/with-c-tcp-sockets-can-send-return-zero – lojunren Feb 24 '14 at 07:35
  • @lojunren That's just another answer at SO, and it doesn't have any more status than this one. I am relying on what it says in the *man* page and indeed the Posix specification. Any other behaviour would be a bug. – user207421 Feb 24 '14 at 07:50
  • send() function returns 0 doesn't mean that an error occur.It may be cause by flow control which is the basic feature of TCP.I wanna to know send() function returns 0 only causes by TCP flow control mechanism? No other possibilities? – lojunren Feb 24 '14 at 08:03
  • @lojunren `send()` returning zero means you supplied a zero length. Period. Not an error, and I didn't state otherwise. Errors are indicated by returning -1. TCP flow control will cause a blocking mode `send()` to block, or a non-blocking `send()` to return `-1/EAGAIN/EWOULDBLOCK.` That's what Posix dictates; it's what the *man* page says; and it's what I said above. It's also consistent with what I have been seeing for about 24 years. I have also given you the only possibility by which `send()` can return zero. – user207421 Feb 24 '14 at 08:37
  • ssize_t send(int sockfd, const void *buf, size_t len, int flags); Actually，before call send() function, I dump the the argument 2 which need to be sent to other end. And I also record the len into my log file.The log indicates that the argument 3 len which I passed into is not 0 and argument 2 buf is not NULL. – lojunren Feb 24 '14 at 09:08
  • You don't need to post the signature of 'send()' here. It's well-known. I've known it since about 1983. What I want to see for anyone who claims that 'send()' returns zero when the length isn't zero is the code, the parameter values and return value produced by it, the operating system name and version, the hardware platform, and a bug report acknowledgement stating that this is a known problem in the implementation. – user207421 Feb 24 '14 at 09:12
  • So post the code. BTW that means edit it into your question. Also as much of the other information I mentioned as you have. – user207421 Feb 24 '14 at 09:14
  • According to company policy，I cannot post code.Thanks for your patience. – lojunren Feb 24 '14 at 09:30
  • @EJP: Technically, you could get a partial write of 0 bytes. – ninjalj Feb 24 '14 at 11:39
  • Under Linux, it shouldn't happen. `tcp_sendmsg()` should never return 0. – ninjalj Feb 24 '14 at 16:20