Multiple clients, single server, same port synchronized socket communication approach

A few thoughts on design / concepts - probably more questions than answers, but hopefully of some help.

First, I think it would help to know why you are using separate ports for each client. After all, a standard web server handling numerous concurrent clients will accept connections from all of them on the same port. If you need to know who you're talking to then it might be better to get clients to identify themselves when they connect (the usual authentication / authorisation / access issues). That would probably be the standard way (if there is such a thing) if all communications will use the same protocol. If you are talking to different clients using different protocols then I can see that using a separate port for each protocol might be sensible.

Second, why do you have a requirement that two clients talk to the same port? What is this aiming to achieve? Is this like online chat, where every message from any client gets relayed to all other clients in a particular chat room? Or like 2 Skype clients being linked together by a 'supernode' server? What is it that links these particular clients and distinguishes their communication from that of any other client? Note that this still doesn't mean that you need more than 1 port to handle the whole caboodle - just that the server needs to be able to link relevant connections in how it handles them.

Third, socket connections are really designed to connect 2 endpoints (broadcasts etc. apart). So to get 3-way communication (server plus 2 clients), your server needs to have some concept of a conversation and which clients are party to that conversation - but each client still has a separate connection to the server. Maybe you divide your clients into groups and each group has a single conversation to itself. Are the groups static / predetermined? Or do they change? If they change, how do you decide what the groups are? Can a client ever participate in more than one conversation / group at once?

Fourth, in consequence you'll need to consider how conversations are initiated (clients might join in any order, need to sort out groups / which conversation to join, how long to wait for other clients etc.) and how conversations end (terminated by server or by client, what happens if a connection is dropped etc.)

Fifth, the server then needs to accept messages from any client in a conversation and relay them to the other clients in that conversation - or process them and generate appropriate responses / messages to those other clients - or do whatever else it does to service that conversation. But communication with clients will still be 1 socket per client.

Sixth, incidentally, what happens if a given client initiates more than one connection to the server? Deny multiple accesses? Treat it like a new client? Or what?

Only once you've sorted out your ideas on all this, would I start thinking about implementation. Yes, multi-threading is almost certainly a good idea (maybe a pool of worker threads to handle inbound / outbound messages rather than having dedicated threads for each client or conversation). I'd avoid any global anything if I possibly could. Classes / objects dedicated to handling connections and conversations seem a better idea. Use synchronization objects (mutexes, wait handles etc.) to co-ordinate messages to / from individual clients so that from a 'conversation' standpoint you only have one client 'talking' at once with messages from other clients queued.

Hello,

Thank you for your response.

Currently different testers (clients) are differentiated using the port numbers. Hence, I would like to maintain the same differentiation. All communication use the same protocol.Though I said two clients should talk through the same port, this is not necessary. Each client can talk to the server using different ports. Sorry for the change in requirement, I realized it later.

It is not like a chat room. Earlier the project had one tester for one PC. Now I need to handle two testers in one PC. The project is to do testing in both the testers, message handling with the server and now the synchronization between these two testers is also important.

It is not 3-way now. With the change in requirement, I believe we can go past the grouping of clients discussion.

Connection initiation, testing initiation, closing is all taken care off for one tester per PC system. Only addition is the two tester working.

Relaying client-server communication, broadcast is not required. One socket per client works.

One client will not initiate multiple connection. In the state machine, definite states are followed at different times.

The only implementation remains is the coordination and message handling of the two testers (from the same PC) with the server. I am overriding the message handling socket functions. Currently, I am trying with two socket class object for each tester. I am finding ways how to identify which function call belong to which tester. As far as the synchronization is concerned, when one tester is performing testing, the second tester has to wait until the first testing process completes.

Please do let me know how should I go about the implementation. As far as possible, I would not like to opt for multithreading.

-Vish