Remarque: la prise est configurée pour bloquer les E / S.
edit: whoops, il n'y a pas de tel que NetworkStream.write uniquement jusqu'à ce qu'il place les données à envoyer dans le tampon d'envoi TCP ou bloquera-t-il jusqu'à ce que les données soient réellement ACK'D par l'hôte récepteur?
tcpclient.write bien sûr! Nous avons tous compris que nous parlions de tcpclient.getstream (). Écrire , qui est en fait NetworkStream.write !
3 Réponses :
tcpclient.write bloquera jusqu'à ce que le tampon de paquet ait été rincé sur le réseau et que les ACK (s) appropriés ont été reçus. Vous remarquerez qu'une connexion abandonnée finira généralement par lancer une exception sur l'opération écrit , car elle attend le ACK mais n'en en obtient pas dans la période définie.
Je suis en désaccord avec les deux réponses [cet état qu'il bloque]. L'écriture sur la prise TCP / IP ne bloque pas si la mémoire tampon sous-jacente est déjà pleine de données de décès. Généralement, il ne bloque pas mais se fait simplement à la mise en œuvre du TCP. Mais bien sûr maintenant, je dois suivre certaines références pour atteindre cet objectif :)
de so
Il semble de voir votre réponse pour être correct sur mono, alors que les autres réponses semblent être correctes sur Windows. Je suis extrêmement confus. J'espère que vous trouverez des références, car je ne trouve rien de concluant.
sauf si .NET utilise autre chose que Winsock, alors selon la référence Winsock:
La réussite d'une fonction d'envoi n'indique pas que les données ont été livrées et reçues avec succès au destinataire. Cette fonction indique uniquement que les données ont été envoyées avec succès.
Si aucun espace tampon n'est disponible dans le système de transport pour contenir les données à transmettre, Envoyer bloquera si la prise n'a été placée en mode anti-bloque. Sur les prises orientées à flux anti-streaming, le nombre d'octets écrits peut être compris entre 1 et la longueur demandée, en fonction de la disponibilité des tampons sur les ordinateurs du client et du serveur.
En supposant que l'écriture appelle l'envoi en dessous, une interprétation stricte de la documentation Winsock indiquerait qu'il n'y a pas de gurantie que les données le rendaient à l'autre extrémité du tuyau lors de son retour.
Voici le lien vers les documents Winsock que je cite: http://msdn.microsoft. COM / EN-US / Bibliothèque / Windows / Motop / MS741416 (v = vs.85) .aspx
+1 pour montrer une référence. Je n'ai pas encore trouvé d'autre documentation sur ce sujet, alors je suppose que ce que vous citez est probablement correct.
+1 Bon travail sur la référence (il était étonnamment difficile de trouver des docos sur quelque chose que je viens de prendre pour acquis)
(Et oui, .Net utilise les prises OS qui sont Winsock sous Windows.)
@ user957902 Cela signifie donc sous Windows, nous ne savons jamais si les données ont été reçues avec succès dans les pairs distants? J'ai fait des tests, même si je débranchai le câble, les données peuvent toujours être écrire (octets) sans aucune exception (j'attendais une autre 20 minutes).
@Shawn c'est correct. C'est pourquoi il existe des protocoles de communication qui renvoient l'accusé de réception des données envoyées afin que vous sachiez que les données sont arrivées au niveau de l'application. Au moins avec un flux de socket TCP, vous savez que la pile de protocole sous-tendante applique que les données doivent arriver dans l'ordre dans lequel elle a été envoyée.
@ user957902 Donc, je suis confus, pourquoi choisir TCP comparer à UDP, nous avons toujours besoin d'ajouter un mécanisme ACK de niveau d'application pour les deux.
@Shawn UDP ne garantit pas que les données que vous envoyez arrivent dans l'ordre de l'envoi, ou si les données deviennent à l'autre extrémité. C'est une sorte de protocole "Envoyer et Pray". Donc, non seulement vous devez vous inquiéter des données qui arrivent à l'autre extrémité, mais de commander correctement une fois qu'elle arrive et détecte si des pièces manquent. Le protocole TCP prend en charge tout cela pour vous.