Quand un UDP sendto() bloc?

Tout en utilisant la valeur par défaut (blocage) le comportement sur un socket UDP, dans lequel cas un appel à sendto() bloc? Je suis intéressé essentiellement dans le Linux comportement.

Pour TCP, je comprends que le contrôle de congestion rend le send() de blocage d'appel si la fenêtre d'envoi est complet, mais qu'en UDP? Est-il même bloc, parfois, ou simplement laisser les paquets se jeter à couches inférieures?

InformationsquelleAutor Jocelyn delalande | 2010-11-12
  1. 16

    Cela peut se produire si vous avez rempli votre prise de tampon, mais il est hautement dépend du système d'exploitation. Depuis UDP ne garantit en rien votre système d'exploitation peut décider de faire ce qu'il veut lors de votre prise de tampon est plein: bloquer ou supprimer. Vous pouvez essayer d'augmenter SO_SNDBUF pour le soulagement temporaire.

    Cela peut s'appuient même sur le réglage de votre système, par exemple, il peut aussi dépendre de la taille de l'anneau TX dans le pilote de votre interface réseau. Il y a quelques discussions à ce sujet dans le iperf liste de diffusion, mais vous voulez vraiment discuter avec la développeurs de votre système d'exploitation. Portez une attention particulière à O_NONBLOCK et EAGAIN /EWOULDBLOCK.

    • Ok, en suivant votre lien, j'ai trouvé spécifique à linux, explication sur ce thread. Donc, à court simplifié de réponse : Linux ne bloquer sendto sur un plein d'envoi de la mémoire tampon.
    • OK, mais maintenant, la question est poussé juste une étape de plus: dans quelles conditions va Linux laisser le tampon de socket de le remplir? (par opposition à la suppression des paquets hors de lui). C'est malheureusement une question très difficile.
    • que diriez-recv,envoyer quand le support est le blocage? Je pense que dans ce cas, envoyer et recv bloquera de toute façon?
    • selon DS.'s réponse ici. Il semble que SO_SNDBUF pour socket UDP est la limite supérieure de paquets UDP (et donc sendto() jamais blocs). Ou pensez-vous de ce qu'il dit est valable pour UNIX, mais pas Linux? Merci!
    InformationsquelleAutor MarcH
  2. 9

    Ce peut être parce que votre système d'exploitation tente d'effectuer une requête ARP pour obtenir l'adresse matérielle de l'hôte distant.

    Fondamentalement, chaque fois qu'un paquet sort, l'en-tête requiert l'adresse IP de l'hôte distant et l'adresse MAC de l'hôte distant. 192.168.1.34 et AB:32:24:64:F3:21.

    Votre "bloc" comportement pourrait être que l'ARP de travail.

    J'ai entendu dans les anciennes versions de Windows (2k je pense), que le 1er paquet parfois se jeter si la demande est trop long et que vous envoyez trop de données. Un service pack probablement résolu depuis.

    • Ok, bon élément de réponse, intéressant ; mais ce que j'ai intérêt est surtout le blocage (ou de l'absence de blocage) liées à la congestion/tampon complète.
    • ARP est utilisé uniquement pour la localisation des hôtes sur le même sous-réseau - généralement le routeur. Et les résultats sont mis en cache pour la suite envoie.
    • Lorsqu'un paquet IP va il requiert l'adresse IP de l'hôte distant, et l'adresse MAC de la next hop...
    • Personne ne sait si à l'aide de ioctlsocket()/fcntl() avec FIONBIO/O_NONBLOCK serait de garder la prise d'envoyer de blocage due à l'ARP de recherche?
    • Dans mon expérience (avec Windows), si vous essayez de faire un send() lors de l'entrée ARP a expiré, le premier paquet IP est perdu et une requête ARP est envoyée à la place. Si vous utilisez le protocole TCP, le protocole de récupération d'erreur apparaîtra et vous sauver. Si vous avez été en utilisant UDP, votre paquet est perdu. C'est complètement orthogonal à s'envoyer() vous bloque. Pour TCP, je pouvais voir où il pourrait si vous êtes l'envoi d'une grande quantité de données dans un send(). Voir ma question sur le protocole UDP et ARP ici pour plus d'informations.
    • ...mais si vous êtes en utilisant UDP (comme cette question unis) ARP ne sera pas vous bloquer en vertu de toute mise en œuvre que j'ai vu. Votre paquet arrive juste jetés sur le sol.
    • J'ai certainement exécuté dans un cas où l'ARP de recherche causé des blocs dans l'envoi. Je me souviens d'une fois sur un ordinateur Windows 7, j'ai eu une boucle qui va envoyer un paquet UDP à 10 adresses IP différentes par 10 sockets. Si tous étaient des adresses IP valides, valides destinations, tout fonctionnait très bien, mais dès que vous avez modifié une à une IP valide que spécifié un hôte qui n'existaient pas, les envoyer pour que socket pourrait bloquer provoquer la perte de paquets de tous les plus de la place pour tous les sockets. J'ai fait beaucoup de recherche, et a conclu que c'était à cause de l'ARP de recherche, mais il est possible que ma conclusion était erronée.

    InformationsquelleAutor mj_