On Feb 17, 6:09 pm, Martin Gregorie <mar...@address-in-sig.invalid> wrote: > On Thu, 17 Feb 2011 13:02:08 -0800, Tim wrote: > > But. The server may encounter a problem > > during the process and ask the user for more information like > > 'abort/retry' or something like that. > > Servers never ask the client for information: they are strictly request/ > response handlers. To do what you're asking about, you'll need to change > both the client and server: > > - the client must analyse every response and, if necessary, ask for > more input from the user. IMO it would be best to design it so it > can accept several commands, with 'quit' being one of them. Either > that or all request/response pairs must be designed so that the client > can always send a single request, output the result and exit no matter > what the server returns. > > - the server must always return a response to every possible request > or log a failure reason, preferably to the system log which is > /var/log/messages in Linux, and die. The server must thoroughly > validate requests and return an adequate error message if errors were > found. I'd strongly suggest that every request generates a single > (newline terminated?) response message because that makes error > detection much easier. If the response is multi-line, send it as a > single line, possibly as a comma-separated list, and let the client > format it for display > > I tend to precede every request and response message with a fixed length > byte count: this way the recipient process always knows how many bytes to > read and can report errors if the received length is wrong. Using an 'end > of message marker' (NEWLINE unless a message can legally contain internal > newlines) can also be useful. I tend to put an error flag in the response > message because this simplifies the client. I also design all messages to > be plain ASCII because this makes debugging a lot easier. If things > really turn to worms you can use wireshark to watch the traffic and read > it straight off the screen without needing to decode binary values, etc. > So, an invalid request and response might look like this: > > Request: "0013,WHOIS,elvis\n" > Response: "0030,ERROR,Unknown request: WHOIS\n" > > > The inetd configuration is: > > myservice stream tcp nowait root /local/daemon.py daemon.py > > From what I recall about inetd that should be OK - I guess it must be > since you can get one request through, and I assume (you didn't say) that > a second request is also accepted without restarting the server. > > -- > martin@ | Martin Gregorie > gregorie. | Essex, UK > org |
Thanks for helping me to understand. I don't know if you're familiar with LaTeX, but that's part of what daemon.py calls via subprocess, and that is the underlying process I wanted the user to be able to interact with. When LaTeX encounters a problem it stops processing, asks the user what to do (like abort/retry, kind-of), and does whatever the user says. The daemon.py script handles that okay from the command line, but if I'm understanding you this will be much harder if not impossible to accomplish from a client communicating over a socket. I thought that maybe I needed to fork the socket (somehow) so it could listen after the message is sent, but it looks like it will be more complex. thanks, I'm going to back to reading more on socket programming. --Tim -- http://mail.python.org/mailman/listinfo/python-list
