Hello All,

I am working on a client/server system (written in C, using TCP/IP sockets). There is a central server handling all clients. There could literally be 50 to 100 clients out there trying to connect at one time to send data to the server. Each client connects, pushes data, disconnects, waits 5 seconds, then continues the cycle. Currently, the code doesn't seem to be working very well. E.g., I am not getting all of the records that the clients are pushing.

I ran a test with "nc" (from a client box, to my server, with my port number). In many cases nc took 2 to 50 minutes just to connect and send data. That would seem to indicate that the server was busy and had a bunch of requests queued up. Yes/no?

In reading up (Stevens book, web searches), I saw there are different methods for servers serving up multiple clients. I was hoping to get some of you knowledgeable folks to direct me to some examples.

I have seen some cases where the server executes 'accept' then forks off a process to do the actual work (read the socket, process, etc). This method seems like something I might want to pursue.

I have seen other cases where some suggest using 'threading'. But I have also seen some discounting that method since you are using shared memory and that could lead to bugs/leaks.

I am open to any suggestions. I didn't see a good 'fork' example in the Stevens book or a good 'thread' example.

I appreciate all help. Thank you.

Bill

http://lmgtfy.com?q=socket+bind+listen+accept+fork

http://www.tutorialspoint.com/unix_s...er_example.htm

Here's an example with fork:
http://beej.us/guide/bgnet/output/ht...entserver.html

Thank you linosaurusroot and suicidalegroll for your responses.

I am still trying to come to grips with the code that I inherited. I noticed that in between the listen and accept they stuffed in a 'select'. If I am a single server accepting connections from multiple clients what purpose does having the 'select' serve me? I don't see that they are doing much with the select in the inherited code. All examples I have seen (some that you have pointed me to) don't have use a select.

Any ideas?

thank you,
Bill

Depends on the example.

The select puts the process to sleep while waiting for input from one or more file descriptors.

The advantage this has is that you can have a single process (one descriptor is listening). When any connection is made the select returns which descriptors have data for processing.

If the descriptor is the listening socket, then it can accept the connection, and add the new descriptor to the list of descriptors that may have data. If it is a data descriptor, then it can process it, returning any other data.

In either case, when the select returns, all descriptors that have data should be processed.

The problem with this is that all processing is sequential - thus two data channels will not be processed in parallel - one will be waiting until the other is completed (though not necessarily disconnected - just the data from the socket is read, processed, and any return data sent). This makes response appear slow if there are very many connections.

The advantage of the forking (or thread) server is that each connection is handled by an independent process (or thread). Thus much more responsive as the separate connections are handled in parallel. The usual problem with a forking/threaded server is the processing of the data. If the application is a database (for instance) then appropriate locking, transactions, and other synchronization has to be done... otherwise the data would get corrupted. Now, this is less of an issue if the application is just a message exchange, though the "processed" data returned to the connection may have to support queuing data for return so that the messages sent to the user (within limits - if it remains below a certain size, a sendmsg can be atomic (I think this would be much easier when it is threaded).

select is also useful for timing ... if you want a bot in an IRC channel giving you alarms before the expiry of some timer (e.g. while playing an online game) you can't leave the bot blocked until it next sees traffic.

And the fork model (if the server processes are independent) is simple and you can verifiy there are no resource leaks when the short-lived processes exit.

Thank you for your responses. I very much appreciate it. The biggest issue with my server application is the number of clients concurrently trying to connect. So far, in tests, the forking method seems to have cleared up that issue. I see where select can be helpful too, but if I am reading your responses correctly the select may not be needed here.