socket.rcv timeout while-loop
dwayneblind at gmail.com
Fri Feb 4 18:16:38 CET 2011
Thank you very much Jean-Michel Pichavant and Stephen Hansen.
@ Jean-Michel Pichavant
I will have a look at Pyro.
@ Stephen Hansen
Now I am pretty much worried. :'(
2011/2/4 Stephen Hansen <me+list/python at ixokai.io>
> On 2/4/11 6:55 AM, Dwayne Blind wrote:
> > @ Jean-Michel Pichavant
> > I am writing a small multiplayer game. Several clients are connected to
> > the server. Games last, say, 20 seconds.
> > You can think of the game as a small chat lasting 20 seconds. All the
> > data received by the server is sent back to the clients.
> > @ Stephen Hansen
> > Each player can send as many words as he wants. I think this is why I
> > need the loop. Don't you think so ?
> No. I've never seen or used network code which operated in any way like
> that. Sometimes you want code which blocks, sometimes you want code that
> doesn't: sometimes you want stuff that may block for a little while, but
> with a timeout.
> I can't even imagine why you'd want code which aggressively tries to
> read for multiple seconds before moving on.
> Either the read works and you have data; or it doesn't, and you move on
> to do something else and try again later. Perhaps after trying to read
> from another socket-- or, perhaps after a select.select() call tells you
> there's something more to read. T
> But you need to separate the logic of your game from this network
> From your game logic perspective, perhaps you process the responses line
> by line. From your network logic perspective, you may happen to get one
> character at a time-- or it may burst to you all at once. The socket
> interfaces will try to give you up to the requested number of bytes but
> the network layer has every possibility of just giving you partial
> So the network layer should just gather up the data as it arrives,
> buffer it -- and pass it off to the game logic layer as each line is
> complete (i.e., as \r\n or \n's are received). But there's no reason at
> all to do a while loop to aggressively try to read from one particular
> socket repeatedly for multiple seconds. At least, none that I've ever
> run into.
> Granted, I'm not at all a master of socket-fu.
> Stephen Hansen
> ... Also: Ixokai
> ... Mail: me+list/python (AT) ixokai (DOT) io
> ... Blog: http://meh.ixokai.io/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list