Blocage socket recv() lorsque send() a envoyé 1418 octets - entre 2 freebox

Question

Bonjour,


J'ai d&#233;velopp&#233; une appli client-serveur avec les winsock2 en me r&#233;f&#233;rant aux exemples MSDN, donc &#224; priori dans les r&#232;gles de l'art.
Le client pose une question ("send").
Le serveur en attente ("recv") re&#231;oit, traite la question et renvoie ("send") sa r&#233;ponse de dimension variable.
Le client qui s'&#233;tait mis en attente ("recv") re&#231;oit sa r&#233;ponse et l'int&#232;gre, etc...


Je suis tomb&#233; par hasard sur la cas particulier suivant : lorsqu'au gr&#233; des questions-r&#233;ponses le serveur retourne une r&#233;ponse d'EXACTEMENT 1418 octets, c&#224;d que le send a pour param&#232;tre une taille &#224; envoyer de 1418 octets, le recv() du client reste bloqu&#233;.
Pour tout envoi de dimension diff&#233;rente (inf ou sup) &#231;a marche. Mon buffer est bien (sur)dimensionn&#233;. Pas de d&#233;bordement.

Du c&#244;t&#233; client, pour varier le morcellement, j'ai essay&#233; de modifier la taille mentionn&#233;e dans le recv(), en petit (1024), en moyen (4096), et en grand... Rien n'y fait.
J'ai essay&#233; en bloquant, non bloquant. J'ai utilis&#233; ioctlsocket avec SO_LINGER pour m'assurer que le flush &#233;tait correct. C'est vraiment cette dimension qui a l'air de poser pb. 
Ca me fait penser &#224; cette erreur algorithmique classique de d&#233;coupage d'un bloc de dimension N qui est un multiple entier de blocs &#233;l&#233;mentaires n, et o&#249; il faut bien penser au "+1" : nbblocs = N / n ; si (N mod n != 0) alors nbblocs += 1
Est-ce que 1418 ne correspondrait pas &#224; une dimension particuli&#232;re (li&#233;e &#224; la Freebox par exemple) ?


Pr&#233;cisons que je rencontre ce pb entre 2 freebox, je n'ai pas essay&#233; dans un autre contexte mat&#233;riel (routeur, FAI diff&#233;rents).

Merci pour votre aide.

cosmobob · Answer

salut,

il faut que tu postes ton code ici si tu veux &#234;tre aid&#233;.

je coupe court a tes questions philosophiques sur la taille du buffer;
il y a 99% de chance que ton pb vienne d'un bogue (les 1% restant &#233;tant
un pb de configuration de ton reseau).

oublie le nombre 1418 ... qu'aurais tu pens&#233; si ca avait &#233;t&#233; 666 ? 



copie colle le code du client et du serveur !!



a+

cosmobob · Answer

poste un code que d'autres personnes puisse compiler, pour voir si ton pb est reproductible ...

cs_billbaxter · Answer

ok, mon code est d&#233;pos&#233;.
2 projets visual studio : le serveur TstSockS et le client TstSockC.
D&#233;riv&#233; d'un projet existant pour mettre en &#233;vidence mon probl&#232;me.
@+
En attendant je vais essayer avec d'autres config mat&#233;rielles.

cs_billbaxter · Answer

Pour info, 

1) j'ai bien cru lire quelque part que 1418 est la longueur des buffers internes de TCP/IP g&#233;r&#233;e par les routeurs... Ce ne serait donc pas une valeur comme une autre.

2) j'ai fait un test entre  (avec "tstsockc") et le serveur&#231;a marche.
Je n'ai donc d&#233;tect&#233; ce probl&#232;me qu'entre ma machine du boulot et le serveur en question. Je testerai demain entre ma machine du boulot et un autre serveur, mais &#224; priori &#231;a plantera aussi car c'est sur  cet autre serveur que j'avais d&#233;tect&#233; initialement le probl&#232;me. Ce qui reviendrait &#224; dire qu'il y a un probl&#232;me depuis ma freebox "boulot" (pb de routage ?...). 

A confirmer.

cosmobob · Answer

mais quand ca marche pas quel est ton probl&#232;me ?????

le send te renvoie SOCKET_ERROR ?!? ou tout se passe correctement mais rien n'arrive?

cosmobob · Answer

ps: ton code est cela dit mal structur&#233; et surtout super mal indent&#233;, ce qui le rend difficilement lisible !!

cs_billbaxter · Answer

Quand &#231;a ne marche pas le probl&#232;me est le suivant : le send du serveur se fait correctement mais le recv du client reste bloqu&#233; jusqu'&#224; retourner un WSAECONNRESET.

J'ai mis &#224; jour le code avec une indentation correcte sur les CPP. Ceci dit, je ne vois pas en quoi il est mal structur&#233;, une fois cette correction faite (remplacement des tabulations par 2 espaces)...

Sinon, A CE JOUR, mon probl&#232;me ne se produit (syst&#233;matiquement et de fa&#231;on reproductible) que depuis mon poste de d&#233;veloppement &#224; mon boulot (freebox V1 connect&#233;e en USB) vers deux serveurs particuliers dot&#233;s d'une freebox derni&#232;re g&#233;n&#233;ration. 
Depuis mon poste, mis &#224; part ce probl&#232;me tout le reste marche nickel (Internet, applications r&#233;seau, etc...)
A+

cosmobob · Answer

salut,

essaie de virer ton globalLock, dans ton exemple ta s&#233;rie de questions se fait dans le meme thread.

cs_billbaxter · Answer

Je pourrais effectivement optimiser le code en faisant dans le client :
1) cBytesRead = recv (ServerSock, lpBufCour, 8192 - dimLus, 0) ;
2) n'appeler qu'une fois le WSAStartup
3) Locker et Unlocker en dehors de la boucle Question (i)
Mais bon, le noeud du pb n'est pas l&#224; me semble-t'il.
A+

Blocage socket recv() lorsque send() a envoyé 1418 octets - entre 2 freebox

9 réponses

Votre réponse

Discussions similaires