× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.