Discussion :

[cosmoff]

Bonjour,

voila j'ai crée un client TCP sur mon smartphone qui transmet les entiers 1,2,3 jusqu'à 10000, et mon serveur recois les messages et les enregistre dans un fichier texte. Le serveur écrit chaque entier qu'il recoit sur le fichier texte puis fait un retour chariot. Ainsi, j'aurais donc un ficher texte de la forme :
1
2
3
...
Le problème est que parfois je me retrouve avec des retours chariots, par exemple si j'émet 555, le serveur écrit sur le fichier texte
5
55

au lieu d'écrire tout simplement
555

j'ai aussi des fois des symboles bizarre qui apparaissent sur mon fichier texte.

Avez vous une idée du probleme et comment je peux le résoudre. Ce qui m'étonne c'est qu'en général ca marche mais dans quelque cas j'ai parfois des retour chariot et des symboles bizarre.

Merci d'avance pour votre aide

[Bousk]

Salut,

TCP envoit les données sous forme de flux, et en tant que tel il n'y a rien qui les sépare par défaut.

[dinobogan]

De ce que j'ai compris, un programme client envoie des octets qui, mis à la suite les uns des autres, représentent tous les nombres de 1 à 10000. Il n'y a aucun autre octet envoyé. Par contre, tu ne dis pas si c'est une chaine de caractères ou des entier 32bits, 64bits... Puisque le serveur peut recevoir un morceau d'un nombre, je suppose que tu transmets des chaines de caractères.
Dans une communication TCP, ce sont des octets qui sont échangés. C'est à toi de faire ton protocole, entre autre dire combien d'octets sont envoyés.
Lorsque le serveur lit les données, il peut lire un nombre indéterminé d'octets lorsque la fonction de lecture se termine.
Quand le client envoie "555" au serveur, il peut se passer pleins de choses sur le réseau comme des latences par exemple. Donc la fonction de lecture sur le serveur peut lire une partie des octets envoyés par le client, le reste est en cours d'acheminement sur le réseau. Donc la fonction de lecture peut lire un seul octet, par exemple "5", puis la lecture suivante peut lire 2 octets, donc "55".

Pour illustrer, le client pourrait lui-même écrire un retour chariot entre chaque nombre. Le serveur pourrait simplement écrire ce qu'il reçoit dans un fichier. Tu verras que le début du fichier est correct. Par contre, il peut se passer des trucs bizarre en fin de fichier car le client ne dit pas quand la transmission est terminée. Soit le serveur arrête de lire avant la fin de l'émission, soit il attend de lire alors que le client à déjà terminé.

Un protocole ultra-simpliste en TCP pourrait être :

• envoyer 1 octets : représente la taille de la chaine à envoyer
• N octets : chaine à envoyer

Le serveur lit toujours 1 octets, puis lit toujours les N octets suivant.

Dans ce protocole, tu peux imaginer ajouter pleins d'autres choses. Par exemple, une fin de transmission de liste. Ca pourrait être le premier octet à zéro puis un octet à 1.