Aller au contenu principal

7. Procedure for UDP-based clients (Procédure pour les clients UDP)

Un client basé sur UDP (UDP-based Client) doit envoyer ses datagrammes au serveur de relais UDP (UDP Relay Server) au port UDP indiqué par BND.PORT dans la réponse à la requête UDP ASSOCIATE. Si la méthode d'authentification sélectionnée fournit une encapsulation à des fins d'authenticité (Authenticity), d'intégrité et/ou de confidentialité, le datagramme doit être encapsulé en utilisant l'encapsulation appropriée. Chaque datagramme UDP porte un en-tête de requête UDP (UDP Request Header) avec lui :

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

Les champs dans l'en-tête de requête UDP :

  • RSV Réservé (Reserved) X'0000'
  • FRAG Numéro de fragment actuel (Current Fragment Number)
  • ATYP type d'adresse des adresses suivantes :
    • IP V4 address : X'01'
    • DOMAINNAME : X'03'
    • IP V6 address : X'04'
  • DST.ADDR adresse de destination souhaitée
  • DST.PORT port de destination souhaité
  • DATA données utilisateur (User Data)

Lorsqu'un serveur de relais UDP décide de relayer un datagramme UDP, il le fait silencieusement, sans aucune notification au client demandeur. De même, il supprimera les datagrammes qu'il ne peut pas ou ne veut pas relayer. Lorsqu'un serveur de relais UDP reçoit un datagramme de réponse d'un hôte distant (Remote Host), il doit encapsuler ce datagramme en utilisant l'en-tête de requête UDP ci-dessus et toute encapsulation dépendante de la méthode d'authentification.

Le serveur de relais UDP doit acquérir du serveur SOCKS l'adresse IP attendue du client qui enverra des datagrammes au BND.PORT donné dans la réponse à UDP ASSOCIATE. Il doit supprimer tous les datagrammes arrivant de toute adresse IP source autre que celle enregistrée pour l'association particulière.

Le champ FRAG indique si ce datagramme fait partie d'un certain nombre de fragments (Fragment). S'il est implémenté, le bit de poids fort (High-Order Bit) indique la fin de la séquence de fragments (End-of-Fragment Sequence), tandis qu'une valeur de X'00' indique que ce datagramme est autonome (Standalone). Les valeurs entre 1 et 127 indiquent la position du fragment dans une séquence de fragments. Chaque récepteur aura une file d'attente de réassemblage (REASSEMBLY QUEUE) et une minuterie de réassemblage (REASSEMBLY TIMER) associées à ces fragments. La file d'attente de réassemblage doit être réinitialisée et les fragments associés abandonnés chaque fois que la minuterie de réassemblage expire, ou qu'un nouveau datagramme arrive portant un champ FRAG dont la valeur est inférieure à la valeur FRAG la plus élevée traitée pour cette séquence de fragments. La minuterie de réassemblage doit être d'au moins 5 secondes. Il est recommandé que la fragmentation (Fragmentation) soit évitée par les applications dans la mesure du possible.

L'implémentation de la fragmentation est optionnelle (Optional) ; une implémentation qui ne prend pas en charge la fragmentation doit supprimer tout datagramme dont le champ FRAG est autre que X'00'.

L'interface de programmation (Programming Interface) pour un UDP compatible SOCKS (SOCKS-aware UDP) doit signaler un espace de tampon disponible (Buffer Space) pour les datagrammes UDP qui est plus petit que l'espace réel fourni par le système d'exploitation :

  • si ATYP est X'01' - 10+method_dependent octets plus petit
  • si ATYP est X'03' - 262+method_dependent octets plus petit
  • si ATYP est X'04' - 20+method_dependent octets plus petit