Обзор датаграмм
Датаграммы основываются на базовом I2CP для предоставления аутентифицированных сообщений с возможностью ответа в стандартном формате. Это позволяет приложениям надежно считывать адрес “от кого” из датаграммы и знать, что этот адрес действительно отправил сообщение. Это необходимо для некоторых приложений, поскольку базовое I2P сообщение является полностью “сырым” - оно не содержит адреса “от кого” (в отличие от IP пакетов). Кроме того, сообщение и отправитель аутентифицируются путем подписи полезной нагрузки.
Датаграммы, как и пакеты потоковой библиотеки , являются конструкцией уровня приложения. Эти протоколы независимы от низкоуровневых транспортов ; протоколы преобразуются в I2NP сообщения router’ом, и любой протокол может передаваться любым транспортом.
Руководство по приложениям
Приложения, написанные на Java, могут использовать datagram API, в то время как приложения на других языках могут использовать поддержку датаграмм в SAMv3 . Также имеется ограниченная поддержка в i2ptunnel в SOCKS proxy , типах tunnel ‘streamr’ и классах udpTunnel.
Длина датаграммы
Разработчик приложения должен тщательно рассмотреть компромисс между репликабельными и нерепликабельными датаграммами. Также размер датаграммы будет влиять на надёжность из-за фрагментации tunnel на сообщения размером 1КБ. Чем больше фрагментов сообщения, тем выше вероятность того, что один из них будет отброшен промежуточным узлом. Сообщения размером больше нескольких КБ не рекомендуются. При размере свыше 10 КБ вероятность доставки резко снижается.
См. страницу спецификации датаграмм.
Также обратите внимание, что различные накладные расходы, добавляемые нижними уровнями, в частности garlic messages, создают значительную нагрузку на периодические сообщения, такие как используемые приложением Kademlia-over-UDP. Реализации в настоящее время настроены для частого трафика с использованием библиотеки потоковой передачи.
Номер протокола I2CP и порты
Стандартный номер протокола I2CP для подписанных (с возможностью ответа) датаграмм — PROTO_DATAGRAM (17). Приложения могут выбирать, устанавливать ли протокол в заголовке I2CP или нет. Значение по умолчанию зависит от реализации. Он должен быть установлен для демультиплексирования трафика датаграмм и потокового трафика, получаемого на одном и том же Destination.
Поскольку дейтаграммы не являются соединение-ориентированными, приложению может потребоваться использовать номера портов для соотнесения дейтаграмм с конкретными узлами или сессиями связи, как это традиционно делается с UDP поверх IP. Приложения могут добавлять порты ‘from’ и ’to’ в заголовок I2CP (gzip), как описано на странице I2CP .
В datagram API нет метода для указания, является ли датаграмма неотвечаемой (raw) или отвечаемой. Приложение должно быть спроектировано так, чтобы ожидать соответствующий тип. Номер протокола I2CP или порт должен использоваться приложением для указания типа датаграммы. Номера протоколов I2CP PROTO_DATAGRAM (подписанная, также известная как Datagram1), PROTO_DATAGRAM_RAW, PROTO_DATAGRAM2 и PROTO_DATAGRAM3 определены в I2PSession API для этой цели. Общий шаблон проектирования в клиент/серверных datagram-приложениях заключается в использовании подписанных датаграмм для запроса, который включает nonce, и использовании raw-датаграммы для ответа, возвращая nonce из запроса.
По умолчанию:
- PROTO_DATAGRAM = 17
- PROTO_DATAGRAM_RAW = 18
- PROTO_DATAGRAM2 = 19
- PROTO_DATAGRAM3 = 20
Целостность данных
Целостность данных обеспечивается контрольной суммой gzip CRC-32, реализованной в слое I2CP . Аутентифицированные датаграммы (Datagram1 и Datagram2) также обеспечивают целостность. В протоколе датаграмм нет поля контрольной суммы.
Инкапсуляция пакетов
Каждая датаграмма отправляется через I2P как одиночное сообщение (или как отдельный clove в Garlic Message ). Инкапсуляция сообщений реализована в нижележащих слоях I2CP , I2NP и tunnel message . В протоколе датаграмм отсутствует механизм разделителей пакетов или поле длины.