Threading and TCP server

[Andrew McGregor]

--On Thursday, February 06, 2003 20:33:50 -0800 Ehab Teima 
<ehab_teima at hotmail.com> wrote:

> Jp Calderone <exarkun at intarweb.us> wrote in message
> news:<mailman.1044555974.4801.python-list at python.org>...
>> On Thu, Feb 06, 2003 at 09:17:27AM -0800, Ehab Teima wrote:
>> > Hello,
>> >
>> > I am getting started with using threads and server. I wrote the server
>> > that waits forever until it gets called from the client. The client
>> > would send a command to the server to be executed on the server
>> > machine(sort of rsh but with piping between the client). The server
>> > would handle the client in a separate thread. The code works fine if
>> > the command to be executed is short. The problem I have is when the
>> > client passes something like "ls && sleep 60", the server can not
>> > respond to any other client until it releases this client. Is there a
>> > way to make the server alert without disconnecting the client that
>> > casues the long delays.
>>
>>   At least two options exist:
>>
>>     Extend your use of threads to include whatever sys call (I'm assuming
>> os.system()) you're passing commands to.  That is, call os.system("sleep
>> 60") from a separate thread from the main server.
>>
>>     Use os.popen() or os.openpty() to execute the commands, and then
>>     handle the resulting file objects asynchronously.
>
> I am not sure this will work. I am already using os.popen to launch
> the process. Also, the whole client request, including the popen call,
> is handled on its own thread. In other words, the popen call is handle
> within the client thread as well. Therefore, I do not think that
> adding another thread for that specific popen call will help. The
> problem disappears when I use spawnv with os.P_NOWAIT since it does
> not wait for the process to finish. Any other method that waits for
> the process, does trap the server.
> Aside from that, openpty is only available on Unix, the code has to
> work on three Unix platforms in addition to Windows.

You're right, it won't work.  Instead, when you wait for a new connection, 
use the accept() method of your socket.  Pass the socket returned by 
accept() to a new thread that handles the interaction and closes it's 
socket when done, and in the original thread go back to listening on the 
old socket.

Have you thought about the security implications of doing this?  If that is 
important you probably want a secure way to do this, a good bet being SSH.

>>   Stepping back from the specifics and looking at the problem as a whole,
>> I'd recommend using something like Twisted -
>> http://www.twistedmatrix.com/ - to solve this problem.  It handles the
>> process abstraction for you, it handles multiplexing clients for you, it
>> does all the socket code, and it doesn't even rely on threads.

Not a bad idea, but probably overkill unless you want to use SSH.  If you 
do, this is the best way to go about it.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20030208/a4e9e3f4/attachment.sig>