12.4. Établissement de liaison et négociation des capacités

La caméra et l’hôte arrivent tous deux au niveau du transport avec leurs propres idées sur la façon dont le protocole doit fonctionner : quels modes de CRC, si les ACK sont requis, quelle est la plus grande charge utile qu’ils peuvent mettre en tampon. Avant que le trafic réel ne démarre, ils échangent un établissement de liaison qui fixe ces paramètres pour le reste de la session.

12.4.1. L’hôte ouvre la connexion

Le côté caméra démarre la pile de protocole au démarrage (ou l’application la redémarre avec protocol.init() pour modifier les paramètres), puis attend tranquillement un hôte. Du point de vue de la caméra, il n’y a rien à faire jusqu’à ce qu’un paquet arrive.

Le côté hôte ouvre le transport – port USB ou UART – et envoie immédiatement un paquet PROTO_SYNC (code d’opération 0x00). Ce paquet possède une charge utile magique qui permet à la caméra de le reconnaître même si les deux côtés se sont désynchronisés, et c’est le seul paquet auquel la caméra répond avant que les capacités ne soient négociées.

Si la caméra ne répond pas dans le délai de retransmission, l’hôte renvoie PROTO_SYNC, jusqu’à rtx_retries fois. Après quoi il abandonne et signale un échec de connexion. C’est cette nouvelle tentative qui fait fonctionner le « débrancher, rebrancher, relancer le script hôte » sans que la caméra ait besoin de savoir que l’hôte a disparu.

12.4.2. Échange des capacités

Une fois que la caméra a accusé réception de la synchronisation, l’hôte envoie PROTO_GET_CAPS (code d’opération 0x01) pour demander ce que la caméra prend en charge. La charge utile de la réponse indique :

  • la validation CRC activée ou désactivée

  • le suivi des numéros de séquence activé ou désactivé

  • les ACK activés ou désactivés

  • les notifications d’événements activées ou désactivées

  • la taille maximale de charge utile de la caméra en octets

  • le nombre actuel de tentatives de retransmission, le délai d’expiration et les paramètres d’interrogation

L’hôte compare ces valeurs à sa propre configuration. Si l’hôte a besoin d’en modifier l’une d’elles – par exemple, pour négocier une charge utile maximale plus petite parce que son tampon de réception est plus petit que celui de la caméra – il envoie PROTO_SET_CAPS (code d’opération 0x02) avec les nouvelles valeurs. La caméra reconfigure sa pile et accuse réception. À partir de là, chaque paquet qui traverse le fil respecte ce contrat partagé.

Si l’hôte ne remplace rien, les valeurs par défaut sont toutes activées : validation CRC, suivi des numéros de séquence, ACK et notifications d’événements. La charge utile maximale par défaut correspond au tampon par carte de la caméra moins 14 octets de surcharge de trame (l’en-tête de 10 octets plus le CRC de charge utile de 4 octets en fin de paquet). Pour la plupart des travaux caméra-vers-ordinateur portable, les valeurs par défaut constituent le bon point de départ ; la page sur la fiabilité explique quand et pourquoi une application en désactive certains éléments.

12.4.3. Découverte des canaux

Après les capacités, l’hôte envoie CHANNEL_LIST (code d’opération 0x20). La caméra répond avec une liste des canaux enregistrés – les quatre canaux intégrés (stdin, stdout, stream, profile) plus ceux que l’application a enregistrés avec protocol.register(). Chaque entrée comporte l’ID du canal, son nom et ses indicateurs de capacité (lecture seule, écriture seule, verrouillable).

L’hôte met la liste de côté et l’utilise plus tard lorsque le code applicatif demande channel_read("frame") ou channel_write("config", ...) – le nom est résolu une seule fois en un ID de canal, puis chaque paquet ultérieur sur ce canal utilise directement l’ID.

Si la caméra enregistre un nouveau canal après la liste initiale – ce qui est fréquent lorsqu’une application commence à s’exécuter après l’établissement de liaison – la caméra émet un paquet d’événement CHANNEL_REGISTERED. L’hôte écoute ces événements et rafraîchit sa liste interne de canaux, de sorte qu’un script hôte qui s’est connecté tôt voit apparaître les canaux nouvellement enregistrés sans redémarrer.

L’établissement de liaison prend quelques allers-retours lors de l’établissement de la connexion, puis ne se répète jamais. Le trafic en régime permanent n’est que des paquets : des octets en trame entrants, des octets en trame sortants, les ID de canaux étant déjà connus des deux côtés.