Programming

Yes, I guess that is what it is sort of meant to do but it is sort of a problem.

Scenario:
Server is running and is blocked at ACCEPT
Client A connects with server
Server returns from ACCEPT and moves to RECV call waiting for incoming string
Client B connects with server
Client B sends string
Client B closes
Client A sends string
Client A closes
Server prints Client A string
Server closes connection to Client A
Server loops back to ACCEPT (still keeps the same bind and listen)
Server immediately sees Client B connection request
Server returns from ACCEPT and moves to RECV
Server immediately sees string and prints it.
Server prints Client B string

So the problem is that the client has come and gone before the server has even started working for it. Is there any way the client connection can be refused if the server isn't ready to accept it yet? I guess removing the accept queue or setting it to zero or something?

Thanks,
Kevin

I'm not understanding the problem. The server doesn't have to accept() until it wants to, and clients will have to wait for the server to accept() before they can send anything (or until TCP timeout). If your clients don't always bother to wait for a reply, that would be their problem.

Hi Corona,
Thanks for the reply.

What you are saying is correct if I was setting up a protocol and ack'ing all over the place. But what the boss wanted was a client that dumped off the data and left. Sooo....

But I think I may have just stumbled on to the answer myself.
listen(socket, QUE_LEN);
I'm thinking by setting my queue length to 1 the incoming connect requests will get refused. So off to try that.

Thanks much,
Kevin

TCP doesn't do that. The connecting process itself makes you wait.

Making your queue small will just prevent most of your clients from connecting at all when the server's busy, imagine russian roulette with 5/6 cylinders full.

Two ways to solve this.

1) Create threads to handle connections. The main program just does accept(); create_thread(); accept(); create_thread(); The threads do the communication. The clients won't have to wait for client1 to finish before they can connect. They might still wait a little just because connections take time to make -- you can't avoid that with TCP. And if the server's down, they'll wait an entire 10 minutes before giving up.

2) Use a connectionless protocol, probably UDP. Clients won't have to connect at all, just throwing a packet towards IP address 1.2.3.4 on port 5678 does the job. They won't even wait for the packet to get through, they won't even know if it gets through. The server can read and reply at its leisure.

Again Corona, thanks for the reply.

What yr saying is not lost on me. Boss/Project Manager is making me keep to these specs. They don't want to spend the time multi-threading this. Their belief is that the server is going to be writing everything it gets to a SQLite DB (read - no transaction manager) and if there is only 1 thread we don't have to create mutexs for access the the DB file (SQLite runs 1 file that it makes act like a DB). So by making sure the sure is only doing 1 thing at a time they believe it helps them. Also the clients are running flat out sniffing the wire, discovering packets and they don't want the client waiting around.

It took me 1.25 days to create the base server class and 1 day for the base client class and they consider that too long - they didn't want to wait another 1-2 days for multi-threading

Also if a client can't connect it comes back right away.

Thanks for everything - "I luv this site baby - good reading"
Kevin