Mon problème est dans le titre :
Winsock découpe tout en paquets et ne s'occupe pas de les recoller.
Est-ce que c'est vrai ou c'est moi qui fait un blocage ?
Parce que ce foutu controle ne simplifie pas la vie s'il faut envoyer des paquets de 6 octets pour etre sur que ca arrive en un morceau ...
Si qqun peut m'éclairer sur le sujet, je suis un peu perdu.
Je sais que sous Unix et en C, quoi qu'on envoie sur le réseau (en un seul appel à l'équivalent de Winsock1.SendData), même si les données correspondantes prennent 10Mo, l'autre machine connectée ne recevra l'énénement de réception (équivalent de DataArrival) que quand les 10Mo seront arrivés...

Bref, qqun a les idées suffisamment claires pour me dire où je m'égare, et le cas échéant, comment faire ?

Merci d'avance
KB

Salut,

He oui, la vie est dure, mais non, WinSock de reconstitue pas lui même les trames que tu envoie.

C'est à toi de gérer les flux.

Pour ça, je te conseil de gérer une mémoire tampon (un buffer de réception) dans la quelle tu mettra les données reçus par la socket et d'ajouter un caractère (ou une chaine) de fin de trame pour savoir quand la réception des données est complète.

A chaque réception, tu test si le caratcère de fin fait parti des données reçues.

Je te conseil des caractères non affichable comme NULL ou GS pour notifier ta fin de trame.

j'espère que c'était claire.

Ciao

Merci pat35 pour ta réponse qui me fixe les idées sur les capacités du controle winsock de vb.

Mais mon incompréhension demeure sur un point :
Si par ex, mon programme client veut envoyer deux requetes indépendantes au serveur (deux appels à SENDDATA), chacune tenant en un paquet de quelques 100 octets, et qu'il les envoie presque au meme instant, eh bien le ctrl winsock ne trouve rien de plus intelligent à faire que de les envoyer en un bloc, le serveur ne sachant que faire de ce paquet, qu'on y ait incorporé des caracteres de controles de partout , ou non...

Je serais-je trompé dans mon observation du comportement du controle winsock?

Salut,

Ton problème ne viens pas tant du fait que ton client envoie les trames simultanément (ou presque) que du temps que met ton serveur à lire et traiter les messages (obligatoirement plus long que le temps d'émission).

En fait, que les envois aient étés simultanés ou non, windows concatène tous les messages non lues par ton serveur à chaque lecture sur la sockets. Donc si ton serveur rame, tu aura le même problème.

Pour éviter de rendre les message illisibles, il faut :
1 - Ajouter un délimiteur à la fin de chaque messages envoyés.

2 - Mettre les messages reçus dans une variable statique et ne traiter les message que si la mémoire tampon contient le délimiteur de fin. Si le tampon contient le délimiteur, il faut extraire la chaîne jusqu'au délimiteur, traiter la chaîne puis supprimer la chaîne traitée du tampon et recommencer tant que le délimiteur est trouvé.


Tu peux trouver un exemple dans le source que j'ai posé sur le site, ça devrai t'éclairer sur ce mode de fonctionnement.

Je te remercie , je vais regarder ta source des que possible (chui en plein concours lol).

Donc d'après ce que tu dis , je dois me résoudre à envoyer des paquets sans aucune garantie d'arrivée en blocs déterminés...

Ton système est bien le bon , mais il reste vulnérable à la possibilité de présence dans les données transférées, du délimiteur en question :) meme si cela n'arrivera qu'une fois toutes les années bissextiles, ca peut arriver quand on envoie des données aléatoires comme une image ou du son ou que sais-je...

Bah, merci encore !

Salut,

Un dernier message pour te dire que tu peux en théorie trouver un ou des caractères qui ne se retrouvent pas dans les données que tu transfert. Le caractère NULL par exemple se retrouve très rarement dans uns donnée.

De plus, tu peux gérer des sécurités. Comme par exemple ajouter un autre caractère avant celui que tu as choisi comme délimiteur si il est transmit comme donnée.

En fait, c'est pas si compliqué de créer un protocole propre et efficace, ça demande juste un peux de traitement de contrôle à la réception des données.

Bon, ben amuse toi bien à ton concours.
Ciao.