client server socket interaction (inetd)
drsalists at gmail.com
Thu Feb 17 17:47:33 CET 2011
On Thu, Feb 17, 2011 at 8:14 AM, Tim <jtim.arnold at gmail.com> wrote:
> Hi, I have an inetd service on freebsd that calls a program
> (daemon.py) with which I want the remote user to communicate. I can
> call daemon.py from the command line on the host machine and it works
> What I don't understand is how to make my remote client script
> actually communicate. If I'm understanding correctly, the code below
> just takes a message and sends it to inetd and writes the stdout from
> the process to the client.
> How can I modify the code to send a response back? Here's the
> outline of what I want to do:
> (1) client sends the message to the server (client -> inetd ->
> (2) client receives output back from the server,
> (3) client user responds to a question from the remote process
> (4) client continues to receive output back.
> where 2-3-4 happen as needed by the remote process. Cries out for a
> while loop doesn't it? I just don't know what to put in it. Currently
> I just have steps 1 and 2 working. Client sends one message and gets
> all output back. If server asks a question, processes deadlock with
> server waiting and client unable to respond.
> --Tim Arnold
> # imports, constants set
> #def line_buffer(sock):
> # code to yield the string response in
> # blocks of 1024 bytes
> def client(ip,port,message):
> sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
> for line in line_buffer(sock):
> print line
> if __name__ == '__main__':
> message = ' '.join(sys.argv[1:]) )
> print 'working... %s %s' % (SERVER_IP,SERVER_PORT)
> print 'done.'
You could probably use strace/truss/ktrace to see what each process has done
I wonder if your server process needs to flush its output when writing the
It might help us help you if you post the server code as well. Also, the
client code above doesn't appear to be complete... posting more of that
might help us help you as well. Specifically: does line_buffer() know when
to stop doing its thing?
BTW, when using unbuffered sockets, things are a bit complex - 3 writes in
the server may appear as 1 recv or 4 recv's (or about any other #, including
3) in the client. Usually you'll get 3, but that's not fully reliable.
Sometimes it helps to wrap up your socket in a python file, or to use
something like http://stromberg.dnsalias.org/~strombrg/bufsock.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-list