Conversation with #inferno at Fri Sep 2 18:10:04 2011 on powerman-asdf@irc.freenode.net (irc) (20:14:08) bvalek2 left the room (quit: Quit: be right back). (20:52:50) Fish- [~Fish@9fans.fr] entered the room. (20:53:59) bvalek2 [50bbc636@gateway/web/freenode/ip.80.187.198.54] entered the room. (22:38:35) bvalek2 left the room (quit: Quit: Page closed). (23:49:43) fgudin [~none@digi00070.digicube.fr] entered the room. (00:28:10) Fish- left the room (quit: Quit: WeeChat 0.3.5). (04:42:58) powerman-asdf: sorry for probably silly question (I'm ill and think slowly now) (04:43:24) powerman-asdf: we've tcp server S, which listen/accept clients, and then in a loop send data to clients (04:43:34) powerman-asdf: S doesn't try to read from clients (04:43:55) powerman-asdf: now, we've client C, who connects to S and start receiving data (04:44:01) powerman-asdf: for now everything is ok (04:44:18) powerman-asdf: next, client C closes connection (and even exit) (04:45:04) powerman-asdf: at this point we've tcp FIN sent from C to S, and ACK sent back from S to C (04:45:45) powerman-asdf: but! after that (ACK'ing client's FIN), server S continue writing data to C (04:45:58) powerman-asdf: so we've half-open tcp connection at this point (04:47:00) powerman-asdf: what I expect, is reply from system which was running C with RST packets to data sent by S after client C closed connection and exit (04:47:26) powerman-asdf: so S got RST and sys->write() return EPIPE error (04:47:33) powerman-asdf: but this doesn't happens (04:48:00) powerman-asdf: system which was running C doesn't reply at all on packets sent by S (04:48:16) powerman-asdf: so S stop sending more data and start resending packets (04:48:29) powerman-asdf: and sys->write() on S is just hangs without returning EPIPE (04:49:03) powerman-asdf: is this correct behaviour for tcp?! (04:52:44) powerman-asdf: I've complex enough network setup here, involving multihoming, vpn, masquerade, complex firewall rules… so is RST packets should be sent (as I expect), they may be dropped because of firewall-related issues (04:53:17) powerman-asdf: so is RST -> so if RST (04:55:06) powerman-asdf: I can probably work around this issue by running one more thread on server S which will read from client, so it will detect EOF when client exit, and will force closing connection to that client (by killing thread which hangs in sys->write() to client). (04:56:44) powerman-asdf: But I wanna find out is this only correct way to do this, or current (simpler) implementation is also correct but doesn't work because of somehow lost RST packets…? (04:59:13) powerman-asdf: Also, wrt 'read EOF' way, I think what if client's system will be switched off, so there will be no FIN sent at all? (05:00:36) powerman-asdf: In Perl/Linux I always got EPIPE on syswrite() in such cases, and hang in sys->write() in Limbo/Inferno was bad surprise. :( (05:33:39) powerman-asdf: ok, looks like I'm not _that_ ill. I've tried to run client on same system as server, and there RST packets is sent, and server got EPIPE on sys->write() and everything works as expected. huh. (05:35:40) powerman-asdf: so, looks like my home workstation either doesn't even try to sent RST or it immediately blocked by firewall/etc. and doesn't reach network interfaces (and so doesn't seen by tcpdump) (09:43:03) bvalek2 [588054a5@gateway/web/freenode/ip.88.128.84.165] entered the room. (10:03:56) powerman-asdf: hmm. it's still strange. when client runs on another server, in same localnet (connected to same switch), with switched off firewall on both servers - there is still no RST packet :( (14:40:36) Fish- [~Fish@bus77-2-82-244-150-190.fbx.proxad.net] entered the room. (15:42:38) bvalek2_ [588054a5@gateway/web/freenode/ip.88.128.84.165] entered the room. (15:42:52) bvalek2 left the room (quit: Ping timeout: 252 seconds). (15:43:12) bvalek2_ is now known as bvalek2 (16:36:06) KBme left the room (quit: Quit: KBme kthxbye). (17:51:26) The account has disconnected and you are no longer in this chat. You will be automatically rejoined in the chat when the account reconnects.