E-mail
Connection closure is a meaningless event as far as an Ice application is concerned: even if Ice were to provide such a callback, it would not tell the application anything useful.
Typically, the wish for a connection closure callback arises in the context of writing an Ice server. If the server holds onto resources on behalf of clients and a client exits or crashes, the server has to reclaim these resources somehow. The idea is that the server can perform this cleanup when it detects that a client's connection has been closed. However, this does not work:
- There is nothing to stop a single client from opening several connections to the same server. If a client does this, connection closure does not imply that the client has gone away.
- Ice provides automatic connection management for both the client and the server side: if a connection has been idle for some time, the Ice run time transparently closes the connection to conserve resources. Again, the closure of such a connection does not imply that the client has gone away.
- The notion of connection closure does not apply to datagrams. Attempting to attach clean-up semantics to connection closure simply would not work for applications that use UDP as a transport.
- Network failures can cause connections to be lost without the server being notified by the TCP/IP stack.
Instead of trying to take action in response to a physical event such as the loss of connection, we generally recommend a more passive approach that relies on the concept of a session. The burden is placed on the client to create a session and keep it alive; if the client allows the session to expire, either because the client crashed or because an ill-behaved client neglected to destroy its session, the server can take action to clean up resources consumed by that client. The Glacier2 firewall service implements this concept and provides hooks for you to add your own logic for handling session expiration and destruction.