Protokoll — Client ↔ Server ​

Die vollständige Spezifikation jedes Bytes, das über den Client-Port (Standard 5225) ausgetauscht wird. Sie besteht aus dem Auth-Handshake, der einmal direkt nach dem Verbindungsaufbau durchgeführt wird, gefolgt vom binären Frame-Sperrprotokoll. Jeder offizielle Client implementiert diese Spezifikation identisch, byte für byte.

Der Abschnitt Struktur jeder Nachrichtenseite zeigt das Feldlayout, und Beispiel zeigt die tatsächlich gesendeten Bytes (die Werte ändern sich mit refresh).

Byte-Notation: op wird als ASCII-Zeichen dargestellt (z. B. A); wait und lease sind binäre u8-Werte, token und owner binäre u64-Big-Endian-Werte. Sie werden hexadezimal dargestellt (z. B. wait=5 → 05). key und addr sind UTF-8-Text, und reason ist ASCII-Text — all diese Felder haben variable Länge, in der Struktur als N dargestellt. Das abschließende \n (Zeilenumbruch) beendet den Frame als 0A. Felder werden ohne Trennzeichen direkt hintereinander gesendet.

Die festen Header (wait, lease, token, owner) sind Binärwerte und können 0x0A enthalten — ein Parser muss daher zuerst die feste Header-Länge des jeweiligen op verbrauchen, bevor er nach dem Zeilenumbruch sucht. Die Längen sind: Anfrage A=10 B / R=8 B, Antwort A=16 B / T·B·R·N=8 B / M·L·E=0 B.

Inhaltsverzeichnis ​

• Transportschicht
• Auth-Handshake — gemeinsam mit dem Raft-Port des Clusters, daher auf der Seite Protokoll (Gemeinsam)
• Anfragen
  • A · Acquire
  • R · Release
• Antworten
  • A · Vergeben
  • T · Zeitüberschreitung
  • B · Belegt
  • R · Freigegeben
  • N · Nicht gefunden
  • E · Fehler
  • M · Verwiesen
  • L · Leader-Hinweis
• Feldbeschränkungen
• Anfrage-×-Schlüsselzustand-Matrix
• Fencing-Token
• Regeln zur Antwortzuordnung
• Beispielsitzung

Das Server-zu-Server-Cluster-Konsensprotokoll (Raft) wird auf einer separaten Seite behandelt.