NotionCommotion Posted June 10, 2017 Share Posted June 10, 2017 A c++ client connects to a Reactphp server using TCP sockets on port 1337. The client is able to write data to the server and the server is able to write data to the client, and all is good. Tshark is running on both machines with a filter for just port 1337, and sees this initial communication. No communication occurs between the two for the next hour, and Tshark on both machines confirms no communication occurred. Neither the client or server received a close connection, and think the connection is still open. The server then attempts to write some more data to the client, Tshark sees the transmission on the server wire, but the Tshark doesn't see the transmission on the clients wire, and obviously the client doesn't respond. The client daemon is then shutdown, and the server senses that the connection has been closed. php.ini shows default_socket_timeout as being 60 seconds and changing the value does not appear to have any affect. What is causing this and how do I prevent it? Thank you Link to comment Share on other sites More sharing options...
NotionCommotion Posted June 10, 2017 Author Share Posted June 10, 2017 More info... Experiment is repeated except for the vary end resulting in the same outcome. Then, instead of halting the client daemon, the server daemon is halted. Unlike the server, the client does not sense that the connection is broken. Link to comment Share on other sites More sharing options...
gizmola Posted June 14, 2017 Share Posted June 14, 2017 What are the os's of the client and server? Is there a proxy/firewall in between the client & server? Are you checking for keepalive packets? (ack with an otherwise empty packet). TCP sockets do have variable timeouts that should close them on lack of activity. Link to comment Share on other sites More sharing options...
NotionCommotion Posted June 14, 2017 Author Share Posted June 14, 2017 What are the os's of the client and server? Is there a proxy/firewall in between the client & server? Are you checking for keepalive packets? (ack with an otherwise empty packet). TCP sockets do have variable timeouts that should close them on lack of activity. Thanks gizmola, Client is a pi and server is Centos. Yes, there are firewalls protecting both, but I don't think this is the issue. I've briefly looked at http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html. I've since implemented a temp solution of sending a json rpc heartbeat, and it seems to work, will look more into the above referenced link. Link to comment Share on other sites More sharing options...
gizmola Posted June 25, 2017 Share Posted June 25, 2017 NAT firewalls can be a problem because the firewall proxies the connection and performs the NAT of course. The firewall itself can have limited resources and typically, implements a connection queue where it will drop the oldest connections. Some form of keep alive is useful in making sure that an active connection doesn't get killed on one side or the other, due to timeout over a long period. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.