More then one client process sends messages to a server and receives messages in turn. One client process sends multiple messages to the server. Now, a client process connects to server each time a message is to be sent and messages from different client processes is received in an interleaved manner by server.
How do I recognize a client? I mean, does a client process have an identity value in the server and is it the same for a process even though it connects multiple times.
Thanks
If you need the server to be able to recognise a client, the better solution should be to implement an authentication process. Any other solution may rely on the actual established connection (but this not work if the connection is closed ) or on the IP address of the client (but this not work if there are more client with the same address or if the address change).
The client can be authenticated to the server using a username and a password. If the client and the server share a key, each message exchanged by them could be authenticated with a sign. This way the server can identify the sender despite the IP address of the received packet.
In order to identify clients in your setting, you'll have to have each client send some form of identification as part of each message.
As far as I can see, there's no other reliable way, since you have a brand new connection established every time a client wants to talk to the server.
Unless you're ok with identifying by the client's IP only, you'll need to add some kind of token to the communication. You could (for example) add a message to the beginning of conversation which requests a unique token and then require the same token to be sent in every message from that client.
In order to communicate through a connection, you need to
accept(2)
that connection. WHat does accept tell us ?Address is the "identification" of the connection. So basically you can do it this way:
accept(2)
returns) and its addressNow, the spiny problem is: how do I compare addresses ? Compare each interesting field for your protocol (for the common case with a
TCP
protocol I would compare the IP and the port).Once the connection is up, you will want to "authenticate" the user in some way. If the authentication succeeds you can add this "information" to the identity in your list of connected clients.
There is no way if you don't have a higher-level protocol. Once the socket is closed, the client is gone.
I think your thought is right.
The server and the client must have the unique identifier for each other if the client can connect multiple times.
If the client cannot connect multiple times, the server can identify each clients' 'accept(2)' return value; however, in your case, clients need multiple connects, so you have to design your own protocol to identify each clients.
In my case, in previous project, I made UUID before connecting the server, and I used UUID as the client's identifier. In Mac OS X or Linux, you can include the header file which is located in /usr/include/uuid/uuid.h.
Then, you can get the random 128bit value in 'id'. I used this UUID as clients' identifications. There may be better way to determine each clients.