One last thing about SocketServer

[rbt]

I've read more about sockets and now, I have a better understanding of
them. However, I still have a few SocketServer module questions:

When used with SocketServer how exactly does socket.setdefau lttimeout()
work? Does it timeout the initial connect request to the socket server
or does it timeout the session between the connecting client socket and
the client socket the server generated to handle the incoming request?

Also, since the *only* thing a 'socket server' does is to create 'client
sockets' to handle requests, how do I use socket object features on
these generated clients to manage and/or monitor them?

The SocketServer module is great, but it seems to hide too many details
of what it's up to!

Thanks,
rbt

[Steve Holden]

Re: One last thing about SocketServer

rbt wrote:[color=blue]
> I've read more about sockets and now, I have a better understanding of
> them. However, I still have a few SocketServer module questions:
>
> When used with SocketServer how exactly does socket.setdefau lttimeout()
> work? Does it timeout the initial connect request to the socket server
> or does it timeout the session between the connecting client socket and
> the client socket the server generated to handle the incoming request?
>[/color]
setdefaulttimeo ut() simply sets the default timeout for all sockets
created thereafter. This timeout applies to any socket operation, I
believe (though I am unsure about "accept()") .
[color=blue]
> Also, since the *only* thing a 'socket server' does is to create 'client
> sockets' to handle requests, how do I use socket object features on
> these generated clients to manage and/or monitor them?
>[/color]
When the accept() call on a socket returns a tuple(socket, address): the
first element of the returned tuple is the socket you use to communicate
with that particular client (in other words, it represents the server
end of the connection that's just been accept()ed).

So you can read and write that socket to communicate with that client
over that specific connection. Of course, if you don't use either the
ThreadingMixIn or the ForkingMixIn then communication with one client
will effectively stop you form accept()ing any more connections, hence
the need for the mix-in classes.
[color=blue]
> The SocketServer module is great, but it seems to hide too many details
> of what it's up to!
>[/color]
Well, of course, that is what abstractions are for! You should bear in
mind that SocketServer isn't necessarily the most efficient or effective
way to handle multiple clients concurrently, but it's very convenient
when you are just getting started.

Later you might want to consider an asyncore-based approach, or perhaps
using the Twisted package. Both of these solutions are a little more
robust for production code.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/