How to know connect to server client disconnect

[henr...@insightrobotics.com]

Hi,

How to know when client connection to server suddenly disconnect (unexpected case)? In server side how to know the client connection was broken? 

[François-Xavier Bourlet]

You get a LostRemote exception as well. This is especially useful for canceling long running computation and/or streams.

On May 8, 2014 6:34 PM, <henr...@insightrobotics.com> wrote:

Hi,

How to know when client connection to server suddenly disconnect (unexpected case)? In server side how to know the client connection was broken? 

--
You received this message because you are subscribed to the Google Groups "zerorpc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zerorpc+u...@googlegroups.com.
To post to this group, send email to zer...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/zerorpc/45bb90fb-3c47-43fb-9a0a-dc5ca07cbdf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[henr...@insightrobotics.com]

LostRemote only client side try to connect to server and get the exception. I means when the client and server established connection and then client side break the problem or suddenly client side disconnect. In server side how to know who client connection broken. In case many client connect to server side. Could you give simple example in server side determinate who client was leave(unexpect close)?

[François-Xavier Bourlet]

Hello,

I think I understand what you mean: You want the server to be informed
when a client is physically disconnected, outside of the context of a
request from the client.
And in short, this is not possible.

For many different reason really. Let me explain a bit more:

When you .connect(), there is no direct notion of physical connection
to a server. In fact, you can connect to more than one server.
Reversely, a server can connect to the client. The notion of
connecting to or being connected is independent from the logical
client->server relationship.

Let me repeat that: The network topology is independent from the
logical client->server relationship.

The only moment you can expect anything to really happen on the
network level starts on calling a remote method through the client.

client = zerorpc.Client()
client.connect/bind # whatever to plug into your network topology

client.MyAwesomeMethod(42) # this is the beginning of an RPC.

On the server side, we have something like:

class MyService(object):
def MyAswesomeMethod(self, value):
[...]

server = zerorpc.Server(MyService())
server.connect/bind # whatever to plug into your network topology

server.run() # now the server just waits forever until a request comes in.

See, here the server doesn't know (or care) if a client is physically
connected (via any network level protocol supported by zeroMQ, like an
unix socket or tcp, or even a local thread-ipc shit). After all,
clients and servers can come and go at any time, only when a request
is initiated from a client you would care about the possibility of a
server taking care and replying to your request.

Let's try a breakdown the different steps and when you get a
LostRemote or a TimeOut error during a remote call.
I will use the default values for the hearbeat (5s) and timeout (30s),
but of course you can tune that and adjust it at will.

So our client does:
>> client.MyAwesomeMethod(42) # this is the beginning of an RPC.

1: The client starts a logical connection to the server:
- After 5s, the client sends the first heartbeat message, and will
send an heartbeat message every 5s thereafter.
- After 10s (heartbeat frequency * 2) without any message received
from the server, the client raises a LostRemoteError.

You can see, at this point, maybe no server could be reached, or the
server crashed, or maybe the server got the request and replied but
the network broke, or is too slow, whatever else: what matters is the
following:
- No connection was established in 10s, the remote is probably lost.

2: The server returned a msg before 10s, maybe its an heartbeat
message, or maybe the finale result to your request, or any other
message used in the zerorpc protocol:
- If this is the finale result to your request, cool, everything is
done here. And the logical connection is closed (heartbeat turns off
etc).
- For other msg (likely an heartbeat, but could be a message part of
a streaming response etc), the connection is considered active.
- If after 30s (the timeout deadline) we still didn't get a reply to
the request from the server, the client raises a TimeoutError.

- So a LostRemote indicates that a connection couldn't be maintained
thoroughly with a server. During a 10s (2 x heartbeat), the network
could have broken and then reconnected. It doesn't matter. Only the
logical level matters.

- The TimeoutError is there to giveup waiting for a reply if the
server is taking too long (You can customize the timeout on a per
request basis btw). Maybe your code is blocked on the server, maybe
your processing is so slow/long that it takes forever to reply. The
Timeout is just an useful tool to avoid waiting forever.

On the server side, things look like that:

1: A request comes in. A logical connection is opened, and like the client:
- After 5s, the server sends the first heartbeat message, and will
send an heartbeat message every 5s thereafter.
- After 10s (heartbeat frequency * 2) without any message received
from the client, the server raises a LostRemoteError.

2: The server executes your method in the context of the logical connection:
- When the method returns (or any exception occurs in the process of
trying to execute or during the execution) the final result is sent to
the client. And the logical connection is closed. There is some
technical trickery here, to ensure that any pending msgs are properly
sent to the zeroMQ queue etc, but for the sake of my example, you can
consider the connection closed.
- If before the method returns, no messages (likely no hearbeat) is
received from the client in 10s (heartbeat frequency * 2), the server
raises a LostRemoteError in the context of the logical connection,
which will likely be raises in the middle of your running code. This
can help you to abort what you are doing, because after all, the
client will anyway never receive the result, so there is no point to
continue working on the request.

A simple example:

client.py:

import zerorpc
import gevent

c = zerorpc.Client('tcp://127.0.0.1:4242')
print 'sleeping for no reason'
gevent.sleep(5)
print 'calling foo'
c.foo()

server.py

import zerorpc
import gevent

class Service(object):
def foo(self):
print 'foo called, waiting 15s'
gevent.sleep(15)

s = zerorpc.Server(Service())
s.bind('tcp://127.0.0.1:4242')
s.run()

Now run, the server, then run the client:
- The client will block 5s, then call the server, wait 15s for the
server to reply, then terminate properly.
- If you kill the client:
- during the 'sleeping for no reason' stage, nothing happens.
- during the 'calling foo' stage, when the server already printed
'foo called...', the server will raise a RemoteError
- If you kill the server during:
- during the 'sleeping for no reason' stage, of the client, the
client will raise a RemoteError during the 'calling foo' stage after
10s.
- after the server printed 'foo called...' then the client will
raise a RemoteError after 10s.

Hope that helps!

Best,
fx

> --
> You received this message because you are subscribed to the Google Groups
> "zerorpc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to zerorpc+u...@googlegroups.com.
> To post to this group, send email to zer...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/zerorpc/77e9b346-cb5e-4d12-b583-14cd2a11e29e%40googlegroups.com.