Déconnecter et reconnecter un socket datagramme connecté

Question

Iam essayant de créer un serveur itératif basé sur les sockets datagrammes (UDP). Il appelle se connecter au premier client qui l'obtient du premier appel recvfrom () (oui je sais que c'est pas vraiment se connecter). Après avoir servi ce client, je déconnecte le socket UDP (appelant en contact avec AF_UNSPEC) Ensuite, j'appelle recvfrom () pour obtenir le premier paquet du prochain client.

Maintenant, le problème est que l'appel de recvfrom () dans la deuxième itération de la boucle est de retour 0. Mes clients ne jamais envoyer des paquets vides, donc ce qui pourrait se passer.

est ce que fait Iam (pseudo-code):

s = socket(PF_INET, SOCK_DGRAM, 0)

bind(s)

for(;;)
{
  recvfrom(s, header, &client_address)  // get first packet from client
  connect(s,client_address)  // connect to this client
  serve_client(s);
  connect(s, AF_UNSPEC); // disconnect, ready to serve next client
}

EDIT: J'ai trouvé le bogue dans mon client d'envoyer par mégarde un paquet vide. Maintenant, mon problème est de savoir comment faire le client attendre pour être servis au lieu d'envoyer une demande en nulle part (serveur est connecté à un autre client et ne sert aucun autre client encore).

Answer 1

connect () est vraiment tout à fait inutile SOCK_DGRAM.

L'appel connect ne vous empêche pas de recevoir des paquets d'autres hôtes , ni ne vous empêche de les envoyer. Il suffit de ne dérange pas, ce n'est pas vraiment utile.

CORRECTION: oui, semble-t-il ne vous empêche de recevoir des paquets d'autres hôtes. Mais faire cela dans un serveur est un peu stupide parce que tous les autres clients seraient en lock-out pendant que vous étiez connect () ed à un. vous aurez également besoin encore attraper « la balle » qui flottent autour. Il y a probablement des conditions de course associées à connect () sur une prise dgram - ce qui se passe si vous appelez connecter et paquets d'autres hôtes qui sont déjà dans la mémoire tampon

En outre, 0 est une valeur paquets de retour valide à partir recvfrom (), comme vides (pas de données) sont valides et peuvent exister (en effet, les gens les utilisent souvent). Donc, vous ne pouvez pas vérifier si quelque chose a réussi de cette façon.

Selon toute vraisemblance, un paquet d'octets zéro était déjà en attente.

Votre protocole devrait être conçu pour minimiser les risques d'un être mal interprété datagrammes errante; pour cette raison, je vous suggère de ne pas utiliser les datagrammes vides, et d'utiliser un nombre magique au lieu.

applications UDP doivent être capables de reconnaître les paquets de « paillettes » et les laisser tomber; ils se tourneront tôt ou tard.

Answer 2

man connect:

...
If the initiating socket is not connection-mode, then connect()
shall set the socket’s peer address, and no connection is made.
For SOCK_DGRAM sockets, the peer address identifies where all
datagrams are sent on subsequent send() functions, and limits
the remote sender for subsequent recv() functions. If address
is a null address for the protocol,  the  socket’s  peer  address
shall be reset.
...

Answer 3

Juste une correction qui que ce soit en cas stumbples à travers cela comme je l'ai fait. Pour déconnecter connect () doit être appelé avec le membre sa_family de sockaddr mis à AF_UNSPEC. Non seulement passé AF_UNSPEC.