[mod_python] webinterface for a local telnet server

Graham Dumpleton grahamd at dscpl.com.au
Fri Oct 6 19:18:13 EDT 2006

On 07/10/2006, at 2:46 AM, Andreas Klauer wrote:

> On Fri, Oct 06, 2006 at 12:14:43PM -0400, Jorey Bump wrote:
>> I think the problem is outside of apache/mod_python. Similar work has
>> been done to develop IMAP proxies to reduce load caused by webmail
>> opening a new connection to the IMAP server for every click. You  
>> might
>> want to start there for examples.
> That's just it. There would be no need for an additional daemon, if I
> could just select the correct thread. A mod_python script by itself
> holds up a telnet connection just fine. No additional work would be
> required in my situation if it were not for threads (or lack of thread
> control for that matter).
> Instead of opening a telnet connection in a mod_python script  
> directly,
> I now have to use an independent daemon, with additional  
> connections to
> every mod_python thread, and I also have to encapsulate each query  
> into
> a separate protocol. If that does not add unnecessary load, I don't
> know what does.
> But I guess for that I'd have to talk to the Apache folks wether it is
> not possible to give modules (and therefore users) more control over
> what is done in which threads.

Personally I think you are possibly working under some misconceptions
about how Apache/mod_python works. You keep mentioning 'threads'
as a problem, but frankly I cannot see how that is really relevant at  

Before I try and address that I would ask why you are trying to perhaps
reinvent the wheel as others have already solved this problem. In the
webmin interface for remotely managing systems, there is a standard
SSH/Telnet Login module that uses a Java applet. There are also other
third party implementations as well. Some sites to start tracking this
stuff down are:


Back to your threads. The problem with using Apache/mod_python when
you want to preserve some state between requests is not threads but
processes. This is because when using prefork or worker Apache MPMs
on UNIX systems, subsequent requests can be directed to different Apache
child processes. As a result, if one child process had initiated a  
connection, when a subsequent request arrives and it ends up being
processed by a different child process, it will not have access to  
the open
connection. On Win32 boxes this isn't a problem, as there is only one
Apache process and all requests are handled by it.

For further information, see:


As far as threads go, on Win32, and when worker MPM is used on UNIX,
when subsequent requests arrive, they may indeed be handled by different
threads within that process, but that shouldn't matter, unless you have
made the mistake of storing state information as thread local data  
that thread such that only that thread can access it. If the data is  
globally, is thread protected and keyed by some user session credentials
then it shouldn't be an issue as it wouldn't matter which actual  
thread handled
a request, as all could still access it.

If you do this correctly, then it would be possible to do what you  
want on a
Win32 system, as the same Apache process is always used. On prefork
and even worker MPMs on UNIX though you can't, as you can't ensure the
same process always gets the requests. Also, even if there were some  
Apache is allowed to shutdown specific child processes at any time,  
so you
would loose any open connection anyway.

If you want to pursue this direction of implementing it yourself, you  
have no
choice but to stick the bits which create the telnet connection in a  
long running daemon process. Communication between the Apache child
processes and the separate daemon could use XML-RPC albeit perhaps
inefficiently, a persistently connected messaging system, or a custom  
over a socket connection.

Writing that daemon isn't necessarily going to be straight forward,  
as making
it secure may be an issue, plus you need to track user sessions,  
implement inactivity timers to cleanup sessions if not used etc etc.

Thus, overall, I would really suggest you pursue some of the Java applet
solutions that exist instead that people have already written.


More information about the Mod_python mailing list