Yggdrasil/infotro/SDi/protocol_development.md

<header><h1>
Protocol developement
</h1></header>

# OSI model
Le modèle OSI (Open Systems Interconnection) est un cadre conceptuel qui divise les fonctions d'un système de
communication en sept couches. Chaque couche offre des services spécifiques et communique avec les couches adjacentes
pour assurer l'interopérabilité des systèmes. Les sept couches du modèle OSI, de la plus haute à la plus basse, sont :
Application, Présentation, Session, Transport, Réseau, Liaison de données, et Physique.
Ce modèle facilite le développement, la compréhension et la standardisation des protocoles de communication.
![osi_model.png](medias%2Fosi_model.png)

Dans un flux de données, les informations traversent ces couches de la couche Application à la couche Physique à
la source, puis sont reçues et traitées de bas en haut à la destination. Chaque couche ajoute des en-têtes spécifiques
et effectue des opérations pour assurer une communication efficace et fiable.

![dataflow_in_layer_model.png](medias%2Fdataflow_in_layer_model.png)


<details>
  <summary><b><u>Exemples</u></b></summary>

  ![layers_protocols.png](medias%2Flayers_protocols.png)

</details>

# Element de protocol
Un protocole est un ensemble de règles qui définit le format et la séquence des messages échangés entre les entités
d'un système de communication. Les entités communiquent entre elles en échangeant des messages. Chaque message est
composé d'un en-tête et d'un corps. L'en-tête contient des informations de contrôle et le corps contient les données
à transférer. Les entités peuvent être des processus, des machines, des systèmes, etc.

## Notions en rapport avec les protocoles
Les notions suivantes sont essentielles en rapport avec la spécification des protocoles :

- **(N)-service :**
  Un service de la couche N.

- **(N)-service provider :**
Le soumissionnaire du service, généralement la couche N.

- **(N)-service user :**
L'utilisateur du service, généralement la couche N+1 ou N-1.

- **(N)-service access point :**
Voie à un certain service. Un service n'est utilisable que si son SAP est connu.

- **(N)-service primitif :**
Éléments de base pour l'utilisation d'un service. Ce sont les suivants, et uniquement les suivants :
Request - Confirmation et Indication - Response.

- **(N)-service data unit :**
Informations qui sont traitées par un service et qui arrivent aux éléments de base en tant que paramètres.

- **(N)-layer :**
La couche N, soit le soumissionnaire des services de cette couche, soit l'utilisateur des services d'une autre couche.

- **(N)-protocol :**
Les règles de communication entre deux couches de même niveau.

- **(N)-entity :**
Instance de service d'une couche.

- **peer-entity :**
Instances de service de la même couche qui communiquent ensemble au moyen d'un protocole.

- **(N)-protocol data unit :**
Paquet virtuel de donnée qui est transporté à l'autre entité paire au moyen d'un protocole.

<details>
<summary><b><u>Exemple SAP</u></b></summary>

![example_SAP.png](medias%2Fexample_SAP.png)

![overview_protocol_example.png](medias/overview_protocol_example.png)

</details>


# Stratégie de conception de protocoles
Un modèle OSI à 7 couches est souvent trop complexe pour les systèmes embarqués. Il est donc nécessaire de définir
une stratégie de conception de protocoles adaptée aux contraintes de ces systèmes. 

## Stratégie 3 Couches
La stratégie 3 couches définit trois couches de communication. Elle facilite le codage avec moins d'interfaces.

1. **Couche Application :**
  - Correspond aux couches 7 (Application), 6 (Presentation) et 5 (Session) du modèle OSI.
  - Gère la logique applicative, la présentation des données et la gestion des sessions.

2. **Couche MAC (Medium Access Control) :**
  - Englobe les couches 4 (Transport), 3 (Network) et 2 (Data Link) du modèle OSI.
  - Gère le contrôle d'accès au support de transmission, le routage, et les fonctions liées à la liaison de données.

3. **Couche PHY (Physical) :**
  - Équivaut à la couche 1 (Physical) du modèle OSI.
  - Se charge des aspects physiques de la transmission des données, tels que la modulation, la fréquence, et la connectique.

![strategie_3layers.png](medias%2Fstrategie_3layers.png)

Cette stratégie divise les responsabilités de communication en trois niveaux distincts, facilitant la modularité,
la maintenance et l'interchangeabilité des composants du système.

## Stratégie RX-TX
La stratégie RX-TX définit deux processus par couche :

1. **Processus RX :**
  - Reçoit les données de la couche supérieure.
  - Traite les données reçues.
  - Envoie les données à la couche inférieure.

2. **Processus TX :**
  - Reçoit les données de la couche inférieure.
  - Traite les données reçues.
  - Envoie les données à la couche supérieure.

![strategie_rx_tx.png](medias%2Fstrategie_rx_tx.png)

Chaque processus peut avoir un ou plusieurs SAP pour l'accès aux différents processus.
Cette stratégie permet de séparer les processus de réception et d'émission des données, facilitant la maintenance
et l'interchangeabilité des composants du système.

## Stratégie SAP
La stratégie SAP définit la manière dont les services sont accessibles à l'extérieur. Il existe deux approches possibles :

1. **Single SAP :**
  - Un seul SAP pour accéder à un service unique.
  - Exemple : Un SAP pour accéder à la couche MAC.
  - Avantages : Facile à implémenter, facile à utiliser.
  - Inconvénients : Pas de distinction entre les services.

2. **Multi SAP :**
  - Un ou plusieurs SAP pour accéder à un ou plusieurs services.
  - Exemple : Un SAP pour accéder à la couche MAC et un autre SAP pour accéder à la couche PHY.
  - Avantages : Distinction entre les services, flexibilité.
  - Inconvénients : Plus complexe à implémenter, plus complexe à utiliser.

![strategie_sap.png](medias%2Fstrategie_sap.png)

Cette stratégie permet de définir l'accès aux services de communication, facilitant la modularité et l'interchangeabilité
des composants du système.

## Stratégie de mémoire
La stratégie de mémoire définit la manière dont les données sont transférées entre les couches. Il existe deux approches
possibles :

1. **Copier les données :**
  - Copie des données entre les couches.
  - Avantages : Facile à implémenter, facile à utiliser.
  - Inconvénients : Utilisation de la mémoire, complexité de gestion de la mémoire.

2. **Référencer les données :**
  - Référence des données entre les couches.
  - Avantages : Utilisation de la mémoire, facilité de gestion de la mémoire.
  - Inconvénients : Plus complexe à implémenter, plus complexe à utiliser.

![strategie_memory.png](medias%2Fstrategie_memory.png)

Cette stratégie permet de gérer efficacement la mémoire, facilitant la maintenance et l'interchangeabilité des composants
du système.

## Stratégie de découplage
La stratégie de découplage définit la manière dont les données sont traitées entre les couches.
Il existe deux approches possibles :

1. **Utilisation de files d'attente :**
  - Utilisation de files d'attente pour traiter les données de manière asynchrone.
  - Avantages : Facile à implémenter, facile à utiliser.
  - Inconvénients : Perte d'informations pendant le traitement.

2. **Utilisation de mécanismes de synchronisation :**
  - Utilisation de mécanismes de synchronisation pour traiter les données de manière synchrone.
  - Avantages : Pas de perte d'informations pendant le traitement.
  - Inconvénients : Plus complexe à implémenter, plus complexe à utiliser.

![strategie_decouplage.png](medias%2Fstrategie_decouplage.png)

Cette stratégie permet de traiter les données de manière efficace, facilitant la maintenance et l'interchangeabilité
des composants du système.

# Implémentation de protocoles par un example
Une pile de communication fictive dispose d’une couche Application, Network et RTX.
Au niveau de la couche Application, des données peuvent être échangées.
De plus, on peut demander à la couche Network d’établir une connexion.
La couche RTX est simplement responsable pour l’envoi et la réception des trames.
Si un nœud n’est pas connecté, sa couche Network envoie périodiquement des messages d’avertissement (Advertisings).
Le canal 0 est réservé pour cela.
Des messages d’avertissement reçus d’autres nœuds sont rapportés par la couche Network à la couche Application pour que
celle-ci puisse décider avec quel autre nœud elle veut se connecter.
Une fois une connexion établie, des données peuvent être échangées mutuellement et sur demande.
L’échange des données n’est pas sécurisé (Request-Indication).
Une connexion est définie par le numéro du canal utilisé par la couche Network (un, deux ou trois).
Le numéro est choisi pendant l’établissement de la connexion.
Sur demande de l’une des deux couches Application, une connexion peut être terminée.
Dans ce cas, la couche Network recommence l’Advertising.
La méthode pour découpler les différentes couches est celle qui est illustrée par la figure ci-dessous.
Elle est uniforme dans tout le système.
Soient les classes AppE, NWE et RTXE. La lettre E signifié Entity.

###### Exercice 1

<b><i><u>Question</u></i></b><br>
Dessinez un premier diagramme de classe qui montre les différentes couches de votre système et leurs classes respectives. Esquissez les dépendances.

<details>
<summary><b><i><u>Réponse</u></i></b></summary>

```plantuml
@startuml
Application.AppE .-down-> Network.NWE
Network.NWE .up-> Application.AppE

Network.NWE .-down-> RTX.RTXE
RTX.RTXE .up-> Network.NWE

@enduml
```

</details>



###### Exercice 2
Dans une prochaine étape, il s’agit d’ajouter aux classes les méthodes nécessaires.

<b><i><u>Question</u></i></b><br>
Présentez dans un tableau les services offerts, respectivement utilisés par chaque couche.
<details>
<summary><b><i><u>Réponse</u></i></b></summary>

| Services        | Application | Network   | RTX      |
|-----------------|-------------|-----------|----------|
| *Data*          | required    | provided  |          |
| *Advertise*     |             | provided  |          |
| *Connection*    | required    | provided  |          |
| *Disconnection* | required    | provided  |          |
| *Transfer*      |             | required  | provided |


</details>

###### Exercice 3
<b><i><u>Question</u></i></b><br>
Appliquez maintenant la méthode de découplage présentée ci-dessus pour réaliser les services dans les différentes couches.
<details>
<summary><b><i><u>Réponse</u></i></b></summary>

![kroki-umlet](medias%2Fprotocole_exercice_class.uxf)

</details>