Adding idle timeout capabilities to asyncore

[Giampaolo Rodola']

Hi there.
We're talking about an asyncore-based server.
Just for the heck of it I'd like to set a timeout which will
disconnects the clients if they're inactive (i.e., no command or data
transfer in progress) for a long period of time.
I was thinking about putting the timeout value into an attribute:

def settimeout(self, secs):
self.timeout = time.time() + secs

And then have the readable method call time.time() at every loop to
check if time has passed or not:

def readable(self):
if time.time() >= self.timeout:
self.send("Timeout")
self.close()
return 1

My only concern is if it's a good idea calling time.time() so often.
Since A LOT of clients could be connected simultaneously, couldn't it
be a too much resource-intensive operation?
I'd also be curious to know how Twisted implemented this kind of
stuff.
By calling time.time() at every loop?
Thanks in advance.

[Josiah Carlson]

On 22 Ott, 12:28, Giampaolo Rodola' <[e-mail]:

Hi there.
We're talking about an asyncore-based server.
Just for the heck of it I'd like to set a timeout which will
disconnects the clients if they're inactive (i.e., no command or data
transfer in progress) for a long period of time.
I was thinking about putting the timeout value into an attribute:

def settimeout(self, secs):
self.timeout = time.time() + secs

And then have the readable method call time.time() at every loop to
check if time has passed or not:

def readable(self):
if time.time() >= self.timeout:
self.send("Timeout")
self.close()
return 1

My only concern is if it's a good idea calling time.time() so often.
Since A LOT of clients could be connected simultaneously, couldn't it
be a too much resource-intensive operation?
I'd also be curious to know how Twisted implemented this kind of
stuff.
By calling time.time() at every loop?

Thanks in advance.

Calling time.time() is relatively inexpensive in comparison to pure
Python function calls, but indeed, it could be a bottleneck.

I don't know what Twisted does, but what I would do is to add two
variables to each instance of the class you want to add timeouts to;
self.timeout and self.lastdata . self.lastdata would hold the time
for the last time you sent or received data on the socket, and
self.timeout would hold the delay between when you last sent/received
data and when it should be closed due to idle timeout.

Now, since you are smart, you don't need to alter your handle_send()
or handle_receive() methods in your asyncore subclass. Instead, you
rewrite asyncore.poll() to update .lastdata for every socket that is
in either the reader or writer list, which will result in one
time.time() call. Further, to check for timeouts, you only ever need
to check those sockets that are *not* in the readable or writable
lists...

To be precise, add the following block to your own copy of
asyncore.poll just after the 'for fd in e:' block...
#handle timeouts
rw = set(r) + set(w)
now = time.time()
for f in (i for i in rw if i in map):
map[f].lastdata = now
for j in (map[i] for i in map if i not in rw):
if j.timeout+j.lastdata now:
#timeout!
j.handle_close()

You ARE going to need to initialize .timeout and .lastdata members for
every instance, but that shouldn't be so bad (for a socket that
doesn't time out, I would actually suggest a 1 hour or 1 day timeout).

- Josiah

[Giampaolo Rodola']

On 23 Ott, 17:34, Josiah Carlson <[e-mail]:

On 22 Ott, 12:28, Giampaolo Rodola' <[e-mail]:

Hi there.
We're talking about an asyncore-based server.
Just for the heck of it I'd like to set a timeout which will
disconnects the clients if they're inactive (i.e., no command or data
transfer in progress) for a long period of time.
I was thinking about putting the timeout value into an attribute:

def settimeout(self, secs):
self.timeout = time.time() + secs

And then have the readable method call time.time() at every loop to
check if time has passed or not:

def readable(self):
if time.time() >= self.timeout:
self.send("Timeout")
self.close()
return 1

My only concern is if it's a good idea calling time.time() so often.
Since A LOT of clients could be connected simultaneously, couldn't it
be a too much resource-intensive operation?
I'd also be curious to know how Twisted implemented this kind of
stuff.
By calling time.time() at every loop?

Thanks in advance.

Calling time.time() is relatively inexpensive in comparison to pure
Python function calls, but indeed, it could be a bottleneck.

I don't know what Twisted does, but what I would do is to add two
variables to each instance of the class you want to add timeouts to;
self.timeout and self.lastdata . self.lastdata would hold the time
for the last time you sent or received data on the socket, and
self.timeout would hold the delay between when you last sent/received
data and when it should be closed due to idle timeout.

Now, since you are smart, you don't need to alter your handle_send()
or handle_receive() methods in your asyncore subclass. Instead, you
rewrite asyncore.poll() to update .lastdata for every socket that is
in either the reader or writer list, which will result in one
time.time() call. Further, to check for timeouts, you only ever need
to check those sockets that are *not* in the readable or writable
lists...

To be precise, add the following block to your own copy of
asyncore.poll just after the 'for fd in e:' block...

#handle timeouts
rw = set(r) + set(w)
now = time.time()
for f in (i for i in rw if i in map):
map[f].lastdata = now
for j in (map[i] for i in map if i not in rw):
if j.timeout+j.lastdata now:
#timeout!
j.handle_close()

You ARE going to need to initialize .timeout and .lastdata members for
every instance, but that shouldn't be so bad (for a socket that
doesn't time out, I would actually suggest a 1 hour or 1 day timeout).

- Josiah- Nascondi testo tra virgolette -

- Mostra testo tra virgolette -

A really nice hack.
Thank you a lot, Josiah.

[Josiah Carlson]

On Oct 23, 9:30 am, Jean-Paul Calderone <[e-mail]:

On Tue, 23 Oct 2007 15:34:19 -0000, Josiah Carlson <[e-mail]:

[snip]

Calling time.time() is relatively inexpensive in comparison to pure
Python function calls, but indeed, it could be a bottleneck.

Did you benchmark this on some system?

There isn't really any "pure Python function calls" that can replace
time.time() in a sensible way, so I made up one that does some random
things (including calling another Python function) and compared it to
time.time:

exarkun@charm:~$ python -m timeit -s '
def g():
return 1. + 2 + 3 * 4 - 5 / 6 + 7 ** 8
def f():
return g()
' 'f()'
1000000 loops, best of 3: 1.39 usec per loop
exarkun@charm:~$ python -m timeit -s 'from time import time as f' 'f()'
100000 loops, best of 3: 4.68 usec per loop
exarkun@charm:~$

Not really useful in any real-world sense, but I still wouldn't
characterize time.time as "relatively inexpensive."

Of course, for any real-world work, one would want to profile the
application to determine if removing calls to time.time() could
make a worthwhile difference.

The particular function call he was talking about was the .readable()
or .writable() in an asyncore.dispatcher subclass. Now, the trick
with any nontrivial asyncore.dispatcher subclass is that you don't
want to signal a socket as writable if you don't have any outgoing
buffer. Similarly, I have seen subclasses that follows a state
machine very strictly (no pipelining, you must finish sending before
you can receive, etc.). In that sense, typically, both
the .readable() and .writable() methods will reference an attribute or
two of the instance.

After running some tests, I notice that it seems like a not
insignificant platform difference. Because on my platform (Windows
and Python 2.3)...

>>setup = '''def g(): return 1. + 2 + 3 * 4 - 5 / 6 + 7 ** 8'''
timeit.Timer('g()', setup).repeat()

[2.0143674536171798, 1.9778226522165654, 1.9959138650798764]

>>setup = '''

.... class foo(object):
.... __slots__ = 'a', 'b'
.... def __init__(self):
.... self.a = 1
.... self.b = 2
.... def foo(self):
.... return self.a and self.b
....
.... inst = foo()
.... '''

>>timeit.Timer('inst.foo()', setup).repeat()

[1.4185994550779242, 1.4186812879064519, 1.4478852871044694]

>>timeit.Timer('f()', 'f = lambda:None').repeat()

[0.58938552412047329, 0.58762154196472238, 0.58324245809257036]

>>timeit.Timer('f()', 'from time import time as f').repeat()

[0.68104482574668168, 0.64085672667252425, 0.6558844364245715]

So to answer your question, even though I hadn't bothered to test it,
my beliefs regarding time.time() being fast in relation to the
particular operation he was expecting to perform, at least according
to my own experience on the platform I use the most (Windows and
Python 2.3) was relatively accurate, though indeed it is slower (but
not much in comparison to what those calls would typically do).

Then again, in the subclasses of asyncore that I write, I don't bother
calling .readable() or .writable() at all, each socket adds and
removes itself from a pair of readable and writable dictionaries
automatically, thus removing perhaps hundreds of function calls for
every loop of asyncore.poll .

What these experiments also tell me is that fetching the time on linux
is slow. But really, since I already wrote code that handles *all* of
the timeout handling with a *single* time.time() call, and that also
generally minimizes all explicit function calls, I'm not sure that
your testing examples were ultimately germane to the conversation (how
would one handle timeouts in asyncore). Or maybe it's just late and
I've had a long day :/ .
In any case, I'm glad that I was able to help Giampaolo.
- Josiah

[Paul Rubin]

Giampaolo Rodola' <gn****@gmail.comwrites:

def readable(self):
if time.time() >= self.timeout:
self.send("Timeout")
self.close()
return 1

Don't do it this way. Put all the timeouts into a priority queue
(see the heapq module) so you only need to check the one due to expire
soonest.