client server socket interaction (inetd)

[Martin Gregorie]

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       |