[SOLVED] Maximum Ports per process?

[kcinmumbai]

Hi,

I'm trying to build a multi-threaded server "C" program connecting to multiple clients. For various design reasons, I thought of having one port number per client. What is the maximum number of ports my process can handle?

Regards,
CK

[Rubberman]

Why (multiple ports)? What does this accomplish? This is NOT standard network programming behavior! Depending upon what you REALLY want to accomplish, there are much easier ways (probably) to accomplish that, so please try to explain in detail what you want to accomplish.

[kcinmumbai]

1. This server code logs pattern based analysis of all messages. Each client is actually a processing system with its own message format

2. Currently, all that those systems do is to dump data on this socket after its own processing. I didn't want to force standard message format across them.

3. Due to data volume I expect, I didn't want to check each message before processing it to appropriately allocate a thread to it.

4. Requirement is also to temporarily disable any of the client [without affecting the socket status] so that only the processing is held up.

[Rubberman]

1. This server code logs pattern based analysis of all messages. Each client is actually a processing system with its own message format

Fine.

2. Currently, all that those systems do is to dump data on this socket after its own processing. I didn't want to force standard message format across them.

Not a problem.

3. Due to data volume I expect, I didn't want to check each message before processing it to appropriately allocate a thread to it.

You don't have to. I'll explain below.

4. Requirement is also to temporarily disable any of the client [without affecting the socket status] so that only the processing is held up.

Not sure what you are getting at here, but I assume you mean that the client won't continue until you send some sort of reply? Clarification on this would help, if you please.


Back to #3. Typically, a server used the accept() function to allow a connection request from a client, which returns the actual socket that the client will be using to send messages to the server. Then the server can create a thread for that specific client's data that come in on that socket. Another main thread will use select() to determine which sockets have data available, waking up the threads associated with those sockets so they can receive the data (or close the socket if the client has shut down) and process it accordingly. Doing this with ports is problematic since what you want to do was never intended for ports. If you have a limited number of message formats, then each client that uses one of them could connect to a more specialized port, but I wouldn't recommend more than a dozen or so used that way.

[kcinmumbai]

Hmmm.... I'll test with single port

But won't recv() alone suffice in the client threads? Why would select() be used?

Anyway, I don't want the thread to do anything else before data arrives.

[Rubberman]

Usually you would have them (the threads) wait on a semaphore specific to that thread, which the thread that does the select() will release, letting the thread in question that is waiting for that socket know that there is data waiting for it, and go into recv().

This is pretty common TCP/IP client/server processing stuff. You should really read some books and such on the subject if you are going to delve into this domain. There are a lot of pitfalls and details to be aware of. More than can be covered here. That's why I am a consultant. Companies who need a jump start pay me big $$ to come in, review their design and code, and get their engineers going in the right direction. I stay for awhile, and then leave them to finish the heavy lifting (coding & testing), only calling me back in when they have a serious problem.