Обзор Дейтаграмм
Дейтаграммы строятся на основе I2CP и предоставляют аутентифицированные сообщения в стандартном формате, на которые можно ответить. Это позволяет приложениям читать достоверный адрес "От" в дейтаграмме, и узнать, с какого адреса на самом деле отправлено сообщение. Это важно для некоторых приложений, поскольку базовое сообщение I2P не форматировано - в нем нет адреса "от" (как это есть в IP). Кроме того, сообщение и отправитель аутентифицируются по подписи на данных.
Дейтаграммы, как и пакеты потоковой библиотеки, являются конструкциями уровня приложения. Эти протоколы не зависят от низкоуровневого транспорта; протоколы конвертируются маршрутизатором в сообщения I2NP, каждый протокол может передаваться любым транспортом.
Руководство по Приложениям
Приложения, написанные на Java, могут использовать API дейтаграмм, приложения на других языках могут использовать поддержку дейтаграмм SAM'а. Также есть ограниченная поддержка в i2ptunnel в SOCKS proxy, 'streamr' типы туннеля и классы udpTunnel.
Длина Дейтаграммы
Проектировщик приложения должен хорошо понимать разницу между дейтаграммами с ответом и без оных. Также, размер дейтаграммы влияет на надежность, в виду фрагментации туннелем сообщений по 1 КБ. Чем больше сообщение фрагментируется, тем более вероятно, что одно из них будет потеряно на промежуточном прыжке. Сообщения размером более нескольких КБ не рекомендованы для использования. При размере более 10 КБ доставка, возможно, сильно ухудшится. Сообщения более 16 КБ не могут быть доставлены по NTCP, шансы сбоя доставки сильно увеличиваются.
Также учитывайте, что различные накладные расходы добавляются на более низких уровнях, в ассиметричном алгоритме ElGamal/AES, они создают большую нагрузку на прерывистые сообщения, как в приложении Kademlia-over-UDP. Сейчас реализация отлажена для часто встречающегося трафика с использованием потоковой библиотеки. Например, доставлено большое количество меток сессии и время жизни меток сессии мало. Сейчас нет конфигурации, доступной в I2CP, для настройки параметров меток сессии ElGamal.
Номер Протокола I2CP и Порты
Стандартный номер протокола I2CP для дейтаграмм - PROTO_DATAGRAM (17). Приложения могут указывать или не указывать протокол в заголовке I2CP. По умолчанию он не указан. Его нужно указать для демультиплексирования дейтаграммы и потокового трафика, полученных на одном пункте назначения.
Поскольку дейтаграммы не ориентированы на соединение, приложению может понадобиться номер порта для сопоставления дейтаграмм от определенных узлов или сессий подключения, как и в традиционном UDP над IP. Приложения могут добавить порты 'от' и 'к' в заголовок I2CP (gzip), как это описано на странице I2CP.
В API дейтаграмм нет возможности указать является ли она безответной (raw) или с возможностью ответа. Приложение должно быть само определять правильный тип. Номер протокола I2CP или порт могут быть использованы приложением для определения типа дейтаграммы. Для этой цели в I2PSession API определены номера протокола I2CP - PROTO_DATAGRAM (подписанная) и PROTO_DATAGRAM_RAW. Общим принципом в приложениях клиент/сервер с дейтаграммами является использование подписанных дейтаграмм для запросов, которые содержат некие данные, и raw дейтаграммы для ответа, с обратной отправкой тех данных из запроса.
Defaults:
- PROTO_DATAGRAM = 17
- PROTO_DATAGRAM_RAW = 18
Протоколы и порты могут быть настроены в I2PSession API I2CP, как это реализовано в I2PSessionMuxedImpl.
Целостность данных
Целостность данных, гарантируемая проверкой gzip суммы CRC-32, реализована на уровне I2CP. В протоколе дейтаграмм нет поля с проверочной суммой.
Инкапсуляция пакета
Каждая дейтаграмма отправляется через I2P как отдельное сообщение (или отдельный зубчик в Чесночном Сообщении). Инкапсуляция сообщения реализована в нижележащих уровнях I2CP, I2NP и туннельном сообщении. В протоколе дейтаграмм нет механизма разделения пакетов или поля длины.