whether the server can sense the client's disconnection

[bxhsix]

Hi
When the client is disconnected but the processing on the server hasn't terminated, how does the server sense the client's disconnection when the processing returns? Can the server sense the client's disconnection as soon as it's disconnected? If so, what should I do?
Thanks for any help!

[bxhsix]

To be detailed, what I want is to do some operations when the rpc returns normally and do others when abnormally(for example, free some resource when the client is disconnected before the rpc returns). Shall I gain my ends? How?

[benoit]

Hi,

There's no way in the server to figure out if a response of a twoway invocation was successfully returned and received by the client.

If you need confirmation from the client that it received the response, your server could callback the client with a twoway call to send the response. See the callback demo from the demo/Ice/callback directory in your Ice distribution for an example.

Cheers,
Benoit.

[matthew]

This is a general problem with all distributed systems, and nothing specific to Ice. Strategies such a relying on the network connection breaking down are not reliable, and should be avoided. A better strategy is to use sessions. See Michi's article "The Grim Reaper" for details: http://www.zeroc.com/newsletter/issue3.pdf

[marc]

See also this FAQ.

[bxhsix]

Thanks for all replying!
In my early TCP/IP programming with socket, when the server returns something to the client, using send() for example, if the client is disconnected at that time, the server will sense it as a timeout. So I have thought that ICE should have the same funtion.

[marc]

That's true, if you get an error while sending a response. However, since there was then just a request from the client, it's unlikely that the response would fail. If the client just disappears, the TCP/IP stack cannot give you a reliable notification about the client being dead.

Note that you do get an exception if the sender calls back the client. This is also how the Grim Reaper example works.

[bxhsix]

But when the client is disconnected in the course of rpc, the server won't sense it and will continue to complete the rpc code. I know the thread will be released as soon as the rpc code ends, but I don't know whether the server will maintain a TCP/IP link in lower layer. If so, how long will it be? Can we configure it and how? If there are too many useless links, each of which occupies about 128K memory, the server will be exhausted.

[benoit]

Hi,

The server closes the TCP/IP connection as soon as it detects it. When this occurs depends very much on how the connection is closed and your network infrastructure.

For example, if the client destroys the communicator while it still has a request being processed by the server, the connection is closed gracefully and the server will close the connection as soon as it receives the close connection message.

However, if the client crashes and is behind several routers, the server will most likely not detect the connection closure in a timely manner. The server will eventually close the connection if sending a response fails with a timeout or if the connection is idle and server ACM is enabled (it's disabled by default).

See 28.4.6 Endpoints in the Ice manual for more information on setting a timeout on the object adapter physical endpoints and see here for more information on ACM. I also recommend reading the Connection Management chapter for detailed information on how Ice manages its connections.

Also, note that you can set Ice.Trace.Network=2 in your client or server configuration file to see connection lifecycle information.

Cheers,
Benoit.

[bxhsix]

I see it. Thank you very much!