hcan udp protocol

Das UDP/IP Protocol

Das UDP/IP Protocol ist die im PC oder im LAN verwendete HCAN Transportschicht. Zentraler Server-Prozess ist der hcand, mit welchem die Clients (z.B. telican) kommunizieren.

hcand lauscht auf UDP Port 3600, die Clients verwenden einen hohen, vom OS dynamisch zugewiesenen UDP Port.

Aufbau

Der Aufbau eines HCAN Paketes sieht folgendermassen aus (siehe hcand/frame.h):

typedef struct
{
uint32_t id;
uint32_t size;
uint8_t  data[8];
} CANFrame;

Die Paketgroesse betraegt immer 16 Bytes. Grund ist das einfache Handling, man kann mit festen Blockgroessen arbeiten.

Das Feld id enthaelt den 29bit CAN extended identifier, wie im HCAN Protcol beschrieben, rechts ausgerichtet.

Das Feld size enthaelt die Anzahl der Daten-Bytes des Frames. Die Breite von size betraegt 32bit, damit die Gesamt-Struktur eine Groesse von 16 Bytes erhaelt. Ursache ist hier "Bitmasken-Denken", d.h. man moechte Groessen nur in 2er-Potenzen auslegen.

Das Array data enthaelt die Nutzbytes der Nachricht. Wichtig ist zu beachten, dass nur size Bytes gueltig sind. Beispiel: size=3, data[0] = 5, data[1] = 10, data[2] = 45, dann sind die Werte von data[4]..data[7] undefiniert und duerfen nicht ausgewertet werden.

Dialog

Ein Client sendet seinen ersten Frame zum hcand. Damit ist die Verbindung eroeffnet. hcand speichert sich den Quell-UDP Port des Clients, und sendet alle Frames, die er zustellen muss, auch an diesen Port.

Empfaengt hcand eine Weile keine Frames vom Client mehr, so verwirft er den Quell-UDP-Port Eintrag. Nun bekommt der Client erst wieder Frames, wenn er ein neues Frame zum hcand sendet.

Wenn der Client, wie z.B. telican im Dump-Modus (//-d//), rein passiv ist, d.h. selbst keine Frames senden moechte, so sendert er Keepalive-Frames.

Ein Keepalive-Frame ist ein normales HCAN UDP Paket, allerdings sind alle Felder auf 0 gesetzt. hcand leitet dieses Frame nicht weiter, setzt aber seinen Timeout Zaehler zurueck. Damit bleibt die Verbindung offen.

Vorteil von UDP gegenueber TCP

Ein berechtigter Einwand: Warum kein TCP verwenden? Dann muss man sich nicht um das Session/Timeout Handling kuemmern. Das waere tatsaechlich bequemer, hat aber einen gewichtigen Nachteil: Wenn der hcand beendet wird, verlieren alle Clients die Verbindung. Hier muesste dann ein Reconnect stattfinden, was im Detail sehr komplex ausfallen kann (Exception wurde geworfen und ein Teil des Zustands schon wieder abgebaut etc.). Ein weiteres Problem: Es kann nicht sichergestellt werden, dass hcand als Erster gestartet wird - eventuell startet der hcanhid frueher. Im UDP-Falle macht das nichts, bei TCP wuerde er keine Verbindung bekommen.

Im Gegensatz dazu verwendet der hcanaddressd aber TCP; hier kommt der Vorteil zum Tragen, dass ein abgestuerzter Client somit automatisch seine Adresse durch den TCP-Timeout freigibt. Dadurch, dass Clients, die sich dynamisch beim hcanaddressd eine Adresse besorgen, vom Charakter her eher kurzlebige Sessions haben, faellt die Start-/Restart Thematik nicht so stark ins Gewicht. Wuerde hier UDP verwendet werden, koennte folgendes Problem auftreten: Der hcanaddressd wird neu gestartet, aber die Clients bekommen nicht mit, dass ihre Adresse nicht mehr gueltig ist. Er koennte nun die gleiche Adresse wieder vergeben, und dann gibt es eine Adress-Kollision, was zu undefiniertem Verhalten im HCAN-System fuehrt - Frames werden mehrfach beantwortet etc.