Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1203 connectés 

  FORUM HardWare.fr
  Programmation
  C

  Conception Client/Serveur (résolu)

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Conception Client/Serveur (résolu)

n°1463283
bb138
La vie est belle ...
Posté le 23-10-2006 à 17:00:53  profilanswer
 

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
mood
Publicité
Posté le 23-10-2006 à 17:00:53  profilanswer
 

n°1463312
Emmanuel D​elahaye
C is a sharp tool
Posté le 23-10-2006 à 17:48:06  profilanswer
 

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/
n°1463711
bb138
La vie est belle ...
Posté le 24-10-2006 à 08:51:37  profilanswer
 

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:


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C

  Conception Client/Serveur (résolu)

 

Sujets relatifs
reflexion sur conception site web educatif[Oracle] - Limitation des varchar2 [Resolu]
[Résolu] Récupération automatique de fichier sur Internet[Résolu]Activer le code html sur un forum ? (et le desactiver ici lol)
[Résolu][XHTML/Javascript/W3C] Problème de XHTML dans un JavascriptQuantum DB, client SQL pour eclipse
Lancement d'impression côté serveurC# et application tierce (MS-EXCEL) (résolu)
[Résolu] Changement de couleur au passage de la souris[Résolu]Problème de caractères depuis migration de siteweb
Plus de sujets relatifs à : Conception Client/Serveur (résolu)


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR