Conception Client/Serveur (résolu)

Conception Client/Serveur (résolu) - C - Programmation

Marsh Posté le 23-10-2006 à 17:00:53    

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.

Message cité 1 fois
Message édité par bb138 le 24-10-2006 à 11:25:59
Reply

Marsh Posté le 23-10-2006 à 17:00:53   

Reply

Marsh Posté le 23-10-2006 à 17:48:06    

bb138 a écrit :

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.


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)

Citation :


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...)


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.


Message édité par Emmanuel Delahaye le 23-10-2006 à 17:51:16

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 24-10-2006 à 08:51:37    

Citation :

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)


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

Citation :


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.


Oups j'allais oublier  :jap:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed