可以将打开的插座放置很长时间而不读取它吗？

Question

I'm opening a socket to a server and then sleeping, possibly for a very long time (days). The process is single-threaded so I can't have a thread dedicated to managing the socket. The socket should stay alive. I'm assuming the server does not send any messages for which a client response is required.

The question is, is it safe to assume the socket will stay alive? Does the Linux kernel handle the needed TCP communication (eg keep-alive packets?) or is reading from the socket required to be called by an application from time to time?

What if the server sends some messages to the client? I'm assuming there is some buffer for such data. How big is it, how it can be changed, and what happens if it is full?

Answer 1

In addition to what has already been said here, firewalls and NATs may drop TCP connections after a period of inactivity. TCP keep-alive messages may be not frequent enough to keep TCP connections alive. This is why many application level protocols feature application level keep-alive messages (for example, I normally configure my ssh client to send keep-alive messages every 30 minutes because my office NAT drops TCP connections after 1 hour).

In other words, your application may like to exchange some messages with its remote peer once in a configurable while.

Alternatively, use a platform-specific socket option to enable TCP keep-alive messages ( SO_KEEPALIVE ) and configure the timeout ( TCP_KEEPIDLE on Linux).

Answer 2

Unless TCP keep-alives have been configured on the client or the server, the connection will stay open infinitely with no action required.

However this is just the theory, unless you are using a keep alive mechanism, you can't rely on this.

Lets look on how TCP works to understand that: Normally a TCP communication partner will send a FIN package to notify the other hand that it is about to close the connection. Unless such a package will getting sent/received, both partners agree about that the connection is open.

However, what if the remote host just went down immediately, let's say because of a blackout? Or because an administrator firewalled the port (after the connection has been established already)?

In such cases the other connection partner would not getting noticed about that fact and a read operation would block forever.

To solve this problem, kernel keep alives were introduced. Using this mechanism, the kernel sends keep-alives packages in configurable intervals and periods to the remote end, which are expected to get answered with an ACK . If no ACK will getting received, the kernel assumes the remote end to be not available anymore and returns from blocking read system calls on the related socket.