Réception de trame.

Réception de trame. - Algo - Programmation

Marsh Posté le 07-12-2011 à 14:02:07    

Bonjour,
 
Je cherche à savoir s'il y a une "Bonne pratique" pour l'implémentation de la réception de trame d'un protocol donné.
 
Indépendamment du type de source ( réseau ou mémoire de masse ), je pose le problème de la manière suivante :
 
J'ai une fonction de lecture bas niveau READ, à qui je fourni un descriteur de média à lire, un buffer à remplir et la taille maxi du buffer.
En retour la fonction indique la quantité d'information réellement lu.
Pour le moment tout va bien...
 
J'ai un protocole qui fourni la structure des trames.
En général, il y a un header dont la taille n'est pas forcément fixe qui contient souvent le type de trame et la taille des données de la trame.
Ensuite on a généralement les données.
Enfin parfois on a un footer (avec ou sans CRC (au sens large)).
 
Je vois plusieurs approches pour implémenter la réception des trames (sans tenir compte de la gestion des erreurs).
 
La première qui me vient naturellement :
 
1 Utiliser READ pour lire l'entête (ou une partie si elle est de longueurs variable)
2 Analyser la partie lue pour savoir quelle quantité de donnée je doit lire pour continuer.
3 Continuer 2 jusqu'à fin du header. A ce moment je sais quelle est la taille des données à lire.
4 Allouer un buffer asser grand et lire les données (et probablement aussi le footer).
5 Mettre les données à disposition de la couche fonctionnelle.
 
Autre méthode que je vois souvent utilisée sans bien comprendre pourquoi :
 
1 Boucle de lecture sans fin avec un buffer à taille fixe.
2 A chaque réception, appeler une fonction qui se charge de décoder la trame
 
La fonction de décodage de la trame a tout le temps une trame disponible à remplir.
Celle-ci peut se trouver dans différents états : Vide, header_lu, en_cours_de_reception_des_données, ...
Quand une trame est lue en totalité, on la met à disposition de la couche fonctionnelle.
 
Quelle est votre préférence et surtout pourquoi ?
Que dise les "Bonnes pratiques" s'il y en a ?
 
J'ai déjà indiqué quelle méthode je préfère, mais je ne sais pas donner d'autre raison que "C'est comme çà que je réfléchi".
 
Salutations,
Mara's Dad.


Message édité par Mara's dad le 07-12-2011 à 14:03:33

---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 07-12-2011 à 14:02:07   

Reply

Marsh Posté le 08-12-2011 à 10:47:17    

Bon, en gros la question est de savoir s'il vaut mieux mixer la lecture et le décodage de la trame ou les séparer, c'est à dire empiler dans un coin ce qu'on reçoit et laisser à un autre processus le soin de le décoder.
 
Personne n'a d'idée ?
 
Une petit précision quand même qui me fait encore une fois pencher pour la première solution.
Souvent, la trame indique son type : "Data" ou "Commande de gestion du protocole" (Fin de session, vérification de l'état de la connexion, découpage en plusieurs trames...)
De plus, dans le cas d'une "Commande de gestion du protocole", il est souvent nécessaire de réagir immédiatement.
 
A+


Message édité par Mara's dad le 08-12-2011 à 10:48:34

---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 08-12-2011 à 12:12:28    

La deuxième méthode, c'est pour quand tu ne sais pas à l'avance quelle est la taille des données que tu vas recevoir. Tu te contentes de remplir ton buffer et de transmettre les données au fur et à mesure à la fonction de décodage qui l'appelle et qui décide, elle s'il est nécessaire de lire le buffer à nouveau en fonction de ce qu'elle a déjà reçu. Les données peuvent être traitées au fil de l'eau, ce qui évite de saturer la mémoire.


---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien
Reply

Marsh Posté le 08-12-2011 à 22:19:15    

Bon, pour parler franchement, c'est un serveur WebSocket que j'implémente.
 
Je viens d'en voir une ici : https://gitorious.org/qtwebsocket/q [...] Socket.cpp
 
Ben pour une fois je me sens moins seul !


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Sujets relatifs:

Leave a Replay

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