Writing Multithreaded Client-Server in Python.

[Sidd]

Hi,
I tried finding and example of multithreaded client-serve program in
python. Can any one please tell me how to write a multithreaded
client-server programn in python such that
1.It can handle multiple connections
2.It uses actual threads and not select() or some other function

[Paul Rubin]

"Sidd" <ia*****@gmail.com> writes:

I tried finding and example of multithreaded client-serve program in
python. Can any one please tell me how to write a multithreaded
client-server programn in python such that
1.It can handle multiple connections
2.It uses actual threads and not select() or some other function

If you mean multiple threads on the server side, see the SocketServer
module and its ThreadingMixin class. You may have to look at the
source code since up until recently the docs were incomplete. There
is a big helpful comment at the top of SocketServer.py which recently
got merged into the library reference manual.

[google]

Paul Rubin schreef:

"Sidd" <ia*****@gmail.com> writes:

I tried finding and example of multithreaded client-serve program in
python. Can any one please tell me how to write a multithreaded
client-server programn in python such that
1.It can handle multiple connections
2.It uses actual threads and not select() or some other function

If you mean multiple threads on the server side, see the SocketServer
module and its ThreadingMixin class. You may have to look at the
source code since up until recently the docs were incomplete. There
is a big helpful comment at the top of SocketServer.py which recently
got merged into the library reference manual.

Yes, however the term 'ThreadingMixIn' is a bit confusing (at least it
was to me).
What it does do, is handle each request (from the same client too) in a
new separate thread. Convenient if your processing intensive handle may
otherwise slow down the main server process becoming less responsive to
other requests.
What it doesn't do (and what Sidd seems to search as is suggested by
his 'select()' remark) is handle each client in a separate thread.

This is in fact listed in the (scarce) doc as a 'ToDo' of the
SocketServer if my memory serves me right.
If you want to apply SocketServer such that each client corresponds to
one thread that handles its' requests (and maintains its state), don't
use ThreadingMixIn - only the thread-selection will be executed in a
separate thread.
You could maintain a dictionary of Threads running RequestHandlers for
each client in the server class.
I use a new Handler for each incoming request, parse a username
parameter from the message and select the thread-handler from the
server dict. Each handler in the dict contains an open outgoing socket,
so I can also e.g. broadcast and notify clients.
Alternatively, you can (probably) keep the client2server socket open as
well (on both client and server). Thread selection should then
(hopefully :-) happen magically by calling the handle() method in each
thread directly.

HTH
Thijs

[Paul Rubin]

go****@phaedro.com writes:

What it does do, is handle each request (from the same client too) in a
new separate thread. Convenient if your processing intensive handle may
otherwise slow down the main server process becoming less responsive to
other requests.
What it doesn't do (and what Sidd seems to search as is suggested by
his 'select()' remark) is handle each client in a separate thread.
I don't know what you mean by that. It launches a new thread for each
client connection. The connection is two-way and can last as long as
desired. If you're imagining something like a web server handling
http requests, using http 1.1 keepalive, you could handle any number
of requests in that connection.
If you want to apply SocketServer such that each client corresponds to
one thread that handles its' requests (and maintains its state), don't
use ThreadingMixIn - only the thread-selection will be executed in a
separate thread.

What do you mean by "each client"? If a client connects, does some
stuff, disconnects, and later reconnects, how do you know that it's
the same client that's come back?

[Steve Holden]

Paul Rubin wrote:

go****@phaedro.com writes:

What it does do, is handle each request (from the same client too) in a
new separate thread. Convenient if your processing intensive handle may
otherwise slow down the main server process becoming less responsive to
other requests.
What it doesn't do (and what Sidd seems to search as is suggested by
his 'select()' remark) is handle each client in a separate thread.

I don't know what you mean by that. It launches a new thread for each
client connection. The connection is two-way and can last as long as
desired. If you're imagining something like a web server handling
http requests, using http 1.1 keepalive, you could handle any number
of requests in that connection.

I suspect he was trying to say that BaseHTTPServer has no mechanism for
handling state. As you know, of course, this is most relevant across
multiple successive connections to a server from the same client, and
has little to do with threads.

If you want to apply SocketServer such that each client corresponds to
one thread that handles its' requests (and maintains its state), don't
use ThreadingMixIn - only the thread-selection will be executed in a
separate thread.

What do you mean by "each client"? If a client connects, does some
stuff, disconnects, and later reconnects, how do you know that it's
the same client that's come back?

The assertion that ThreadingMixIn doesn't handle *sessions* might be
more appropriate, but then there's no reason why it really should (since
if they were handled at all they would be better handled in the base
server classes). By "each client" I suspect the OP really meant "each
session", and was ignoring the fact that the same client can have
multiple sessions to the same server.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[google]

Steve Holden schreef:

Paul Rubin wrote:

go****@phaedro.com writes:

What it doesn't do (and what Sidd seems to search as is suggested by
his 'select()' remark) is handle each client in a separate thread.

I don't know what you mean by that. It launches a new thread for each
client connection. The connection is two-way and can last as long as
desired. If you're imagining something like a web server handling
http requests, using http 1.1 keepalive, you could handle any number
of requests in that connection.

I suspect he was trying to say that BaseHTTPServer has no mechanism for
handling state. As you know, of course, this is most relevant across
multiple successive connections to a server from the same client, and
has little to do with threads.

see below: I must apologize for not being able to use the standard CS
vernacular but indeed I meant session (persistent state over multiple
requests) - I still think that the thread-starter looks for a mechanism
that handles each *session* in a thread where the 'mother'
server-thread selects the thread belonging to a session.

If you want to apply SocketServer such that each client corresponds to
one thread that handles its' requests (and maintains its state), don't
use ThreadingMixIn - only the thread-selection will be executed in a
separate thread.

What do you mean by "each client"? If a client connects, does some
stuff, disconnects, and later reconnects, how do you know that it's
the same client that's come back?

The assertion that ThreadingMixIn doesn't handle *sessions* might be
more appropriate, but then there's no reason why it really should (since
if they were handled at all they would be better handled in the base
server classes). By "each client" I suspect the OP really meant "each
session", and was ignoring the fact that the same client can have
multiple sessions to the same server.

Correct. My own 'brew' is multi-session-clients enabled (in fact I test
with two applets from the same PC) but indeed I used confusing language
saying 'client' for 'session'.

Again: ThreadingMixIn doesn't give you 'session threads' in which you
store persistent information - a candidate for some generic extension
of SocketServer ?

When doing research for my own hobby project, I stumbled upon "Twisted"
, it seems to give a lot in terms client-server features/functionality
compared to SocketServer ? Is it indeed a 'generic network programming
framework'? Anyone has experience with it ?
Yours,

--
Thijs - phaedro.com

[Paul Rubin]

go****@phaedro.com writes:

I suspect he was trying to say that BaseHTTPServer has no mechanism for
handling state. As you know, of course, this is most relevant across
multiple successive connections to a server from the same client, and
has little to do with threads.

Usually you would do that with browser cookies.
Correct. My own 'brew' is multi-session-clients enabled (in fact I test
with two applets from the same PC) but indeed I used confusing language
saying 'client' for 'session'.

Again: ThreadingMixIn doesn't give you 'session threads' in which you
store persistent information - a candidate for some generic extension
of SocketServer ?

What exactly do you mean by session? Let's say the client does
the following:

1. Sends
GET /abcde HTTP/1.1
Connection: Keep-Alive
and downloads the abcde page

2. Sends
GET /fghij HTTP/1.1
and downloads the fghij page, re-using the TCP connection from step 1

3. Opens a completely new TCP connection and sends
GET /klmno HTTP/1.1
through the new connection, and downloads klmno through that
connection.

How many sessions took place here? It sounds like you want the answer
to be one session, that operations 2 and 3 are part of the same session.
But that makes no sense unless you associate them somehow, say using
a client cookie and a global session table indexed by the cookie.

Why don't you take a look at any of the web frameworks that get
discussed here (Spyce, CherryPy, Zope, Django, whatever). They all
have mechanisms like that. BaseHTTPServer doesn't try to operate
at that level.

[google]

a bit of a late reply, sorry...

Paul Rubin schreef:

go****@phaedro.com writes:

I suspect he was trying to say that BaseHTTPServer has no mechanism for
handling state. As you know, of course, this is most relevant across
multiple successive connections to a server from the same client, and
has little to do with threads.
Usually you would do that with browser cookies.

Mwah... Not if you want the client to be responsive to server-initiated
messages, i.e. to implement some sort of listener ? (Or you should use
Jason-RPC or some other relatively exotic tech?)
And, and my guess is this is more applicable in the context of OP's
question, not if you want to prevent constructing some
client-representing object from a cookie-id for each incoming request
(istd. of forwarding the request to a thread holding the
client-representing object in the correct current state)
Correct. My own 'brew' is multi-session-clients enabled (in fact I test
with two applets from the same PC) but indeed I used confusing language
saying 'client' for 'session'.

Again: ThreadingMixIn doesn't give you 'session threads' in which you
store persistent information - a candidate for some generic extension
of SocketServer ?

What exactly do you mean by session?

<snap HTTP session trace>

I mean (in a C/S context) : "A persistent state initiated by a client
(e.g. a login- or first-message event) and maintained by the server."

How many sessions took place here?
Though trivial: 2 'TCP sessions' but I am (sorry for the confusion) not
talking about TCP sessions but (and I guess OP too) application-level
sessions.
It sounds like you want the answer
to be one session, that operations 2 and 3 are part of the same session.
But that makes no sense unless you associate them somehow, say using
a client cookie and a global session table indexed by the cookie.

In my world, message 3 would be 'session initiating'.
Message 2 could be handled on the basis of a possibly changed 'client
state' due to processing of message 1 (or other intermediate message
exchange).
Why don't you take a look at any of the web frameworks that get
discussed here (Spyce, CherryPy, Zope, Django, whatever). They all
have mechanisms like that. BaseHTTPServer doesn't try to operate
at that level.

The OP had a question about SocketServer not BaseHTTPServer? That
certainly doesn't give you 'persistent state mechanism' for free.
SocketServer doesn't either - all I wanted to say is I got myself
confused a bit by the name "ThreadingMixIn" suggesting to me that it
would give me a thread to store state info in - again it doesn't .

I know Zope very well, and CherryPy a bit. At least for my project they
wouldn't suffice because, as far as I know, they don't offer a
mechanism for the server to 'raise an event' or 'send a non-response
message' to the client. I don't know about Djange and Spyce but thanks:
I'll certainly study them ! I suggested Twisted as an 'out-of-the-box'
framework for state-persistent, real-time C/S framework but I perceived
the overhead/learning-curve intimidating and decided to pass.
--
T.
www.phaedro.com
Compile-time type-checking is a drag.
http://www.bushclintonkatrinafund.com/ - help now but never ever vote
republican again please