This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: telnetlib.Telnet.read_very_eager() performance
Type: behavior Stage: resolved
Components: Library (Lib) Versions: 3rd party
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: jackdied, ptz, r.david.murray
Priority: normal Keywords:

Created on 2010-10-23 10:31 by ptz, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg119423 - (view) Author: (ptz) Date: 2010-10-23 10:31
In Python 2.4, Assuming we've imported telnetlib, the following works:

    >>> f = telnetlib.Telnet("some_text_based_server")
    >>> f.read_very_eager()

The last call outputs the text that the server outputs upon connection (e.g. "login: ").

However, if we put this inside a function it does not work:

    >>> def g():
    ...   f = telnetlib.Telnet("server")
    ...   data = f.read_very_eager()
    ...   print data
    ...
    >>> g()

This returns the empty string. I believe this indicates that the data from the server isn't cooked. 

Note that if we use read_until() instead of read_very_eager(), everything works as expected, further supporting the hypothesis that data doesn't cook properly when the functions are called as above.

So why the difference?
msg119425 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-23 12:49
Presumably the difference is that there is a pause between the two statement executions at the interactive prompt (even if you cut and paste) that does not exist in the function.
msg119434 - (view) Author: (ptz) Date: 2010-10-23 15:39
Strange. I was certain that I tried inserting a time.sleep() in the function and it still didn't work, but I tried it just now and it does work as expected. Sorry, and thanks for your answer, at least I learned something.
msg119436 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-10-23 15:52
Well, perhaps when you ran the test with the sleep the target server had an unusually long startup delay.  If you are going to use read_very_eager you are going to have to deal with the possibility of not getting back what you expected, so it doesn't really matter what it's "performance" is :)
msg119589 - (view) Author: Jack Diederich (jackdied) * (Python committer) Date: 2010-10-26 04:37
There was no test suite for telnetlib prior to 2.7/3.1 so it is easily possible that this is a regression.  If you can post a test case that fails or - even better - a patch that passes where the current code fails I'd be very appreciative.
msg119593 - (view) Author: (ptz) Date: 2010-10-26 08:39
As David suggested, it indeed seems to be a case of timing. When telnetlib.Telnet(...) returns, the server still doesn't have the data cooked, and read_very_eager() fetches nothing. So nothing here fails as such, it's just that my 0 experience in network programming showed.

Either way, some things you could do to get the function g() above to fetch the data the server usually returns upon connection are:

a) insert a time.sleep(t) line after creating the socket. But I don't think there is one answer as to what the value of t should be.
b) if one knows the format of the data that will be received, one could use read_until("expected string")
c) one could write something like

    >>> def g():
    ...   f = telnetlib.Telnet("chessclub.com")
    ...   data = ''
    ...   while not data:
    ...     data = f.read_some()
    ...   print data,f.read_very_eager()
    ...
    >>>

This simply loops until the server has some cooked data available, then fetches it. Tested, works, and is probably the way to do it.

Either way, like David wisely said, this isn't an issue with either Python or telnetlib. However, it may be a good idea to add a warning to the documentation to the effect that by the time the Telnet constructor returns cooked data is typically not yet available from the server. To a beginner network programmer, this is far from obvious.
History
Date User Action Args
2022-04-11 14:57:07adminsetgithub: 54385
2010-10-26 08:39:52ptzsetmessages: + msg119593
2010-10-26 04:37:05jackdiedsetnosy: + jackdied
messages: + msg119589
2010-10-23 15:52:37r.david.murraysetmessages: + msg119436
2010-10-23 15:39:17ptzsetmessages: + msg119434
2010-10-23 12:49:28r.david.murraysetstatus: open -> closed

nosy: + r.david.murray
messages: + msg119425

resolution: not a bug
stage: resolved
2010-10-23 10:31:24ptzcreate