|
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 mailing list archive is Copyright 1997-2025 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.