Click here to Skip to main content
14,970,515 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
Hello everyone,

I currently have many clients and a server TCP socket communication setup. The port numbers are fixed to the clients. For one of the ports, my requirement is to have two clients to the system which talk to the same port. There are threads running at the server and I would prefer minimum code change at the server side. Both the clients talking to the same port work stand alone and communicate with the server like any other client as it is currently. It is now also important for me to synchronize the working of these two clients.

I am using a simple MFC SDI C++ application project. My socket class is derived from CAsynsocket. How should I go about the new implementation? What should be a good approach? There is no scalability issue, I mean its not that I will have more than two clients tomorrow talking with the same port.

-Multithreading
-Define different socket objects for the two clients and make code changes in the overriding functions OnReceive(), OnConnect() etc accordingly. Take care of synchronization using global flags updated by the objects perhaps?

Thank you.

-Vish
Posted

http://www.codeproject.com/script/Articles/ArticleVersion.aspx?aid=12209&av=9290

I am following the above link for my project. The only requirement is now to handle two clients with one server.

Things to do would be:

-Set up two tester/socket connection from the PC with the server
-Identify the function calls corresponding to tester
-Synchronize the testing. Only one tester can perform the testing at a given time.

-Vish
   
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
   
v2

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900