Silent Peers在ACE中就没好办法了么

peakzhang

Handling Silent PeersIf a client disconnects, either gracefully or abruptly, its
socket will become readable. A reactor can detect this event and dispatch the handle_input() hook method on the event handler that's associated with
the socket handle. The handler will then determine that the connection has
closed, which is usually revealed by a recv() or read() call
returning 0 or -1. If the client simply stops communicating altogether, however,
there could be a number of causes, including

• An Ethernet cable's being pulled out of its connector, which
  may be plugged back in shortly and the connection continues or
  
• The host crashed without the opportunity to close any
  connections, so the local endpoint of the connection is stranded and will never
  continue.
  

In these cases there are no events for a reactor to detect.
Depending on the needs of your application services and the
application-level protocol(s) used, there are several ways to handle a silent
peer. These include:

• Wait until the TCP keepalive
  mechanism abandons the peer and closes the connection, which will trigger an
  event on the socket that can be handled just as if the client closed the
  connection. Unfortunately, this may take a long time?maybe hours梐s described in
  [SW95].
  
• Implement an application-level policy or protocol, such as a
  "heartbeat" message or periodic "are you there?" message. If the peer fails to
  send a heartbeat message or answer the "are you there?" message within an
  application defined period of time, abort the connection unilaterally. The
  application may then attempt to reopen the connection at a later time.
  
• Implement a policy that if the peer does not send any data for
  some determined amount of time, the connection will be abandoned. This type of
  policy is used by the Logging_Event_Handler_Ex class (page
  68).
  

peakzhang

大概就是这些策略了。winsock立刻检测出，其实不准确。ACE完全是依赖于winsock的，在它的上面包装了一层。

peakzhang

winsock好像立即能检测出所谓“Silent Peers”
Not really.