boost::asio::ip::tcp::socket is connected?(如何知道socket的链接是链接或断开？)

翻译：华亮 From：http://stackoverflow.com/questions/1511129/boostasioiptcpsocket-is-connected

问题：

I want to verify the connection status before realize my operations (read/write).

回答：

TCP is meant to be robust in the face of a harsh network;

TCP注定是在混乱的网络环境中能够保持健壮性，这个是因为TCP就是那么设计的。

even though TCP provides what looks like a persistent end-to-end connection, it's all just a lie, each packet is really just a unique, unreliable datagram.

尽管TCP在表面看来是提供了一个持续的点对点的连接，但那仅仅是一个假象。每个数据包都是一个独立不可靠的数据报。

The connections are really just virtual conduits created with a little state tracked at each end of the connection (Source and destination ports and addresses, and local socket). The network stack uses this state to know which process to give each incoming packet to and what state to put in the header of each outgoing packet.

所谓连接，只是一个由连接的每个端点保存的一些状态构成的虚拟的管道。网络栈通过这些状态，知道把传入的数据包传给那个进程，也知道把什么状态放到发出的数据包的包头。

Because of the underlying — inherently connectionless and unreliable — nature of the network, the stack will only report a severed connection when the remote end sends a FIN packet to close the connection, or if it doesn't receive an ACK response to a sent packet (after a timeout and a couple retries).

Because of the asynchronous nature of asio, the easiest way to be notified of a graceful disconnection is to have an outstanding async_read which will returnerror::eof immediately when the connection is closed. But this alone still leaves the possibility of other issues like half-open connections and network issues going undetected.

由于asio的异步的天性，最容易发现断开连接的方法是在 async_read 里面收到 error::eof。

The most effectively way to work around unexpected connection interruption is to use some sort of keep-alive or ping. This occasional attempt to transfer data over the connection will allow expedient detection of an unintentionally severed connection.

The TCP protocol actually has a built-in keep-alive mechanism which can be configured in asio using asio::tcp::socket::keep_alive. The nice thing about TCP keep-alive is that it's transparent to the user-mode application, and only the peers interested in keep-alive need configure it. The downside is that you need OS level access/knowledge to configure the timeout parameters, they're unfortunately not exposed via a simple socket option and usually have default timeout values that are quite large (7200 seconds on Linux).

Probably the most common method of keep-alive is to implement it at the application layer, where the application has a special noop or ping message and does nothing but respond when tickled. This method gives you the most flexibility in implementing a keep-alive strategy.