12.4. Handshake a vyjednání schopností¶

Kamera i hostitel přicházejí k přenosu s vlastními představami o tom, jak má protokol běžet: které režimy CRC, zda jsou vyžadována potvrzení (ACK) a jaký je největší užitečný obsah (payload), který dokážou uložit do bufferu. Než začne skutečný provoz, vymění si handshake, který tyto parametry zafixuje pro zbytek relace.

12.4.1. Hostitel otevírá spojení¶

Strana kamery spouští zásobník protokolu při startu (nebo jej aplikace restartuje pomocí protocol.init() ke změně parametrů) a poté tiše čeká na hostitele. Z pohledu kamery není co dělat, dokud nedorazí paket.

Strana hostitele otevře přenos – USB port nebo UART – a okamžitě odešle paket PROTO_SYNC (opcode 0x00). Tento paket má magický užitečný obsah (payload), který umožňuje kameře jej rozpoznat, i když se obě strany rozsynchronizovaly, a je to jediný paket, na který kamera kdy odpovídá před vyjednáním schopností.

Pokud kamera neodpoví v rámci časového limitu pro opětovné odeslání, hostitel odešle PROTO_SYNC znovu, až rtx_retries krát. Poté to vzdá a ohlásí selhání spojení. Právě opakování je to, co umožňuje, aby „odpoj, znovu připoj, restartuj hostitelský skript“ fungovalo, aniž by kamera musela vědět, že hostitel odešel.

12.4.2. Výměna schopností¶

Jakmile kamera potvrdí synchronizaci, hostitel odešle PROTO_GET_CAPS (opcode 0x01), aby zjistil, co kamera podporuje. Užitečný obsah (payload) odpovědi hlásí:

validaci CRC povolenou nebo zakázanou
sledování pořadových čísel povolené nebo zakázané
potvrzení (ACK) povolená nebo zakázaná
oznámení událostí povolená nebo zakázaná
maximální velikost užitečného obsahu (payload) kamery v bajtech
aktuální počet pokusů o opětovné odeslání, časový limit a parametry dotazování (polling)

Hostitel je porovná s vlastní konfigurací. Pokud hostitel potřebuje kterýkoli z nich změnit – například vyjednat menší maximální užitečný obsah (payload), protože jeho přijímací buffer je menší než ten kamery – odešle PROTO_SET_CAPS (opcode 0x02) s novými hodnotami. Kamera překonfiguruje svůj zásobník a potvrdí. Od této chvíle každý paket, který projde přes vedení, dodržuje tuto sdílenou dohodu.

Pokud hostitel nic nepřepíše, jsou všechny výchozí hodnoty zapnuté: validace CRC, sledování pořadových čísel, potvrzení (ACK) a oznámení událostí. Výchozí maximální užitečný obsah (payload) je buffer kamery specifický pro danou desku mínus 14 bajtů režie rámcování (10bajtová hlavička plus 4bajtové koncové CRC užitečného obsahu). Pro většinu práce mezi kamerou a notebookem jsou výchozí hodnoty správným výchozím bodem; stránka o spolehlivosti popisuje, kdy a proč aplikace některé jejich části vypne.

12.4.3. Zjišťování kanálů¶

Po schopnostech odešle hostitel CHANNEL_LIST (opcode 0x20). Kamera odpoví seznamem zaregistrovaných kanálů – čtyř vestavěných (stdin, stdout, stream, profile) plus jakýchkoli, které aplikace zaregistrovala pomocí protocol.register(). Každá položka nese ID kanálu, jeho název a jeho příznaky schopností (jen pro čtení, jen pro zápis, uzamykatelný).

Hostitel si seznam uloží a použije jej později, když aplikační kód požádá o channel_read("frame") nebo channel_write("config", ...) – název se jednou vyhledá na ID kanálu a poté každý následující paket na tomto kanálu používá přímo ID.

Pokud kamera zaregistruje nový kanál po počátečním seznamu – což je běžné, když se aplikace začne spouštět až po handshaku – kamera vyšle paket události CHANNEL_REGISTERED. Hostitel jim naslouchá a obnoví svůj interní seznam kanálů, takže hostitelský skript, který se připojil brzy, vidí nově zaregistrované kanály bez restartu.

Handshake zabere při navazování spojení pár výměn tam a zpět a poté se už nikdy neopakuje. Provoz v ustáleném stavu jsou jen pakety: zarámované bajty dovnitř, zarámované bajty ven, ID kanálů už známá na obou stranách.