Writing Multithreaded Client-Server in Python.

Discussion in 'Python' started by Sidd, Aug 30, 2005.

  1. Sidd

    Sidd Guest

    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
     
    Sidd, Aug 30, 2005
    #1
    1. Advertising

  2. Sidd

    Paul Rubin Guest

    "Sidd" <> 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.
     
    Paul Rubin, Aug 30, 2005
    #2
    1. Advertising

  3. Sidd

    Guest

    Paul Rubin schreef:

    > "Sidd" <> 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
     
    , Aug 30, 2005
    #3
  4. Sidd

    Paul Rubin Guest

    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?
     
    Paul Rubin, Aug 30, 2005
    #4
  5. Sidd

    Steve Holden Guest

    Paul Rubin wrote:
    > 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 +44 150 684 7255 +1 800 494 3119
    Holden Web LLC http://www.holdenweb.com/
     
    Steve Holden, Aug 30, 2005
    #5
  6. Sidd

    Guest

    Steve Holden schreef:

    > Paul Rubin wrote:
    > > 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
     
    , Sep 1, 2005
    #6
  7. Sidd

    Paul Rubin Guest

    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.
     
    Paul Rubin, Sep 1, 2005
    #7
  8. Sidd

    Guest

    a bit of a late reply, sorry...

    Paul Rubin schreef:

    > 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
     
    , Sep 6, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. -
    Replies:
    2
    Views:
    402
    Alan Krueger
    Jul 29, 2005
  2. John Lull

    Multithreaded COM server problem...

    John Lull, Jan 10, 2004, in forum: Python
    Replies:
    10
    Views:
    3,459
    Mark Hammond
    Jan 21, 2004
  3. Ronen Yacov
    Replies:
    7
    Views:
    323
  4. Ronen Yacov
    Replies:
    3
    Views:
    350
  5. NaeiKinDus
    Replies:
    2
    Views:
    639
    NaeiKinDus
    Mar 6, 2007
Loading...

Share This Page