La dernière mise à jour de cette page été effectuée en 2025-04 et est exacte pour la version 0.9.66 du routeur.

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

The application designer should carefully consider the tradeoff of repliable vs. non-repliable datagrams. Also, the datagram size will affect reliability, due to tunnel fragmentation into 1KB tunnel messages. The more message fragments, the more likely that one of them will be dropped by an intermediate hop. Messages larger than a few KB are not recommended. Over about 10 KB, the delivery probablility drops dramatically.

Voir la page de spécification des datagrammes.

Also note that the various overheads added by lower layers, in particular garlic messages, place a large burden on intermittent messages such as used by a Kademlia-over-UDP application. The implementations are currently tuned for frequent traffic using the streaming library.

Numéros de protocole et ports d’I2CP

The standard I2CP protocol number for signed (repliable) datagrams is PROTO_DATAGRAM (17). Applications may or may not choose to set the protocol in the I2CP header. The default is implementation-dependent. It must be set to demultiplex datagram and streaming traffic received on the same 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.

There is no method within the datagram API to specify whether it is non-repliable (raw) or repliable. The application should be designed to expect the appropriate type. The I2CP protocol number or port should be used by the application to indicate datagram type. The I2CP protocol numbers PROTO_DATAGRAM (signed, also known as Datagram1), PROTO_DATAGRAM_RAW, PROTO_DATAGRAM2, and PROTO_DATAGRAM3 are defined in the I2PSession API for this purpose. A common design pattern in client/server datagram applications is to use signed datagrams for a request which includes a nonce, and use a raw datagram for the reply, returning the nonce from the request.

Defaults:

  • PROTO_DATAGRAM = 17
  • PROTO_DATAGRAM_RAW = 18
  • PROTO_DATAGRAM2 = 19
  • PROTO_DATAGRAM3 = 20

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

Data integrity is assured by the gzip CRC-32 checksum implemented in the I2CP layer. Authenticated datagrams (Datagram1 and Datagram2) also ensure integrity. There is no checksum field in the datagram protocol.

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.

Spécification

Voir la page de spécification des datagrammes.