Frequently Asked Questions
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.
If you need to clean up server-side resources in response to clients exiting or crashing, have a look at the article "The Grim Reaper" in Issue 3 of Connections. It shows you how you can implement a session concept that achieves this simply and cleanly. Glacier2 also provides such a service—please check the Ice documentation for more detail.