Face à un problème avec recv() et send() winsock api. Recv() se bloque lors de la réception du dernier paquet

Question

Je suis confronté à un problème avec recv() et send() winsock api. Recv() se bloque lors de la réception du dernier paquet.

Description du problème: -

Système A app est en train d'écrire des données sur un app socket non bloquant et le système B reçoit des données sur une douille de blocage en morceaux de 64k.

Il semble que tout en lisant probablement le dernier paquet de 64k, qui peut être inférieur ou égal à 64k, la réception se bloque. Je ne suis pas sûr si la réception du dernier paquet ou l'envoi du dernier paquet est un problème, mais j'observe ce problème par intermittence dans nos applications héritées.

Est-ce que quelqu'un a déjà fait face à un problème similaire? Si oui, alors s'il vous plaît pouvez fournir vos entrées.

Si non, alors pouvez-vous s'il vous plaît fournir quelques techniques de dépannage pour affiner jusqu'à la cause première.

Juste pour information j'ai des serveurs win2k3.

Merci, Varun

Answer 1

Wireshark est un excellent outil pour le code de réseau de dépannage. Il vous montrera exactement quels paquets entrent et quittent votre interface réseau en temps quasi réel.

En ce qui concerne votre problème spécifique: dites-vous que le dernier segment de données peut être plus court que 64k? Si tel est le cas, votre protocole doit inclure des informations sur la longueur des messages afin que le destinataire connaisse la quantité de données à rechercher.

Answer 2

Quelques suppositions ...

Si vous utilisez UDP, peut-être un ou plusieurs paquets sont abandonnées en cours de route (qui UDP est autorisé à le faire chaque fois qu'il se sent comme). Dans ce cas, votre récepteur pourrait finir par attendre des données qui ne vont tout simplement jamais arriver; Pour résoudre ce problème, vous devez implémenter un moyen de renvoyer automatiquement les données perdues, ou (si vous n'avez pas strictement besoin de toutes les données), un moyen pour l'expéditeur d'informer le destinataire qu'il a fini de transmettre, de sorte que le destinataire pourrait aussi bien cesser d'attendre. (bien sûr, vous devrez gérer le cas où cette notification est abandonnée, aussi ... cela peut devenir compliqué si vous voulez 100% de robustesse)

Si vous utilisez TCP, vous ne vérifiez peut-être pas les valeurs avec attention retourné par send() du côté de l'envoi? Si vous supposez que send() enverra toujours le nombre d'octets que vous lui avez demandé, vous pourriez finir par penser que send() a envoyé tous les octets alors qu'en fait il n'en a envoyé que quelques-uns ... l'expéditeur penserait que la transmission était terminée, alors que le destinataire serait bloqué en attente de données qui ne vont pas arriver.

Answer 3

Vous pourriez avoir un problème avec le serveur envoyant des données sur le fil plus rapidement que le récepteur est capable de le lire. Vous pouvez essayer d'augmenter le tampon de réception:

int nSocketBuffer = 131072; // 128k 
if (setsockopt(m_sSocket,SOL_SOCKET,SO_RCVBUF,(LPCSTR)&nSocketBuffer,sizeof(int)) == SOCKET_ERROR) 
{ 
    // socket error 
    return false; 
}