Silent Peers在ACE中就没好办法了么
Handling Silent PeersIf a client disconnects, either gracefully or abruptly, itssocket 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).
大概就是这些策略了。winsock立刻检测出，其实不准确。ACE完全是依赖于winsock的，在它的上面包装了一层。 winsock好像立即能检测出所谓“Silent Peers”
Not really.
页:
[1]