Bonjour à tous !
 
Je me posais une petite question de conception pour des messages qui transitent entre une application cliente et une application serveur.
 
Je comptais structurer mes messages comme suit :
1er octet : définition de la taille (tt), en octet, occupée pour définir la taille de mon message (dans l'absolu 0 <= tt <= 255, mais en réalité 1<= tt <= 255).
2ième au (tt + 1)ième octet : taille (tm) de mon message (sous forme de chaîne de caractères... en l'écrivant je me dis que je pourrait tout aussi bien le stocker sous forme binaire et utiliser un masque défini en fonction de tt...).
(tt + 2)ième au (tt + 2 + tm) ième octet : mon message.
 
1) Que pensez-vous de ceci ?
2) Si c'est Acceptable, devrais-je plutôt :
   - lire tout ce qui est disponible sur ma chaussette puis trier les messages (cas où plusieurs messages sont en attente) et traiter le cas éventuel de messages tronqués,
   - lire tt puis décoder tm pour ne retirer qu'un message après l'autre (il me semble que c'est plus simple, mais cela nécessite plusieurs appel successifs à la fonction de reception des données...)
 
Merci de vos conseils éclairés et de vos commentaires.

Ca me va. Pour la longueur, tu peux définir un format fixe en bytes, au format réseau (MSB en tête) genre :
 
[0] MSB (8-bit)
[1] LSB (8-bit)

Le 2ème cas. Peu importe les appels successifs... de toutes façons, il faut assembler les messages reçus avant de les exploiter, car on ne sait pas comment ils ont été découpés à l'émission (la taille du buffer d'émission est limitée et peut changer d'un système à l'autre). Il faut d'ailleurs prendre des précautions en ce sens à l'émission en s'appuyant sur la valeur retournée par la fonction d'émsision.

Oui, tu as raison, ce n'est peut être pas la peine de s'ennuyer à définir une taille variable.

Oups j'allais oublier