2010-02-19 8 views

Répondre

1

L'option SO_RCVTIMEO que vous avez définie sur le socket est en réalité un temporisateur d'inactivité. En d'autres termes, en configurant RCVTIMEO, vous vous assurez que l'appel recvfrom reviendra après l'expiration du délai même si aucune donnée n'a été reçue. Il ne semble pas que ce soit exactement ce que vous essayez de faire.

Il y a plusieurs façons de faire ce que vous demandez ... voici quelques idées.

Si vous êtes à l'aise avec les signaux, vous pouvez utiliser 'setitimer' pour suivre votre délai maximum. Il enverrait votre processus un SIGALRM à l'expiration de la temporisation, et dans votre gestionnaire de signal, vous pourriez définir un drapeau qui indique à votre boucle recvfrom pour quitter.

Vous pouvez également saisir l'heure système à votre point de départ, puis l'interroger dans votre boucle recvfrom pour voir si vous avez dépassé la valeur de délai d'attente souhaitée. http://dell5.ma.utexas.edu/cgi-bin/man-cgi?gettimeofday+2

+0

Merci d'avoir répondu? J'ai encore une question avant de continuer ... J'ai enlevé la fonction de fcntl() et maintenant cela fonctionne encore, car il y a aussi un délai. Mais maintenant, chaque réponse prend 500 ms, ce qui n'était pas le cas lors de l'appel de recvfrom une fois. Pourquoi se comporte-t-il comme ça? Faut-il arrêter la boucle dès qu'il n'y a pas de données obtenues à partir de recvfrom? Il semble que maintenant il ne retourne que lorsque le délai d'attente atteint ... –

+0

Le recvfrom est un appel bloquant. Donc, s'il n'y a pas de paquets et que vous n'avez pas défini SO_RCVTIMEO (ou O_NONBLOCK), il bloquera pour toujours. Je suppose que vous avez pris la route du signal, ce qui entraînerait l'interruption de l'appel de recvfrom à l'expiration du temporisateur. – sckor

Questions connexes