Zum Hauptinhalt springen

7. Procedure for UDP-based clients (Verfahren für UDP-basierte Clients)

Ein UDP-basierter Client (UDP-based Client) muss seine Datagramme an den UDP-Relay-Server (UDP Relay Server) am UDP-Port senden, der durch BND.PORT in der Antwort auf die UDP ASSOCIATE-Anfrage angegeben ist. Wenn die ausgewählte Authentifizierungsmethode eine Kapselung für Zwecke der Authentizität (Authenticity), Integrität und/oder Vertraulichkeit bereitstellt, muss das Datagramm unter Verwendung der entsprechenden Kapselung gekapselt werden. Jedes UDP-Datagramm trägt einen UDP-Anforderungsheader (UDP Request Header) mit sich:

   +----+------+------+----------+----------+----------+
|RSV | FRAG | ATYP | DST.ADDR | DST.PORT | DATA |
+----+------+------+----------+----------+----------+
| 2 | 1 | 1 | Variable | 2 | Variable |
+----+------+------+----------+----------+----------+

Die Felder im UDP-Anforderungsheader:

  • RSV Reserviert (Reserved) X'0000'
  • FRAG Aktuelle Fragmentnummer (Current Fragment Number)
  • ATYP Adresstyp der folgenden Adressen:
    • IP V4 address: X'01'
    • DOMAINNAME: X'03'
    • IP V6 address: X'04'
  • DST.ADDR gewünschte Zieladresse
  • DST.PORT gewünschter Zielport
  • DATA Benutzerdaten (User Data)

Wenn ein UDP-Relay-Server beschließt, ein UDP-Datagramm weiterzuleiten, tut er dies stillschweigend, ohne den anfragenden Client zu benachrichtigen. Ebenso wird er Datagramme verwerfen, die er nicht weiterleiten kann oder will. Wenn ein UDP-Relay-Server ein Antwort-Datagramm von einem entfernten Host (Remote Host) empfängt, muss er dieses Datagramm unter Verwendung des obigen UDP-Anforderungsheaders und jeder authentifizierungsmethodenabhängigen Kapselung kapseln.

Der UDP-Relay-Server muss vom SOCKS-Server die erwartete IP-Adresse des Clients erwerben, der Datagramme an den BND.PORT sendet, der in der Antwort auf UDP ASSOCIATE angegeben ist. Er muss alle Datagramme verwerfen, die von einer anderen Quell-IP-Adresse als der für die bestimmte Assoziation aufgezeichneten ankommen.

Das FRAG-Feld gibt an, ob dieses Datagramm eines von mehreren Fragmenten (Fragment) ist. Falls implementiert, zeigt das höchstwertige Bit (High-Order Bit) das Ende der Fragmentsequenz (End-of-Fragment Sequence) an, während ein Wert von X'00' anzeigt, dass dieses Datagramm eigenständig (Standalone) ist. Werte zwischen 1 und 127 geben die Fragmentposition innerhalb einer Fragmentsequenz an. Jeder Empfänger hat eine Reassemblierungs-Warteschlange (REASSEMBLY QUEUE) und einen Reassemblierungs-Timer (REASSEMBLY TIMER), die mit diesen Fragmenten verbunden sind. Die Reassemblierungs-Warteschlange muss neu initialisiert und die zugehörigen Fragmente müssen verworfen werden, wann immer der Reassemblierungs-Timer abläuft oder ein neues Datagramm mit einem FRAG-Feld ankommt, dessen Wert kleiner ist als der höchste für diese Fragmentsequenz verarbeitete FRAG-Wert. Der Reassemblierungs-Timer muss mindestens 5 Sekunden betragen. Es wird empfohlen, dass Fragmentierung (Fragmentation) von Anwendungen nach Möglichkeit vermieden wird.

Die Implementierung der Fragmentierung ist optional (Optional); eine Implementierung, die keine Fragmentierung unterstützt, muss jedes Datagramm verwerfen, dessen FRAG-Feld anders als X'00' ist.

Die Programmierschnittstelle (Programming Interface) für ein SOCKS-fähiges UDP (SOCKS-aware UDP) muss einen verfügbaren Pufferspeicher (Buffer Space) für UDP-Datagramme melden, der kleiner ist als der tatsächliche vom Betriebssystem bereitgestellte Speicher:

  • wenn ATYP X'01' ist - 10+method_dependent Oktette kleiner
  • wenn ATYP X'03' ist - 262+method_dependent Oktette kleiner
  • wenn ATYP X'04' ist - 20+method_dependent Oktette kleiner