Vue d’ensemble des datagrammes
Les datagrammes sont construits sur la base I2CP pour des messages authentifiés et réflexibles dans un format standard. Ceci laisse les applications lire de façon fiable les adresses "from" à partir d’un datagramme et savoir que l’adresse a vraiment envoyé le message. Ceci est nécessaire pour quelques applications sachant que le message base I2P est complètement brut - il n’a pas d’adresse "from" (contrairement aux paquets IP). De plus, le message et l’expéditeur sont authentifiés en signant la charge utile.
Les datagrammes, tels que streaming library packets, sont consruits au niveau application. Ces protocoles sont indépendants des transports de bas niveau; les protocoles sont convertis en messages I2NP par le routeur, et l’un ou l’autre protocole peut être transporté par l’un ou l’autre transport.
Guide application
Les applications écrites en Java peuvent utiliser l’API de datagrammes, tandis que les applications en d’autres langages peuvent utiliser la prise en charge des datagrammes de SAM. Il existe aussi une prise en charge limitée dans i2ptunnel, dans le mandataire SOCKS, les types de tunnel 'streamr' et les classes udpTunnel.
Longueur des datagrammes
Le concepteur d’application devrait considérer soigneusement la différence entre des datagrammes réflexibles et non-réflexibles. Aussi, la taille de datagramme affectera la fiabilité, en raison de la fragmentation des messages de tunnel en taille de 1 Ko. Plus il y a de fragments de message, plus il est probable que l’un d’entre eux sera laissé tombé par une étape intermédiaire. On recommande des messages pas plus grand que quelques KO. Au delà de 10 KO, la probabilité de livraison diminue radicalement. Les messages de plus de 16 KO ne peuvent pas être livrés via NTCP, laissant tomber encore davantage les chances de livraison.
Notez aussi que les surcharges diverses ajoutées par les couches inférieures, en particulier ElGamal/AES asymétrique, imposent un lourd fardeau sur les messages intermittents tels que ceux utilisés par une application Kademlia-sur-UDP. Les mises en œuvre sont actuellement ajustées pour un trafic fréquent utilisant la bibliothèque de diffusion «streaming ». Par exemple, de nombreuses étiquettes de session sont livrées et la durée de vie d’une étiquette de session est courte. Il n’y a actuellement aucun paramètre de configuration dans I2CP qui permettrait d’ajuster les paramètres « Étiquette de session ElGamal ».
Numéros de protocole et ports d’I2CP
Le numéro standard du protocole I2CP pour les datagrammes est PROTO_DATAGRAM (17). Les applications peuvent ou pas choisir de définir le protocole dans l’en-tête d’I2CP. Il n’est pas défini par défaut. Il doit être défini pour démultiplexer le trafic de datagrammes et de diffusion en continu reçu sur la même destination.
Comme les datagrammes ne sont pas orientés connexion, les applications pourraient exiger les numéros de port pour corréler les datagrammes avec des pairs particuliers ou des sessions de communications, comme cela est habituel avec l’UDP sur IP. Les applications peuvent ajouter les ports « de » et « vers » à l’en-tête d’I2CP (gzip) comme décrit sur la page I2CP.
Il n’y a aucune méthode dans l’API de datagramme pour spécifier si c’est un réflexible ou un non-réflexible (brut). L’application devrait être conçue pour s’attendre au type approprié. Le numéro de protocole I2CP et le port devraient être utilisés par l’application pour indiquer le type de datagramme. Les numéros de protocole PROTO_DATAGRAM (signé) et PROTO_DATAGRAM_RAW sont définis dans l’l’API I2PSession à cette fin. Un modèle de design commun dans les applications de datagramme client/serveur est d’utiliser des datagrammes signés pour une requête qui inclue une occasion, et utiliser un datagramme brut pour la réponse, retournant l’occasion depuis la requête.
Defaults:
- PROTO_DATAGRAM = 17
- PROTO_DATAGRAM_RAW = 18
Les protocoles et les ports peuvent être définis dans l’API I2PSession d’I2CP, comme implémenté dans I2PSessionMuxedImpl.
Intégrité des données
L’intégrité des données est assurée par la somme de contrôle gzip CRC-32 mise en œuvre dans la couche I2CP. Il n’y a aucun champ de somme de contrôle dans le protocole de datagramme.
Encapsulation de paquets
Chaque datagramme est envoyé à travers I2P comme un simple message (ou comme un clou de girofle individuel dans un Message Ail). L’encapsulation de message est mise en œuvre dans les couches sous-jacentes I2CP, I2NP, et message tunnel. Il n’y a aucun mécanisme délimiteur de paquet ni de longueur de champ dans le protocole de datagramme.