How to stop an [Rpyc] server thread?

[Saizan]

I embedded an Rpyc threaded server in a preexistent daemon (an irc
bot), this is actually very simple;
start_threaded_server(port = DEFAULT_PORT)
then I had the necessity to stop the thread which accept() new
connections without killing the whole app, the thread is simply a while
True that spawn a new thread which serves each connection, so I placed
a flag and a break in this way:
def local_threaded_server(port = DEFAULT_PORT, **kw):
global stop
sock = create_listener_socket(port)
while True:
newsock, name = sock.accept()
t = Thread(target = serve_socket, args = (newsock,),
kwargs = kw)
t.setDaemon(True)
t.start()
if stop: break
but, since sock.accept() blocks, when I set stop=True the server wait
one more connection and only then stops.
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
44, in read
buf = self.sock.recv(count)
socket.error: (10053, 'Software caused connection abort')

OR
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
46, in read
raise EOFError()
EOFError

I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.

 

[Tal Einat]

I embedded an Rpyc threaded server in a preexistent daemon (an irc
bot), this is actually very simple;
start_threaded_server(port = DEFAULT_PORT)
then I had the necessity to stop the thread which accept() new
connections without killing the whole app, the thread is simply a while
True that spawn a new thread which serves each connection, so I placed
a flag and a break in this way:
def local_threaded_server(port = DEFAULT_PORT, **kw):
global stop
sock = create_listener_socket(port)
while True:
newsock, name = sock.accept()
t = Thread(target = serve_socket, args = (newsock,),
kwargs = kw)
t.setDaemon(True)
t.start()
if stop: break

First off, instead of the "while True" and the break, you could write:
while not stop:

but, since sock.accept() blocks, when I set stop=True the server wait
one more connection and only then stops.
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
[snip]

I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.

Now to the real issue. I've also had such weird problems with socket
timeout in Python. The best workaround I found is to use select() to
check for activity on the socket(s), and use select()'s timeout
mechanism. So far, this has worked without a hitch on both WindowsXP
and Solaris Sparc9 installations.

- Tal
reduce(lambda m,x:[m+s[-1] for i,s in enumerate(sorted(m))],
[[chr(154-ord(c)) for c in '.&-&,l.Z95193+179-']]*18)[3]

 

[Bryan Olson]

Saizan wrote:
[...]

I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection: [...]
socket.error: (10053, 'Software caused connection abort') [...]
EOFError

I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..

After modest investigation, it looks like a bug in Python's
sockets, at least on WinXP.

Try inserting the line after accept():

[...]
newsock, name = sock.accept()
newsock.settimeout(None)
[...]

 

[Felipe Almeida Lessa]

Now to the real issue. I've also had such weird problems with socket
timeout in Python. The best workaround I found is to use select() to
check for activity on the socket(s), and use select()'s timeout
mechanism. So far, this has worked without a hitch on both WindowsXP
and Solaris Sparc9 installations.

Twisted[1] is the answer. I've never seen a better framework for using
sockets, it's painless. I created two versions of the same protocol
(both client and server), one using sockets + select, another using
Twisted. The sockets version had 2x lines than the Twisted one and
lots of bugs. Sockets may fail *anywhere* in your code, and Twisted
takes care of all details for you[2]. Simply Sweet.

Cheers,

[1] http://www.twistedmatrix.com/
[2] Of couse this is just *one* advantage of the Twisted framework...

PS.: No, I wasn't paid for this e-mail ;-)