Unix：recvfrom（）

Question

How to receive message from only desired client if I know that this client has been connected to my server?

recvfrom(sockfd, buf, BUFFSIZE, MSG_PEEK,
                (struct sockaddr *)&addr, &caddrlen);

addr will be replaced by corresponding data, but I want receive data from only one client

Answer 1

recvfrom(sockfd, buf, BUFFSIZE, MSG_PEEK,
                (struct sockaddr *)&addr, &caddrlen); 

if(addr.sin_addr.s_addr == "ADDRESS_OF_DESIRED_CLIENT")
{
//ALLOW USER
}

For IPV4 "addr.sin_addr.s_addr" is an int, but you can also get the Address in a string from.

Answer 2

How to receive message from only desired client if I know that this client has been connected to my server?

You can't really do this with a datagram socket in the AF_INET or AF_INET6 family, unless undesired clients are blocked at a lower level, such as via a firewall. At least, not if you want to be able to continue to receive messages from desired clients after one from an undesired client arrives. The network driver queues datagrams for you, and you need to handle them in order, where the C API for "handling" a datagram is to receive it via one of the several system calls that serve that purpose, such as recvfrom() .

You can discriminate between messages after receiving them, such as by discarding those from undesired clients. However, it is of limited, special-purpose use to retrieve message data without dequeueing it, as the MSG_PEEK flag to recvfrom() provides. In particular, that does not serve your stated purpose -- you will still need to receive every message, via a subsequent call that does not use MSG_PEEK . Instead, I suggest simply reading the data via recvfrom() , checking the address to determine whether it's from the client you're interested in, and handling it appropriately.

If you want to handle multiple clients at the same time, then you have some alternatives. A relatively simple one is to have a function, perhaps running in a dedicated thread, that receives all incoming messages and dispatches them appropriately according to their source addresses. Another alternative is to open a new (datagram) socket for each client, each on its own port, and to set up a protocol by which you tell each client which port to use after their first contact. Datagrams from unexpected clients on these additional ports would be erroneous, and therefore safe to reject.

Of course, the latter of those is an approximation to a connection-oriented protocol. If it seems attractive to you then perhaps you should be looking at stream sockets instead of datagram sockets. Not only would that get you no-fuss client specificity, it would also provide for reliable and guaranteed in-order communication.