Is there a way to call shutdown(blah, SHUT_WR) on a network SOCK_STREAM
connection's fd without discarding pending output? Or some way to block
until pending output has been acknowledged by the far end? (There's a TCP/IP
acknowledgement packet being sent, I'm fairly certain of this...)
I want the connection at the far end to get EOF from read, but still be able
to send me data back from the other half of the connection.
I've looked at the BSD networking documentation, the source code to "netcat",
all the man pages I could find, asked google, etc. The 2.4.18 net/ipv4/tcp.c
source has some interesting comments (line 396) about poll not having a
notion of HUP in just one direction, but I've gathered that select and poll
behave differently on files, pipes, network sockets, block devices, etc...
In any case, this doesn't help me find an exported user-space API that might
help me implement this behavior. (By the way, is "PULLHUP" on lines 414 and
417 a typo for "POLLHUP", or not?)
There doesn't seem to be any variant of a blocking flush() call on a socket
(that I can find), or a way to tell shutdown() to wait for pending output the
way a normal close() does. (Maybe I can do something fancy with poll or
select?)
If there IS no way to do this, why does shutdown(2) bother taking a second
argument?
(Maybe I can disable nagle and then do a write of length zero, to make the
other end unblock with a read of length zero and THINK the stream's done?
Probably won't work, but it's worth a try...)
Rob
(P.S. yes I can rewrite the protocol being sent over the wire to signal EOF
in-band (yet again) but this keeps coming up over and over. Processes that
work when stdin and stdout are seperate file handles don't work when the data
goes back and forth through a network socket...)
On Thu, 2002-06-06 at 21:19, Rob Landley wrote:
> Is there a way to call shutdown(blah, SHUT_WR) on a network SOCK_STREAM
> connection's fd without discarding pending output?
Just call it. It doesn't discard pending output