Salut,
 
 
il me semble que pour programmer un serveur TCP, les choses n'aillent pas forcement de soi.
 
TCP ayant tout un tas de mecanisme pour protéger la connection (détection des paquets manquants, etc...), pourquoi faut-il prévoir des cas compliques de paquets arrivant tronqués (étalés sur plusieurs recv()) et pourquoi n'obtient-on pa de facon garantie, les données d'un paquet et d'un seul paquet seulement ?

TCP te garantit que tu recois tous les octets ( à condition que la connexion reste établie ) , et dans l'ordre. Il ne te garantit pas que tu recevras en un seul recv tes 1000 octets, parce que de l'autre coté tu as envoyé en un seul send tes 1000 octets ( même si c'est très probable que ca soit le cas ).
 
en TCP on est en mode "STREAM" , il n'y a pas de notion de paquet mais juste de flux d'octet.
 
Si tu veux travailler par paquets , tu implémentes ta propre couche, ou tu travailles en UDP ( mais avec d'autres contraintes comme la non garantie d'ordre des paquets, ou de bonne réception du paquet ).

Comme ton protocole TCP va passer par une couche réseau plus "physique" (a priori IP), le redécoupage en paquets plus petits va dépendre du "path MTU" (ie de la taille des buffers de données des machines tout le long du chemin), cf cette explication (succincte) de Wikipedia.
A+,

Ok ok je comprends... en effet TCP garantit pas mal de truc, mais pas ca specifiquement. Merci.