2016-04-04 2 views
0

J'ai 2 programmes. 1 serveur et 1 client.Que se passe-t-il lorsque nous faisons networkstream.write()?

Dans le client, il va quelque chose comme ceci:

while(statement) 
{ 
    networkstream.write(data); 
} 

Et dans le serveur, il va quelque chose comme ceci:

while(statement) 
{ 
    while(statement) 
    { 
     ReceiveData; 
    } 

    Do other stuff; 
} 

Ainsi, alors que le client peut écrire dans le flux de réseau très rapide , le serveur doit toujours s'occuper des données avant de pouvoir en lire plus. Que se passe-t-il lorsque le client a déjà effectué 4 tours de la boucle contenant l'écriture alors que le serveur n'a encore lu qu'une seule fois par exemple.

Y at-il un moyen de faire savoir au client quand il peut faire une autre écriture? Et aussi ce qui arrive quand le client fait plusieurs '.write'? Le serveur les garde-t-il tous et les lit-il tous ou les données envoyées sont-elles écrasées?

J'espère que vous pouvez comprendre ma question. Editez le titre de la question si vous le désirez.

+1

networkstream.Write est synchrone. Il attend que les données soient envoyées. networkstream.WriteAsync ne l'est pas. Lequel utilisez-vous? Les deux ont la mécanique pour assurer assez écrire/lire – ntohl

+0

En ce moment je l'ai comme ceci: 'networkstream.Write (SendingBuffer, 0, currentPacketLength);' – meme

+0

http://stackoverflow.com/questions/1611582/how-does-networkstream -work-dans-deux-directions qui devraient aider – ntohl

Répondre

3

Il existe une pile de couches entre votre .write et les fils réels. Les couches font toutes sortes de choses, de la correction d'erreurs à s'assurer que vos trafics réseau ne se heurtent pas avec d'autres etc .; Non, ils vous fournissent un tampon et un blocage (si vous avez envoyé trop de données ou - du côté récepteur - il n'y a pas encore de données).

Pour répondre à votre question, quelque part le long de la ligne sera un tampon (un morceau de mémoire) où vos octets sont écrits. Jusqu'à ce qu'ils soient envoyés à l'arrêt suivant en cours de route, ils bloqueront (attendre/se bloquer ...). Ces appels se déplacent le long de la pile, du côté réception, puis de l'autre côté et de nouveau vers le haut. Ainsi, lorsque votre write revient, vous pouvez être raisonnablement sûr que tout va bien, sauf si vous obtenez un code d'erreur, une exception ou quel que soit le traitement de votre erreur.

Si le serveur est lent lors du traitement de vos demandes, il ne sera pas à read aussi vite que vous le souhaitez, de sorte que les tampons entre vous et eux se rempliront, à quel point l'écriture s'arrête.

Il y a aussi beaucoup de tampons différents sur différentes couches, une réponse complète serait assez complexe. https://en.wikipedia.org/wiki/OSI_model