Hi Jerry,
I think part of the problem is that the client program is always 'active'
regardless of whether it has any data to send and when I start the server,
the server Selects the already active (client) connection, Accepts it,
then does a read which doesn't return anything to which the server returns
to the Select where it waits for other potential clients to make contact.
Yes, that's the normal paradigm for a multiplexing server. However, you
should have some sort of a "reasonable" time limit on how long you wait
for that particular client. I don't mean all clients, or for
connections to be established, I just mean for any connected client, you
should have data within a reasonable amount of time. Maybe 30 seconds?
If you don't have anything, then why keep the connection live? Why not
close it and wait until the client has something to say?
But, again, I don't know enough about your scenario to know whether this
is good or bad advice. It may just be an unusual situation.
I purposely set it to non-blocking so the first client's receive function
doesn't monopolize the program.
Yes, that's what you should always do.
However, I typically code a timeout on my select() statement of
something like 15 seconds or 30 seconds. So even if I don't get any new
data from any of my clients in that time, my program will wake up, it'll
check the %shtdn() BIF to see if the system has requested shutdown, and
it'll check to see how long it's been (individually for each client)
since I've received data.
If it's been more than 30 seconds or 60 seconds or whatever is
appropriate for the scenario, I'll close the socket.
I guess I need to re-think what options I have here. One option is to
simply let the program end when there is no data to be received and cycle
it so that it runs every 30 minutes or so.
I don't understand that at all... you only need your server program to
run once every half hour!? Makes no sense to me. Also, why would you
want to end your server program, instead of just closing the client
socket and accepting the next one?
I'm thoroughly confused by what's happening here.... can you please
explain the scenario a little better? For starters:
a) How many clients do you expect to handle at once.
b) Do the different clients need to communicate with each other?
c) What happens during the conversation with a particular client?
What's the purpose for the connection? How much data is exchanged, and
how often?
In most business software, things happen in transactions. POs are
requested. Orders are placed. Invoices are sent. Remittance is sent,
etc. Or a file is uploaded, or downloaded, etc. There's some sort of a
transaction going on.
Typically, you'd make a connection, handle one transaction, then
disconnect. The time you'd remain connected, would be the time it takes
to complete that transaction, not some arbitrary "30 minutes" or "60
seconds" or "8 hours" type of number. But typically there wouldn't be
much idle time during a transaction... sure, the client might have to
sit and wait while a server validates the data it just sent, but that's
not typically something that would take long... a few seconds at the
most. So there'd be very little idle time during the actual transaction
(barring network lag, of course)
The other paradigm is something like Telnet, where you don't really have
any transactions, and you don't really know what the user is doing.
You're just sending keypresses to the host, and echoing back it's
response... you don't know what the transactions are, so you stay
connected until the user tells you not to. In that scenario, it's
perfectly reasonable to have long idle times -- but not much actually
works like this. That doesn't mean that your application shouldn't
work this way, it just means that it's uncommon.
I don't know enough about your situation to say which way it should
work, and I'm really concerned that you're taking my advice to heart
when my advice is based on generalities and not on your particular
circumstance.
midrange.com
