Discussion :

[Kalite]

J'ai un protocole d'échange de données de base nommé P-Protocole.
Ce porotocole peut être encapsuler ou pas dans un autre protocole S-Protocole.
S-Protocole ne peut exister sans P-Protocole.

Les deux protocoles dispose de leur propre commande aux-quelle ils doivent répondre.

Comment pourrait-je faire (Proposition d'autre solution)?

Ma solution :
Utilisation du design pattern décorateur.
ProtocolMng est le composant du design pattern.
La classe TransportProtocol est composé d'un support de communication et d'un ProtocolMng.

P-Protocole est un protocole concret. S-Protocole un décorateur.
Lors de la réception de trame je fait HandleFrame() sur le ProtocolMng. Le S-Protocole désencapsule les données et les fait traiter par P-Protocole.

Mais c'est ici que j'ai un problème.
Lorsque le P-Protocole doit envoyer des données (répondre à une commande) il faut qu'elle soit encapsuler par le S-Protocole.
Tout en sachant que le S-Protocole peut également envoyer des données qui ne doivent pas être encapsuler.

J'ai penser informer le TransportProtocol qu'il y a des données à envoyer. En-suite, le TransportProtocol récupérer les données à envoyer. De cette manière les données peuvent être encapsulée, mais cela fait beaucoup de copie.

PS: Le développement est en C++.

[souviron34]

d'abord "ce qui se conçoit clairement s'exprime simplement"..

Nous sommes dans un forum conception, et tu mélanges allègrement outil, conception, implémentation...


Ensuite, sur le fond, tu manques des phases justement par l'aspectbrouillon :

Trame -> décodage S -> décodage P

encodage P -> encodage S -> trame


C'est pourtant simple...

• P ne doit RIEN connaître de S.
• S doit connaître P

Pour ne pas copier, il faut réfléchir à des structures de données adaptées, sauf si l'encodage des données elles-même est différent entre S et P. Si S est juste un décorateur, une structure judicieuse du côté de S fera qu'il n'y aura pas besoin de copie...

[Kalite]

Nous sommes dans un forum conception, et tu mélanges allègrement outil, conception, implémentation...

Désolé mais je voi pas où dans mon poste je parle d'outil et d'implémentation.
Je suis entraint de faire mes diagrammes UML donc je suis bien dans la conception.

Sinon mon post n'ai effectivement pas tès clair.
Donc, j'ai mon S-Protocole qui encapsule mon P-Protocol.

Donc, je peut avoir les cas suivant:

Trame -> décodage S
encodage S -> Trame

Ou

Trame -> décodage S -> décodage P
encodage P -> encodage S -> Trame
C'est deux cas sont exclisif.

Ca c'est mon problème de base.

C'est pourtant simple...

• P ne doit RIEN connaître de S.
• S doit connaître P

Je suis d'accord avec toi, c'est pour sa que j'ai un problème lors de l'encodage. En effet comment faire pour que les données à envoyer par le P-Protocole soit encapsuler par le S-Protocole.

Les deux protocoles sont différents et je ne peut pas les modifier.

[souviron34]

Désolé mais je voi pas où dans mon poste je parle d'outil et d'implémentation.
Je suis entraint de faire mes diagrammes UML donc je suis bien dans la conception.

L'utilisation de termes tels que : "UML", "Utilisation du design pattern décorateur", "je fait HandleFrame()", etc... réfèrenet à des outils/langages/paradigmes de programmation et non à de la conception..

Passons..

Je suis d'accord avec toi, c'est pour sa que j'ai un problème lors de l'encodage. En effet comment faire pour que les données à envoyer par le P-Protocole soit encapsuler par le S-Protocole.

Les deux protocoles sont différents et je ne peut pas les modifier.

Oui, mais puisque S doit communiquer avec P, c'est que S doit connaître P, non ???


Ou alors l y a franchement quelque chose que je ne comprend pas...

Est-ce que S a UNE SEULE entrée possible, ou DEUX (une pour extérieur et une pour P) ?

Si S n'a qu'une seule entrée possible, soit il peut y avoir un paramètre à insérer dans Trame pour faire comprendre à S que ce n'est pas une trame "de base", soit on ne peut rien faire tel quel.

Si S a 2 entrées possibles, alors c'est simple...

Mais ton problème n'est toujours pas clair...

[Kalite]

L'utilisation de termes tels que : "UML", "Utilisation du design pattern décorateur", "je fait HandleFrame()", etc... réfèrenet à des outils/langages/paradigmes de programmation et non à de la conception..

Passons..

Sauf que moi j'aimerais bien comprendre car j'ai l'impression d'avoir poster dans le mauvais forum.
Dans ce cas là pourrait tu m'indiqué où j'aurai du poster.

Oui, mais puisque S doit communiquer avec P, c'est que S doit connaître P, non ???
Ou alors l y a franchement quelque chose que je ne comprend pas...

Ce que tu a compris est correcte S connait P mais S ne connait pas le format de P. C'est à P de gérer son format.
(Je vois sa comme ça)
Les Trame de P son encapsuler dans des Trame S. C'est à dire qu'il y a un entête et une fin qui appartienne à S afin qu'il identifie que le contenue est à un autre protocole sans savoir lequel.

Sinon je pense avoir trouver la solution à mon problème.
Un fois que P a traité la trame désencapsulée par S, il peut arrivé que P doivent envoyer une réponse. Si P doit envoyer une réponse il doit en "informer" le protocole encapsulateur.
Informer --> Observateur.
Les protocoles sont des sujets.
Le protocole d'encapsulation est un observateur.

[souviron34]

Sauf que moi j'aimerais bien comprendre car j'ai l'impression d'avoir poster dans le mauvais forum.
Dans ce cas là pourrait tu m'indiqué où j'aurai du poster.

Non, pour l'instant c'est correct, c'est juste que ta réflexion est polluée par es termes ou constructions techniques qui n'ont que peu à voir avec l conception...

Ce que tu a compris est correcte S connait P mais S ne connait pas le format de P. C'est à P de gérer son format.
(Je vois sa comme ça)
Les Trame de P son encapsuler dans des Trame S. C'est à dire qu'il y a un entête et une fin qui appartienne à S afin qu'il identifie que le contenue est à un autre protocole sans savoir lequel.

S ne sait peut-être pas le DETAIL du contenu du message envoyé par P, mais sa FORME il doit la connaître...

Sinon je pense avoir trouver la solution à mon problème.
Un fois que P a traité la trame désencapsulée par S, il peut arrivé que P doivent envoyer une réponse. Si P doit envoyer une réponse il doit en "informer" le protocole encapsulateur.
Informer --> Observateur.
Les protocoles sont des sujets.
Le protocole d'encapsulation est un observateur.

Je ne comprend pas, et je subodore que c'est faux..

Encore une fois, P est en bas..

P peut fonctionner seul, sans encapsulateur.. Donc P ne doit rien connaitre de S..

• Si on raisonne sans S :
  Soit une trame de base devant arriver à P:
  
  trame -> P :
  
  Dans P :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  décodage
  décision si envoi réponse
  si  oui
     encodage réponse
     envoi newtrame P -> extéreur
  sinon
     envoi OK ?
  fin si

• Maintenant, si on prend S, on a le même schéma .
  
  trame devant arriver à S :
  
  trame -> S :
  
  dans S :
  
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  décodage
  décision si envoi réponse
  si  oui
     encodage réponse
     envoi newtrame S -> extéreur
  sinon
     envoi OK ?
  fin si

• Si maintenant on ajoute un étage :
  
  trame -> S :
  
  dans S :
  
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  décodage
  transformation formatage vers formatage P
  envoi vers P
      -> traitement normal par P (voir ci-dessus)
      -> éventuellement retour de P
          dans ce cas :
              transformation formatage P vers formatage S
  décision si envoi réponse
  si  oui
     encodage réponse
     envoi newtrame S -> extéreur
  sinon
     envoi OK ?
  fin si

C'est le protocole S qui saura si oui ou non il attend une réponse de P..


Imagine que ce soit une conversation entre 3 personnes. Le premier dit quelque chose au deuxième. Le deuxième retransmet au troisième.

Si ces communications se font par téléphone, par exemple, si je suis ce que tu dis, le deuxième raccroche dès qu'il a transmis le message au troisème. Et donc il ne peut pas entendre la réponse si le troisème lui en donne une... Sinon c'est le troisième qui doit RAPPELER le deuxième pour lui donner une réponse..

La seule autre solution est que tout se passe en asyncrhone, et que les communications soient ouvertes en permanence, et que un dialogue entre 2 puisse être interrompu par la réponse du troisème à une question posée à un moment x donné, sans rapport avec le moment présent...

Alors je ne sais pas dans quel contexte ou pour quelle application tu veux faire ça, et quelle forme a la trame initiale arrivant à S...

De ce que je comprend, ta trame arrivant sur S serait de la forme :

trame S :

• décoration debut
• trame P
• décoration fin

Dans ce cas, logiquement, le dialogue devrait être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
trame S -> S  (S reçoit trame S)
enlever décoration début
enlever décoration fin
trame P -> P
réponse (OK ou trame P)
si OK
   envoi OK ?
   rien (attend prochaine trame S)
sinon
   ajout décoration début
   ajout décoration fin
   S -> trame S (S envoie trame S)
fin si

• Si les protocoles S et P n'envoient aucun accusé de réception même si ils ne doivent pas envoyer de réponse, alors S doit obligatoirement savoir si pour telle trame il doit attendre une réponse ou non.. Il doit donc connaître suffisamment P pour savoir si sur telle trame il doit attendre une réponse.
  
  
• Si les protocoles S et P envoient un simple OK (ou équivalent) dans le cas où ils ne doivent pas envoyer de réponses plus élaborées, alors S doit simplement attendre le retour de P, quel qu'il soit... Et dans le cas où la réponse est différente du OK, ajouter les décorations sans en savoir plus.

[Kalite]

Ton analogie ma permit de comprendre que le fond du problème n'était pas là on je pensait.
Effectivement, lorsque S envoie la trame à P il n'attend pas la réponse.

C'est pour cette raison que je parlait d'observateur afin de faire des messages asynchrone/synchrone lorsque P devait retourner une TRAME de réponse.

Je pense que je vai m'orienté plustot vers cette solution.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
trame S -> S  (S reçoit trame S)
enlever décoration début
enlever décoration fin
trame P -> P
réponse (OK ou trame P)
si OK
   envoi OK ?
   rien (attend prochaine trame S)
sinon
   ajout décoration début
   ajout décoration fin
   S -> trame S (S envoie trame S)
fin si