Introducción a los datagramas
Los datagramas se construyen sobre la base de I2CP para proporcionar autentificación y mensajes respondibles en un formato estandar. Esto permite a las aplicaciones leer con fiabilidad la dirección "from" (desde) de los datragramas, y confirmar que la dirección envió efectivamente el mensaje. Esto es necesario para algunas aplicaciones ya que el mensaje base I2P es completamente crudo (`raw`) - no tiene dirección "from" (al contrario que los paquetes IP). Además el mensaje y el emisor son autentificados mediante el firmado de la carga.
Los datagramas, al igual que los paquetes de la librería de streaming, son una construcción al nivel de aplicación. Estos protocolos son diferentes de los transportes de bajo nivel; estos protocolos son convertidos en mensajes I2NP por el ruter, y así cualquier protocolo puede ser llevado por cualquier transporte.
Guía de aplicaciones
Las aplicaciones escritas en Java pueden usar la API datagram, mientras que las aplicaciones en otros idomas pueden usar el soporte datagram de SAM. También hay soporte limitado en i2ptunnel en el proxy SOCKS, los tipos de túnel 'streamr', y las clases udpTunnel.
Longitud del datagrama
El diseñador de la aplicación debe considerar cuidadosamente las contrapartidas de datagramas respondibles frente a los no-respondibles. El tamaño del datagrama también afectaría a la fiabilidad, debido a la fragmentación del túnel en mensajes de túnel de 1KB. Cuantos más fragmentos de mensaje, más probable es que uno de ellos se pierda en un salto intermedio. Los mensajes más largos de unos pocos KB no están recomendados. Por encima de alrededor de 10KB, la probabilidad de entrega cae dramáticamente. Los mensajes por encima de 16KB no pueden ser entregados sobre NTCP (TCP basado en NIO).
Observe también que el variado tráfico de control añadido por las capas inferiores, en particular la asimétrica ElGamal/AES, coloca una gran carga sobre los mensajes intermitentes tales como los usados por una aplicación Kademlia-sobre-UDP. Las implementaciones actualmente se ajustan para tráfico frecuente usando la librería streaming. Por ejemplo, si hay un alto número de etiquetas de sesión entregadas, y una vida corta de etiqueta de sesión. Actualmente no hay parámetros de configuración disponibles dentro de I2CP para ajustar los parametros de la Etiqueta de Sesión ElGamal.
Número de protocolo y puertos de I2CP
El número stadard del protocolo I2CP (Protocolo de Cliente I2P) para datagramas es PROTO_DATAGRAM (17). Las aplicaciones pueden o no elegir establecer el protocolo en la cabecera I2CP. No está establecido por defecto. Debe ser establecido para demultiplexar el datagrama y el tráfico de streaming recibido en el mismo Destino.
Como los datagramas no están orientados a la conexión, la aplicación puede requerir números de puerto para correlacionar los datagramas con pares ('peers') concrectos o sesiones de comunicaciones, como es tradicional con UDP sobre IP. Las aplicaciones pueden añadir puertos 'from' (origen) y 'to' (destino) a la cabecera (gzip) I2CP como se describe en la página de I2CP.
No hay método dentro de la API datagram para especificar si es no-respondible (raw (crudo)) o respondible. La aplicación debe ser designada para esperar el tipo apropiado. El número de protocolo I2CP o el puerto debería ser usado por la aplicación para indicar el tipo de datagrama. Los números de protocolo I2CP `PROTO_DATAGRAM_RAW` se definen en la API I2PSession para este propósito. Un patrón de diseño común en aplicaciones datagrama cliente/servidor es usar datagramas firmados para una petición que incluye un nonce (valor de seguridad de un único uso), y usa un datagrama crudo (`raw`) para la respuesta, devolviendo el nonce desde la petición.
Defaults:
- PROTO_DATAGRAM = 17
- PROTO_DATAGRAM_RAW = 18
Los protocolos y puertos pueden ser establecidos en la API I2PSession de I2CP, tal como están implementados en I2PSessionMuxedImpl.
Integridad de los datos
La integridad de los datos está asegurada por el checksum CRC-32 de gzip implementado en la capa I2CP. No hay campo checksum en el protocolo datagram
Encapsulado de paquetes
Cada datagrama se envía a través de I2P como un mensaje único (o como un 'clove' (diente) individual en un `Garlic Message)` (mensaje ajo). La encapsulación del mensaje se implementa en los I2CP, I2NP, y las capas de mensaje de túnel subyacentes. No hay mecanismo delimitador de paquetes o campo de tamaño en el protocolo datagram.