Re: How to service multiple socket clients

Buck,
    Do these different clients need to be able to talk to each other
directly?  Does Client 1 need to be able to send data directly to Client
2, etc?

If not, you'd probably be better off using the paradigm in chapter 7 of
my sockets tutorial.   Using that method, your programs can be normal
procedural programs without the need for keeping track of states or
multiplexing sockets.

Another idea, if you do need to be able to exchange data between the
different clients, would be to combine the two paradigms.   Have two
servers, one that accepts the clients and submits a job for each,
accessible from the outside, and one that's only bound to the loopback
interface which allows you to send communications between the processes.

(of course, you could also use messages or data queues for interprocess
communications)

Finally, if all else fails, you'll be stuck with the "state machine" type
server.   Very few different server apps have a lot of different states.
Perhaps the server should just be executing "commands" send by the client,
and the sequence of those commands should be determined by the client?



On Fri, 19 Oct 2001, Buck Calabro wrote:

> I'm working with sockets and have a mental block.  I want to be able to
> service multiple clients in one program (need the shared storage and
> database access) but I can't seem to work out the details.  Basically, I
> started out with an array to hold the info for each client; stuff like
> socket descriptor#, user/pass, current key for database and so on.  My first
> processing loop looked like this:
>
> loop
> select()
>   check for new client
>     (if new client, add to client array)
>   spin through array looking for input
>     (if input, run "process" subr)
> repeat loop
>
> The "process" subr handles things like:
> validate user ID
> validate password
> parse command:
>   get next order
>   get order header
>   get order detail
>   update order quantity
>   cancel order
>   ...
>
> This is a problem because while the program is processing the request for
> client 1, all the other sockets are "stalled."  If it takes a minute to
> negotiate the login dialogue, the other clients might time out.  So I went
> through Scott's tutorial (awesome examples!) and saw that his method
> basically works like this:
>
> loop
> select()
>   process new client
>   add each client's input to a buffer (multi occur DS)
>   add outbound data to client output buffer (MODS)
>   process each buffer
> repeat loop
>
> This is better, but now I need to keep track of the status of each client
> because the original processes are no longer atomic (obviously - that was
> the whole idea!)  So now my login sequence can be:
>
> read LOGIN from client 1
> read GET NEXT ORDER from client 2
> send USER prompt to client 1
> read "smith" from client 1
> send "12345" to client 2
> send PASS prompt to client 1
> read GET ORDER HEADER from client 2
> ...
>
> Scott uses a "state" variable, so the program can tell how far each atomic
> dialogue has progressed.  For instance, a client cannot be allowed to
> request the next order number unless it has been validated for userID and
> password.  This works, but results in a very large SELECT statement to
> handle all the possible states a client can be in.
>
> I started thinking about a recursive "process" function, where I'd
>
> loop
> select()
>   check for new client
>     (if new client, add to client array)
>   spin through array looking for input
>     (if input, run "process" subr)
>       send LOGIN prompt
>         spin through array looking for input
>         (if input, run "process" subr)
>         ...
> repeat loop
>
> But I don't see an easy way to crawl back up the stack, because I can't
> guarantee what clients will do what.  Is it time to abandon the idea of
> multiple clients here and go with a simple "listener/talker" that sends
> requests to a spawned client server?  Do all the "long" work asynchronously
> and have the socket program handle communications chores only?  How do I
> handle atomic operations like a login sequence that need to run in order?
>
> Ow, my head hurts.
>   --buck