Cette page a été mise à jour en Août 2010 et est valide pour la version de routeur 0.8.

Vue d'ensemble datagramme

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 datagramme, tandis que les applications dans d'autres langages peuvent utiliser le support datagramme de SAM. Il y a aussi un support limité dans i2ptunnel dans le proxy SOCKS, les types de tunnel 'streamr', et classes udpTunnel.

Longueur de datagramme

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 diverses en-têtes ajoutées par des couches inférieures, en particulier ElGamal/AES asymétrique, placent un grand fardeau sur les messages intermittents tels que ceux utilisés par une application Kademlia-par-dessus-UDP. Les mises en œuvre sont actuellement ajustées pour du trafic fréquent utilisant la bibliothèque streaming. Il y a un large nombre d'étiquettes de session livrées, et l'étiquette de session a une courte durée de vie, par exemple. Il n'y a actuellement aucun paramètre de configuration disponible dans I2CP qui permettrait d'ajuster les paramètres d'é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 peuvent ne pas vouloir mettre le protocole dans l'en-tête I2CP. Il n'est pas mis par défaut. Il doit être mis pour dé-multiplexer le datagramme et le trafic streaming reçu sur la même Destination.

Comme les datagrammes ne sont pas orientés-connexion, les applications peuvent nécessiter des numéros de port pour corréler des datagrammes avec des pairs particuliers ou des sessions de communications, comme c'est traditionnel avec UDP sur IP. Les applications peuvent ajouter les ports 'from' et 'to' à l'en-tête d'I2CP (gzip) comme décrit dans 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.

Les protocoles et les ports peuvent être mis 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 paquet

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.

Spécification

Voir la page de spécification des datagrammes.