Que se passe-t-il avec les paquets TCP entre deux appels Socket.BeginReceive ?

Question

J'ai un doute sur la programmation des prises. Je suis en train de développer un renifleur de paquets TCP. J'utilise Socket.BeginAccept, Socket.BeginReceive pour capturer chaque paquet, mais lorsqu'un paquet est reçu, je dois traiter quelque chose. Il s'agit d'une opération rapide, mais qui prendrait quelques millisecondes, puis j'appelle à nouveau BeginReceive.

Ma question est la suivante : que se passe-t-il si des paquets sont envoyés alors que je suis en cours de traitement et que je n'ai pas appelé BeginReceive ? Les paquets sont-ils perdus, ou sont-ils mis en mémoire tampon en interne ? Y a-t-il une limite ?

Answer 1

Dans le monde linux, le noyau les met en mémoire tampon pour vous - je suppose que le monde Windows fait la même chose. Mais éventuellement, comme l'a dit deltreme, la mémoire tampon débordera (il y a certainement une limite) et il y a une possibilité que les données soient abandonnées en silence.

Si vous faites quelque chose d'aussi lourd que quelques millisecondes par paquet, alors vous pourriez envisager d'utiliser un threadpool pour libérer le thread réseau. En d'autres termes, tout ce que votre thread réseau devrait faire est de saisir le paquet et de le placer dans une file d'attente pour qu'il soit traité par un autre thread, puis de retourner écouter le réseau. Un ou plusieurs autres threads peuvent récupérer ces paquets de la file d'attente et les traiter - l'avantage est que vous pouvez même être en mesure de traiter plusieurs paquets à la fois, ce qui permet d'économiser de l'overhead. Ici, votre file d'attente agira comme un tampon et vous pouvez contrôler sa taille et définir votre propre politique de suppression.

Answer 2

Ils sont mis en mémoire tampon, mais je ne sais pas à quel niveau ni quelle est la limite.

http://tangentsoft.net/wskfaq/ est une excellente ressource que vous pourriez trouver utile pour tout problème lié à Winsock.

Answer 3

TCP vous offre un flux fiable, de sorte que les données ne sont pas perdues (en supposant que le réseau sous-jacent ne tombe pas en panne).

Le système d'exploitation des deux extrémités dispose de tampons qui prennent en charge les octets lorsque vous ne les lisez pas. Ces tampons ont une taille limitée, s'ils se remplissent, le TCP a un contrôle de flux - essentiellement l'extrémité émettrice découvrira que les tampons sont pleins et arrêtera d'envoyer jusqu'à ce qu'un espace supplémentaire soit disponible.