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

Bonjour,

J'ai développé une appli client-serveur avec les winsock2 en me référant aux exemples MSDN, donc à priori dans les règles de l'art.
Le client pose une question ("send").
Le serveur en attente ("recv") reçoit, traite la question et renvoie ("send") sa réponse de dimension variable.
Le client qui s'était mis en attente ("recv") reçoit sa réponse et l'intègre, etc...

Je suis tombé par hasard sur la cas particulier suivant : lorsqu'au gré des questions-réponses le serveur retourne une réponse d'EXACTEMENT 1418 octets, càd que le send a pour paramètre une taille à envoyer de 1418 octets, le recv() du client reste bloqué.
Pour tout envoi de dimension différente (inf ou sup) ça marche. Mon buffer est bien (sur)dimensionné. Pas de débordement.

Du côté client, pour varier le morcellement, j'ai essayé de modifier la taille mentionnée dans le recv(), en petit (1024), en moyen (4096), et en grand... Rien n'y fait.
J'ai essayé en bloquant, non bloquant. J'ai utilisé ioctlsocket avec SO_LINGER pour m'assurer que le flush était correct. C'est vraiment cette dimension qui a l'air de poser pb.
Ca me fait penser à cette erreur algorithmique classique de découpage d'un bloc de dimension N qui est un multiple entier de blocs élémentaires n, et où il faut bien penser au "+1" : nbblocs = N / n ; si (N mod n != 0) alors nbblocs += 1
Est-ce que 1418 ne correspondrait pas à une dimension particulière (liée à la Freebox par exemple) ?

Précisons que je rencontre ce pb entre 2 freebox, je n'ai pas essayé dans un autre contexte matériel (routeur, FAI différents).

Merci pour votre aide.

salut,
il faut que tu postes ton code ici si tu veux être aidé.
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 étant un pb de configuration de ton reseau).
oublie le nombre 1418 ... qu'aurais tu pensé si ca avait été 666 ?

copie colle le code du client et du serveur !!

a+

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

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

Pour info,

1) j'ai bien cru lire quelque part que 1418 est la longueur des buffers internes de TCP/IP gérée par les routeurs... Ce ne serait donc pas une valeur comme une autre.

2) j'ai fait un test entre chez moi (avec "tstsockc") et le serveur (avec "tstsocks") - cf mon code source déposé -, les 2 en freebox dernière version, et ça marche.
Je n'ai donc détecté ce problè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 à priori ça plantera aussi car c'est sur  cet autre serveur que j'avais détecté initialement le problème. Ce qui reviendrait à dire qu'il y a un problème depuis ma freebox "boulot" (pb de routage ?...).

A confirmer.

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

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

Quand ça ne marche pas le problème est le suivant : le send du serveur se fait correctement mais le recv du client reste bloqué jusqu'à retourner un WSAECONNRESET.

J'ai mis à jour le code avec une indentation correcte sur les CPP. Ceci dit, je ne vois pas en quoi il est mal structuré, une fois cette correction faite (remplacement des tabulations par 2 espaces)...

Sinon, A CE JOUR, mon problème ne se produit (systématiquement et de façon reproductible) que depuis mon poste de développement à mon boulot (freebox V1 connectée en USB) vers deux serveurs particuliers dotés d'une freebox dernière génération.
Depuis mon poste, mis à part ce problème tout le reste marche nickel (Internet, applications réseau, etc...)
A+

salut,
essaie de virer ton globalLock, dans ton exemple ta série de questions se fait dans le meme thread.

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à me semble-t'il.
A+