Протокол клиента I2P (I2CP)

Обзор

Это спецификация протокола управления I2P (I2CP) — низкоуровневого интерфейса между клиентами и router. Java-клиенты будут использовать клиентский API I2CP, который реализует этот протокол.

Не существует известных реализаций клиентской библиотеки I2CP на языках, отличных от Java. Кроме того, приложениям, ориентированным на сокеты (потоковым), потребуется реализация протокола потоковой передачи, но библиотек для этого на других языках также не существует. Поэтому клиентам на языках, отличных от Java, следует вместо этого использовать протокол более высокого уровня SAM SAMv3 , для которого существуют библиотеки на нескольких языках.

Это низкоуровневый протокол, поддерживаемый как внутренне, так и внешне Java I2P router. Протокол сериализуется только в том случае, если клиент и router не находятся в одной JVM; в противном случае Java-объекты I2CP сообщений передаются через внутренний интерфейс JVM. I2CP также поддерживается внешне C++ router i2pd.

Более подробная информация находится на странице обзора I2CP I2CP .

Сессии

Протокол был разработан для обработки нескольких “сессий”, каждая с 2-байтовым идентификатором сессии, через одно TCP-соединение, однако множественные сессии не были реализованы до версии 0.9.21. См. раздел о мультисессиях ниже . Не пытайтесь использовать множественные сессии на одном I2CP-соединении с router версии старше 0.9.21.

Также похоже, что есть некоторые возможности для одного клиента взаимодействовать с несколькими router через отдельные соединения. Это также не тестировалось и, вероятно, не является полезным.

Не существует способа поддерживать сессию после отключения или восстановить её на другом I2CP соединении. Когда сокет закрывается, сессия уничтожается.

Примеры последовательностей сообщений

Примечание: Примеры ниже не показывают байт протокола (0x2a), который должен быть отправлен от клиента к router при первом подключении. Больше информации об инициализации соединения находится на странице обзора I2CP I2CP .

Стандартная установка сессии

  Client                                           Router

                           --------------------->  Get Date Message
        Set Date Message  <---------------------
                           --------------------->  Create Session Message
  Session Status Message  <---------------------
Request LeaseSet Message  <---------------------
                           --------------------->  Create LeaseSet Message

Получить ограничения пропускной способности (простая сессия)

  Client                                           Router

                           --------------------->  Get Bandwidth Limits Message
Bandwidth Limits Message  <---------------------

Поиск назначения (простая сессия)

  Client                                           Router

                           --------------------->  Dest Lookup Message
      Dest Reply Message  <---------------------

Исходящее сообщение

Существующая сессия, с i2cp.messageReliability=none

  Client                                           Router

                           --------------------->  Send Message Message

Существующая сессия, с i2cp.messageReliability=none и ненулевым nonce

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (succeeded)

Существующая сессия с i2cp.messageReliability=BestEffort

  Client                                           Router

                           --------------------->  Send Message Message
  Message Status Message  <---------------------
  (accepted)
  Message Status Message  <---------------------
  (succeeded)

Входящее сообщение

Существующая сессия с i2cp.fastReceive=true (начиная с версии 0.9.4)

  Client                                           Router

 Message Payload Message  <---------------------

Существующая сессия, с i2cp.fastReceive=false (УСТАРЕЛО)

  Client                                           Router

  Message Status Message  <---------------------
  (available)
                           --------------------->  Receive Message Begin Message
 Message Payload Message  <---------------------
                           --------------------->  Receive Message End Message

Заметки о многосессионности

Множественные сессии на одном I2CP соединении поддерживаются начиная с версии router 0.9.21. Первая созданная сессия является “основной сессией”. Дополнительные сессии являются “подсессиями”. Подсессии используются для поддержки нескольких назначений, разделяющих общий набор tunnel. Основное применение заключается в том, что основная сессия использует ключи подписи ECDSA, в то время как подсессия использует ключи подписи DSA для связи со старыми eepsite.

Подсессии используют те же пулы входящих и исходящих туннелей, что и основная сессия. Подсессии должны использовать те же ключи шифрования, что и основная сессия. Это относится как к ключам шифрования leaseSet, так и к (неиспользуемым) ключам шифрования Destination. Подсессии должны использовать разные ключи подписи в destination, поэтому хэш destination отличается от основной сессии. Поскольку подсессии используют те же ключи шифрования и туннели, что и основная сессия, всем очевидно, что Destination-ы работают на одном router-е, поэтому обычные гарантии анонимности против корреляции не применяются.

Подсессии создаются путем отправки сообщения CreateSession и получения ответного сообщения SessionStatus, как обычно. Подсессии должны создаваться после создания основной сессии. Ответ SessionStatus при успехе будет содержать уникальный Session ID, отличный от ID основной сессии. Хотя сообщения CreateSession должны обрабатываться по порядку, нет надежного способа сопоставить сообщение CreateSession с ответом, поэтому клиент не должен иметь несколько одновременно ожидающих ответа сообщений CreateSession. Параметры SessionConfig для подсессии могут не учитываться, если они отличаются от основной сессии. В частности, поскольку подсессии используют тот же tunnel pool, что и основная сессия, параметры tunnel могут игнорироваться.

Router отправит отдельные сообщения RequestVariableLeaseSet для каждого Destination клиенту, и клиент должен ответить сообщением CreateLeaseSet для каждого. Leases для двух Destination не обязательно будут идентичными, даже если они выбраны из одного и того же пула tunnel.

Подсессия может быть уничтожена с помощью сообщения DestroySession как обычно. Это не уничтожит основную сессию и не остановит I2CP соединение. Однако уничтожение основной сессии уничтожит все подсессии и остановит I2CP соединение. Сообщение Disconnect уничтожает все сессии.

Обратите внимание, что большинство, но не все сообщения I2CP содержат Session ID. Для тех, которые не содержат, клиентам может потребоваться дополнительная логика для правильной обработки ответов router. DestLookup и DestReply не содержат Session ID; используйте вместо них более новые HostLookup и HostReply. GetBandwidthLimts и BandwidthLimits не содержат session ID, однако ответ не является специфичным для сессии.

Примечания к версии

Начальный байт версии протокола (0x2a), отправляемый клиентом, не должен изменяться. До версии 0.8.7 информация о версии router не была доступна клиенту, что препятствовало работе новых клиентов со старыми router. Начиная с версии 0.8.7, строки версий протокола обеих сторон обмениваются в сообщениях Get/Set Date Messages. В дальнейшем клиенты могут использовать эту информацию для правильного взаимодействия со старыми router. Клиенты и router не должны отправлять сообщения, которые не поддерживаются другой стороной, поскольку они обычно разрывают сессию при получении неподдерживаемого сообщения.

Обмениваемая информация о версии представляет собой версию “основного” API или версию протокола I2CP, и не обязательно соответствует версии router’а.

Краткое описание версий протокола I2CP выглядит следующим образом. Подробности смотрите ниже.

Заголовок сообщения I2CP

Описание

Общий заголовок для всех I2CP сообщений, содержащий длину сообщения и тип сообщения.

Содержание

1. 4-байтовое Integer , указывающее длину тела сообщения
2. 1-байтовое Integer , указывающее тип сообщения.
3. Тело I2CP сообщения, 0 или более байт

Заметки

Фактический лимит длины сообщения составляет около 64 КБ.

Идентификатор сообщения

Описание

Уникально идентифицирует сообщение, ожидающее на конкретном router в определенный момент времени. Это всегда генерируется router и НЕ является тем же самым nonce, который генерируется клиентом.

Содержание

1. 4 байта Integer

Заметки

ID сообщений уникальны только в рамках сессии; они не являются глобально уникальными.

Полезная нагрузка

Описание

Эта структура представляет содержимое сообщения, доставляемого от одного Destination к другому.

Содержание

1. 4-байтовая длина Integer
2. Столько байт

Примечания

Полезная нагрузка представлена в формате gzip, как указано на странице обзора I2CP I2CP-FORMAT .

Фактический лимит длины сообщения составляет около 64 КБ.

Конфигурация сессии

Описание

Определяет параметры конфигурации для конкретной клиентской сессии.

Содержание

1. Destination
2. Mapping опций
3. Date создания
4. Signature предыдущих 3 полей, подписанная SigningPrivateKey

Примечания

• Опции указаны на странице обзора I2CP I2CP-OPTIONS .
• Mapping должен быть отсортирован по ключу, чтобы подпись была правильно проверена в router.
• Дата создания должна находиться в пределах +/- 30 секунд от текущего времени при обработке router’ом, иначе конфигурация будет отклонена.

Автономные подписи

• Если Destination подписан в автономном режиме, Mapping должен содержать три опции i2cp.leaseSetOfflineExpiration, i2cp.leaseSetTransientPublicKey, и i2cp.leaseSetOfflineSignature. Signature затем генерируется временным SigningPrivateKey и проверяется с помощью SigningPublicKey , указанного в i2cp.leaseSetTransientPublicKey. См. I2CP-OPTIONS для подробностей.

Идентификатор сессии

Описание

Уникально идентифицирует сессию на конкретном router в определённый момент времени.

Содержание

1. 2-байтовое Целое число

Примечания

Session ID 0xffff используется для обозначения “отсутствия сессии”, например, для поиска имён хостов.

Сообщения

См. также I2CP Javadocs .

Типы сообщений

Описание

Сообщить клиенту, какие ограничения пропускной способности установлены.

Отправляется от router к клиенту в ответ на GetBandwidthLimitsMessage .

Содержание

1. 4 байта Integer Лимит входящих соединений клиента (КБ/с)
2. 4 байта Integer Лимит исходящих соединений клиента (КБ/с)
3. 4 байта Integer Лимит входящих соединений router (КБ/с)
4. 4 байта Integer Лимит пиковых входящих соединений router (КБ/с)
5. 4 байта Integer Лимит исходящих соединений router (КБ/с)
6. 4 байта Integer Лимит пиковых исходящих соединений router (КБ/с)
7. 4 байта Integer Время пиковой нагрузки router (секунды)
8. Девять 4-байтовых Integer (не определено)

Примечания

Ограничения клиента могут быть единственными установленными значениями и могут представлять фактические ограничения router, или процент от ограничений router, или быть специфичными для конкретного клиента, в зависимости от реализации. Все значения, помеченные как ограничения router, могут быть равны 0, в зависимости от реализации. По состоянию на релиз 0.7.2.

BlindingInfoMessage

Описание

Уведомить router о том, что Destination является blinded, с дополнительным паролем для поиска и дополнительным приватным ключом для расшифровки. См. предложения 123 и 149 для подробностей.

Router должен знать, является ли место назначения скрытым. Если оно скрыто и использует секретную или индивидуальную аутентификацию клиента, ему также необходимо иметь эту информацию.

Host Lookup нового формата b32 адреса (“b33”) сообщает router’у, что адрес является скрытым, но нет механизма для передачи секретного или приватного ключа router’у в сообщении Host Lookup. Хотя мы могли бы расширить сообщение Host Lookup для добавления этой информации, более чистым решением будет определить новое сообщение.

Это сообщение предоставляет программный способ для клиента сообщить router’у. В противном случае пользователю пришлось бы вручную настраивать каждый пункт назначения.

Использование

Прежде чем клиент отправит сообщение к blinded destination (скрытому назначению), он должен либо найти “b33” в сообщении Host Lookup, либо отправить сообщение Blinding Info. Если blinded destination требует секрет или аутентификацию для каждого клиента, клиент должен отправить сообщение Blinding Info.

Router не отправляет ответ на это сообщение. Отправляется от клиента к router.

Содержание

1. ID сессии
2. 1 байт Integer Флаги

• Порядок битов: 76543210 > - Бит 0: 0 для всех, 1 для каждого клиента > - Биты 3-1: Схема аутентификации, если бит 0 установлен в 1 для > каждого клиента, иначе 000 > - 000: DH аутентификация клиента (или отсутствие аутентификации для каждого клиента) > - 001: PSK аутентификация клиента > - Бит 4: 1 если требуется секрет, 0 если секрет не требуется > - Биты 7-5: Не используются, устанавливаются в 0 для совместимости с будущими версиями

3. 1 байт Integer Тип конечной точки

• Тип 0 - это Hash > - Тип 1 - это имя хоста String > - Тип 2 - это Destination > - Тип 3 - это Sig Type и > SigningPublicKey

4. 2 байта Integer Тип слепой подписи
5. 4 байта Integer Секунды истечения срока с начала эпохи
6. Конечная точка: Данные как указано, одно из

• Тип 0: 32-байтный Hash > > - Тип 1: имя хоста String > > - Тип 2: бинарный Destination > > > > - Тип 3: 2-байтный Integer тип подписи, за которым следует > > - SigningPublicKey (длина как > подразумевается типом подписи)

7. PrivateKey Ключ расшифровки Присутствует только если бит флага 0 установлен в 1. 32-байтовый приватный ключ ECIES_X25519, little-endian
8. String Пароль поиска Присутствует только если бит флага 4 установлен в 1.

Примечания

• По состоянию на релиз 0.9.43.
• Тип конечной точки Hash вероятно не полезен, если только router не может выполнить обратный поиск в адресной книге для получения Destination.
• Тип конечной точки hostname вероятно не полезен, если только router не может выполнить поиск в адресной книге для получения Destination.

CreateLeaseSetMessage

УСТАРЕЛО. Не может использоваться для LeaseSet2, оффлайн ключей, типов шифрования отличных от ElGamal, множественных типов шифрования или зашифрованных LeaseSet. Используйте CreateLeaseSet2Message со всеми router версии 0.9.39 или выше.

Описание

Это сообщение отправляется в ответ на RequestLeaseSetMessage или RequestVariableLeaseSetMessage и содержит все структуры Lease , которые должны быть опубликованы в базе данных сети I2NP.

Отправлено от клиента к router.

Содержание

1. Session ID
2. DSA SigningPrivateKey или 20 игнорируемых байт
3. PrivateKey
4. LeaseSet

Примечания

SigningPrivateKey соответствует SigningPublicKey из LeaseSet, только если тип ключа подписи - DSA. Это предназначено для отзыва LeaseSet, который не реализован и вряд ли когда-либо будет реализован. Если тип ключа подписи не DSA, это поле содержит 20 байт случайных данных. Длина этого поля всегда составляет 20 байт, она никогда не равна длине приватного ключа подписи не-DSA типа.

PrivateKey соответствует PublicKey из LeaseSet. PrivateKey необходим для расшифровки сообщений, маршрутизируемых через garlic encryption.

Отзыв не реализован. Подключение к нескольким router не реализовано ни в одной клиентской библиотеке.

CreateLeaseSet2Message

Описание

Это сообщение отправляется в ответ на RequestLeaseSetMessage или RequestVariableLeaseSetMessage и содержит все структуры Lease , которые должны быть опубликованы в I2NP Network Database.

Отправляется от клиента к router. Начиная с версии 0.9.39. Аутентификация по клиенту для EncryptedLeaseSet поддерживается с версии 0.9.41. MetaLeaseSet пока не поддерживается через I2CP. См. предложение 123 для получения дополнительной информации.

Содержание

1. ID сессии
2. Один байт типа leaseSet, который следует далее.

• Тип 1 это LeaseSet (устарел) > - Тип 3 это LeaseSet2 > - Тип 5 это EncryptedLeaseSet > - Тип 7 это MetaLeaseSet

3. LeaseSet или LeaseSet2 или EncryptedLeaseSet или MetaLeaseSet
4. Однобайтовое число приватных ключей, которые следуют далее.
5. Список PrivateKey . По одному для каждого публичного ключа в lease set, в том же порядке. (Отсутствует для Meta LS2)

• Тип шифрования (2 байта Integer ) > - Длина ключа шифрования (2 байта Integer ) > - PrivateKey для шифрования (количество байт > как указано)

Примечания

PrivateKeys соответствуют каждому PublicKey из LeaseSet. PrivateKeys необходимы для расшифровки сообщений с garlic encryption.

См. предложение 123 для получения дополнительной информации о зашифрованных leaseSet.

Содержимое и формат для MetaLeaseSet являются предварительными и могут быть изменены. Протокол для администрирования нескольких router’ов не определен. Смотрите предложение 123 для получения дополнительной информации.

Приватный ключ подписи, ранее определенный для отзыва и неиспользуемый, отсутствует в LS2.

Предварительная версия с типом сообщения 40 была в 0.9.38, но формат был изменен. Тип 40 заброшен и не поддерживается. Тип 41 не действителен до версии 0.9.39.

CreateSessionMessage

Описание

Это сообщение отправляется клиентом для инициации сессии, где сессия определяется как подключение одного Destination к сети, через которое будут доставляться все сообщения для этого Destination и через которое этот Destination будет отправлять все сообщения любому другому Destination.

Отправляется от клиента к маршрутизатору. Маршрутизатор отвечает SessionStatusMessage .

Содержание

1. Конфигурация сессии

Примечания

• Это второе сообщение, отправленное клиентом. Ранее клиент отправил GetDateMessage и получил ответ SetDateMessage .
• Если дата в конфигурации сессии слишком отличается (более чем на +/- 30 секунд) от текущего времени router’а, сессия будет отклонена.
• Если на router’е уже существует сессия для этого Destination, сессия будет отклонена.
• Mapping в конфигурации сессии должен быть отсортирован по ключу, чтобы подпись была корректно проверена в router’е.

DestLookupMessage

Описание

Отправляется от клиента к router’у. Router отвечает сообщением DestReplyMessage .

Содержание

1. SHA-256 Hash

Примечания

Начиная с версии 0.7.

Начиная с версии 0.8.3, поддерживаются множественные одновременные запросы, и запросы поддерживаются как в I2PSimpleSession, так и в стандартных сессиях.

HostLookupMessage является предпочтительным начиная с версии 0.9.11.

DestReplyMessage

Описание

Отправляется от Router к Client в ответ на DestLookupMessage .

Содержание

1. Destination при успехе, или Hash при неудаче

Примечания

Начиная с версии 0.7.

Начиная с версии 0.8.3, запрошенный Hash возвращается при неудачном поиске, чтобы клиент мог иметь несколько активных запросов и сопоставлять ответы с запросами. Чтобы сопоставить ответ Destination с запросом, возьмите Hash от Destination. До версии 0.8.3 ответ был пустым при неудаче.

DestroySessionMessage

Описание

Это сообщение отправляется от клиента для уничтожения сессии.

Отправляется от клиента к router. Router должен ответить сообщением SessionStatusMessage (Destroyed). Однако см. важные примечания ниже.

Содержание

1. ID сессии

Заметки

На данном этапе router должен освободить все ресурсы, связанные с сессией.

В API 0.9.66 Java I2P router и клиентские библиотеки существенно отклоняются от данной спецификации. Router никогда не отправляет ответ SessionStatus(Destroyed). Если сессий не осталось, он отправляет DisconnectMessage . Если остаются подсессии или основная сессия, он не отвечает.

Клиентская библиотека Java отвечает на сообщение SessionStatus уничтожением всех сессий и переподключением.

Уничтожение отдельных подсессий на соединении с несколькими сессиями может быть не полностью протестировано или не работать в различных реализациях router и клиентов. Будьте осторожны.

Реализации должны обрабатывать уничтожение основной сессии как уничтожение всех подсессий, но позволять уничтожение одной подсессии с сохранением соединения открытым, однако Java I2P сейчас этого не делает. Если поведение Java I2P изменится в последующих выпусках, это будет задокументировано здесь.

DisconnectMessage

Описание

Сообщить другой стороне о наличии проблем и том, что текущее соединение будет разорвано. Это завершает все сессии на данном соединении. Сокет будет закрыт в ближайшее время. Отправляется либо от router к клиенту, либо от клиента к router.

Содержание

1. Причина String

Примечания

Реализовано только в направлении от router к клиенту, по крайней мере в Java I2P.

GetBandwidthLimitsMessage

Описание

Запросить у router информацию о текущих ограничениях пропускной способности.

Отправляется от клиента к router. Router отвечает сообщением BandwidthLimitsMessage .

Содержание

Нет

Заметки

По состоянию на выпуск 0.7.2.

Начиная с версии 0.8.3, поддерживается как в I2PSimpleSession, так и в стандартных сессиях.

GetDateMessage

Описание

Отправляется от клиента к router. Router отвечает сообщением SetDateMessage .

Содержание

1. Версия I2CP API String
2. Аутентификация Mapping (опционально, начиная с релиза 0.9.11)

Заметки

• Обычно это первое сообщение, отправляемое клиентом после отправки байта версии протокола.
• Строка версии включена начиная с релиза 0.8.7. Это полезно только если клиент и router не находятся в одной JVM. Если она отсутствует, клиент имеет версию 0.8.6 или более раннюю.
• Начиная с релиза 0.9.11, может быть включено Mapping аутентификации с ключами i2cp.username и i2cp.password. Mapping не обязательно должно быть отсортировано, поскольку это сообщение не подписывается. До релиза 0.9.10 включительно аутентификация включалась в Session Config Mapping, и аутентификация не применялась для GetDateMessage , GetBandwidthLimitsMessage или DestLookupMessage . Когда включена, аутентификация через GetDateMessage требуется перед любыми другими сообщениями начиная с релиза 0.9.16. Это полезно только вне контекста router. Это несовместимое изменение, но затронет только сессии вне контекста router с аутентификацией, что должно быть редким случаем.

HostLookupMessage

Описание

Отправляется от клиента к router. Router отвечает сообщением HostReplyMessage .

Это заменяет DestLookupMessage и добавляет ID запроса, таймаут и поддержку поиска по имени хоста. Поскольку это также поддерживает поиск по Hash, оно может использоваться для всех поисков, если router это поддерживает. Для поиска по имени хоста, router будет запрашивать naming service своего контекста. Это полезно только если клиент находится вне контекста router’а. Внутри контекста router’а клиент должен самостоятельно запрашивать naming service, что гораздо более эффективно.

Содержание

1. Session ID
2. 4 байта Integer ID запроса
3. 4 байта Integer тайм-аут (мс)
4. 1 байт Integer тип запроса
5. SHA-256 Hash или имя хоста String или Destination

Типы запросов:

Примечания

• Начиная с релиза 0.9.11. Используйте DestLookupMessage для старых router’ов.
• ID сессии и ID запроса будут возвращены в HostReplyMessage . Используйте 0xFFFF для ID сессии, если сессии нет.
• Timeout полезен для Hash поиска. Рекомендуемый минимум 10,000 (10 сек.). В будущем он также может быть полезен для поиска в удаленной службе имен. Значение может не учитываться для поиска локальных имен хостов, который должен быть быстрым.
• Поиск имени хоста в Base 32 поддерживается, но предпочтительно сначала преобразовать его в Hash.

HostReplyMessage

Описание

Отправляется от Router к Client в ответ на HostLookupMessage .

Содержание

1. Session ID
2. 4-байтовый Integer идентификатор запроса
3. 1-байтовый Integer код результата

• 0: Успешно > - 1: Неудача > - 2: Требуется пароль для поиска (начиная с версии 0.9.43) > - 3: Требуется приватный ключ (начиная с версии 0.9.43) > - 4: Требуются пароль для поиска и приватный ключ (начиная с версии 0.9.43) > - 5: Ошибка расшифровки leaseSet (начиная с версии 0.9.43) > - 6: Ошибка поиска leaseSet (начиная с версии 0.9.66) > - 7: Неподдерживаемый тип поиска (начиная с версии 0.9.66)

4. Destination , присутствует только если код результата равен нулю, за исключением того, что может также возвращаться для типов поиска 2-4. См. ниже.
5. Mapping , присутствует только если код результата равен нулю, возвращается только для типов поиска 2-4. Начиная с версии 0.9.66. См. ниже.

Ответы для типов поиска 2-4

Предложение 167 определяет дополнительные типы поиска, которые возвращают все опции из leaseSet, если они присутствуют. Для типов поиска 2-4 router должен получить leaseSet, даже если ключ поиска находится в адресной книге.

В случае успеха, HostReply будет содержать опции Mapping из leaseset и включит их как элемент 5 после destination. Если в Mapping нет опций, или leaseset был версии 1, он всё равно будет включён как пустой Mapping (два байта: 0 0). Будут включены все опции из leaseset, а не только опции записей служб. Например, могут присутствовать опции для параметров, которые будут определены в будущем. Возвращаемый Mapping может быть отсортирован или нет, в зависимости от реализации.

При неудаче поиска leaseset ответ будет содержать новый код ошибки 6 (Неудача поиска leaseset) и не будет включать сопоставление. Когда возвращается код ошибки 6, поле Destination может присутствовать или отсутствовать. Оно будет присутствовать, если поиск имени хоста в адресной книге был успешным, или если предыдущий поиск был успешным и результат был кэширован, или если Destination присутствовал в сообщении поиска (тип поиска 4).

Если тип поиска не поддерживается, ответ будет содержать новый код ошибки 7 (тип поиска не поддерживается).

Примечания

• Начиная с релиза 0.9.11. См. заметки к HostLookupMessage .
• ID сессии и ID запроса соответствуют тем, что указаны в HostLookupMessage .
• Код результата: 0 для успеха, 1-255 для неудачи. 1 означает общую ошибку. Начиная с версии 0.9.43, были определены дополнительные коды ошибок 2-5 для поддержки расширенных ошибок при “b33” поиске. См. предложения 123 и 149 для дополнительной информации. Начиная с версии 0.9.66, были определены дополнительные коды ошибок 6-7 для поддержки расширенных ошибок при поиске типа 2-4. См. предложение 167 для дополнительной информации.

MessagePayloadMessage

Описание

Доставить полезную нагрузку сообщения клиенту.

Отправляется от router к клиенту. Если i2cp.fastReceive=true, что не является значением по умолчанию, клиент отвечает ReceiveMessageEndMessage .

Содержание

1. ID сессии
2. ID сообщения
3. Полезная нагрузка

Заметки

MessageStatusMessage

Описание

Уведомить клиента о статусе доставки входящего или исходящего сообщения. Отправляется от Router к Client. Если это сообщение указывает, что входящее сообщение доступно, клиент отвечает ReceiveMessageBeginMessage . Для исходящего сообщения это ответ на SendMessageMessage или SendMessageExpiresMessage .

Содержание

1. Session ID
2. Message ID , сгенерированный router’ом
3. 1 байт Integer статус
4. 4 байта Integer размер
5. 4 байта Integer nonce, ранее сгенерированный клиентом

Примечания

До версии 0.9.4 известными значениями статуса являются: 0 для сообщения доступно, 1 для принято, 2 для успешной доставки best effort, 3 для неудачной доставки best effort, 4 для успешной гарантированной доставки, 5 для неудачной гарантированной доставки. Целое число size указывает размер доступного сообщения и актуально только для статуса = 0. Несмотря на то, что гарантированная доставка не реализована (единственным сервисом является best effort), текущая реализация router использует коды статуса гарантированной доставки, а не коды best effort.

Начиная с версии router 0.9.5, определены дополнительные коды состояния, однако они не обязательно реализованы. См. MessageStatusMessage Javadocs для получения подробной информации. Для исходящих сообщений коды 1, 2, 4 и 6 указывают на успех; все остальные являются ошибками. Возвращаемые коды ошибок могут различаться и зависят от реализации.

Все коды состояния:

ReceiveMessageBeginMessage

УСТАРЕЛО. Не поддерживается i2pd.

Описание

Запросить у router доставку сообщения, о котором он был ранее уведомлен. Отправляется от клиента к router. Router отвечает сообщением MessagePayloadMessage .

Содержание

1. ID сессии
2. ID сообщения

Примечания

ReceiveMessageBeginMessage отправляется как ответ на MessageStatusMessage , сообщающее о том, что новое сообщение доступно для получения. Если идентификатор сообщения, указанный в ReceiveMessageBeginMessage , недействителен или неверен, router может просто не ответить или отправить обратно DisconnectMessage .

Это не используется в режиме “быстрого получения”, который является настройкой по умолчанию начиная с версии 0.9.4.

ReceiveMessageEndMessage

УСТАРЕЛО. Не поддерживается i2pd.

Описание

Сообщить router’у, что доставка сообщения была успешно завершена и что router может удалить сообщение.

Отправлено с клиента на router.

Содержание

1. ID сессии
2. ID сообщения

Заметки

Сообщение ReceiveMessageEndMessage отправляется после того, как MessagePayloadMessage полностью доставляет полезную нагрузку сообщения.

Это не используется в режиме “быстрого приёма”, который является режимом по умолчанию начиная с версии 0.9.4.

ReconfigureSessionMessage

Описание

Отправляется от клиента к router для обновления конфигурации сессии. Router отвечает сообщением SessionStatusMessage .

Содержание

1. ID сессии
2. Конфигурация сессии

Примечания

• По состоянию на релиз 0.7.1.
• Если дата в Session Config слишком сильно отличается (более чем на +/- 30 секунд) от текущего времени router’а, сессия будет отклонена.
• Mapping в Session Config должен быть отсортирован по ключу, чтобы подпись была правильно валидирована в router’е.
• Некоторые параметры конфигурации могут быть установлены только в CreateSessionMessage , и изменения здесь не будут распознаны router’ом. Изменения параметров tunnel inbound.* и outbound.* всегда распознаются.
• В общем случае router должен объединить обновленную конфигурацию с текущей конфигурацией, поэтому обновленная конфигурация должна содержать только новые или измененные параметры. Однако из-за объединения параметры нельзя удалить таким образом; они должны быть явно установлены в желаемое значение по умолчанию.

ReportAbuseMessage

УСТАРЕЛО, НЕ ИСПОЛЬЗУЕТСЯ, НЕ ПОДДЕРЖИВАЕТСЯ

Описание

Сообщить другой стороне (клиенту или router), что она находится под атакой, возможно со ссылкой на конкретный MessageId. Если router находится под атакой, клиент может принять решение о миграции на другой router, а если клиент находится под атакой, router может перестроить свои маршруты или внести в черный список некоторых из узлов, которые отправляли ему сообщения с атакой.

Отправляется либо от router к клиенту, либо от клиента к router.

Содержание

1. Session ID
2. 1 байт Integer степень нарушения (0 — минимальное нарушение, 255 — крайне серьёзное нарушение)
3. Причина String
4. Message ID

Примечания

Не используется. Не полностью реализовано. И router, и клиент могут генерировать ReportAbuseMessage , но ни у одного из них нет обработчика для этого сообщения при получении.

RequestLeaseSetMessage

УСТАРЕЛО. Не поддерживается i2pd. Не отправляется Java I2P клиентам версии 0.9.7 или выше (2013-07). Используйте RequestVariableLeaseSetMessage.

Описание

Запрос клиенту на авторизацию включения определенного набора входящих tunnel. Отправляется с Router на клиента. Клиент отвечает сообщением CreateLeaseSetMessage .

Первое из этих сообщений, отправленных в сессии, является сигналом клиенту о том, что tunnel построены и готовы к передаче трафика. Router не должен отправлять первое из этих сообщений до тех пор, пока не будут построены как минимум один входящий И один исходящий tunnel. Клиенты должны прервать сессию по таймауту и уничтожить её, если первое из этих сообщений не получено в течение некоторого времени (рекомендуется: 5 минут или более).

Содержание

1. Session ID
2. 1 байт Integer количество tunnel’ов
3. Столько же пар:
   1. Hash
   2. TunnelId
4. Конец Date

Примечания

Это запрашивает LeaseSet со всеми записями Lease , для которых установлено одинаковое время истечения. Для клиентских версий 0.9.7 или выше используется RequestVariableLeaseSetMessage .

RequestVariableLeaseSetMessage

Описание

Запрос на то, чтобы клиент авторизовал включение определенного набора входящих tunnel’ов.

Отправляется от router к клиенту. Клиент отвечает CreateLeaseSetMessage или CreateLeaseSet2Message .

Первое из этих сообщений, отправляемых в сессии, является сигналом клиенту о том, что tunnel построены и готовы для трафика. Router не должен отправлять первое из этих сообщений до тех пор, пока не будет построен хотя бы один входящий И один исходящий tunnel. Клиенты должны завершать по таймауту и уничтожать сессию, если первое из этих сообщений не получено через некоторое время (рекомендуется: 5 минут или более).

Содержание

1. ID сессии
2. 1 байт Integer количество tunnel’ов
3. Соответствующее количество записей Lease

Примечания

Это запрашивает LeaseSet с индивидуальным временем истечения для каждого Lease .

Начиная с версии 0.9.7. Для клиентов более ранних версий используйте RequestLeaseSetMessage .

SendMessageMessage

Описание

Так клиент отправляет сообщение (полезную нагрузку) в Destination . Router будет использовать срок истечения по умолчанию.

Отправляется от клиента к router. Router отвечает MessageStatusMessage .

Содержание

1. Session ID
2. Destination
3. Payload
4. 4-байтовый Integer nonce

Заметки

Как только SendMessageMessage поступает полностью целым, router должен вернуть MessageStatusMessage , указывающее, что сообщение принято к доставке. Это сообщение будет содержать тот же nonce, который был отправлен здесь. Позже, основываясь на гарантиях доставки конфигурации сессии, router может дополнительно отправить обратно еще один MessageStatusMessage , обновляющий статус.

Начиная с версии 0.8.1, router не отправляет ни одно MessageStatusMessage , если i2cp.messageReliability=none.

До выпуска версии 0.9.4 значение nonce равное 0 не допускалось. Начиная с версии 0.9.4, значение nonce равное 0 разрешено и указывает router’у, что он не должен отправлять MessageStatusMessage , то есть это работает как если бы для данного сообщения было установлено i2cp.messageReliability=none.

До выпуска 0.9.14 сессия с i2cp.messageReliability=none не могла быть переопределена для отдельного сообщения. Начиная с выпуска 0.9.14, в сессии с i2cp.messageReliability=none клиент может запросить доставку MessageStatusMessage с информацией об успехе или неудаче доставки, установив nonce в ненулевое значение. Router не отправит MessageStatusMessage “принято”, но позже отправит клиенту MessageStatusMessage с тем же nonce и значением успеха или неудачи.

SendMessageExpiresMessage

Описание

Отправляется от клиента к router. То же самое, что SendMessageMessage , за исключением того, что включает время истечения и опции.

Содержание

1. Session ID
2. Destination
3. Payload
4. 4-байтовый Integer nonce
5. 2 байта флагов (опции)
6. Date истечения срока, сокращенная с 8 байт до 6 байт

Примечания

По состоянию на версию 0.7.1.

В режиме “best effort”, как только SendMessageExpiresMessage поступает полностью неповрежденным, router должен вернуть MessageStatusMessage, указывающее, что сообщение было принято к доставке. Это сообщение будет содержать тот же nonce, который был отправлен здесь. Позже, основываясь на гарантиях доставки конфигурации сессии, router может дополнительно отправить обратно другое MessageStatusMessage с обновлением статуса.

Начиная с версии 0.8.1, router не отправляет сообщения Message Status Message, если i2cp.messageReliability=none.

До версии 0.9.4 значение nonce равное 0 не допускалось. Начиная с версии 0.9.4, значение nonce равное 0 разрешено и указывает router’у, что он не должен отправлять никаких Message Status Message, то есть это действует так, как если бы для данного сообщения было установлено i2cp.messageReliability=none.

До версии 0.9.14 сессия с i2cp.messageReliability=none не могла быть переопределена для отдельного сообщения. Начиная с версии 0.9.14, в сессии с i2cp.messageReliability=none клиент может запросить доставку Message Status Message с результатом успешной или неудачной доставки, установив nonce в ненулевое значение. Router не отправит “accepted” Message Status Message, но позже отправит клиенту Message Status Message с тем же nonce и значением успеха или неудачи.

Поле флагов

Начиная с релиза 0.8.4, верхние два байта поля Date переопределены для содержания флагов. Флаги должны по умолчанию иметь значение все нули для обратной совместимости. Date не будет затрагивать поле флагов до 10889 года. Флаги могут использоваться приложением для предоставления подсказок router’у о том, должен ли LeaseSet и/или ElGamal/AES Session Tags доставляться вместе с сообщением. Настройки значительно повлияют на количество протокольных накладных расходов и надежность доставки сообщений. Отдельные биты флагов определены следующим образом, начиная с релиза 0.9.2. Определения могут изменяться. Используйте класс SendMessageOptions для конструирования флагов.

Порядок битов: 15…0

Биты 15-11

Не используется, должно быть ноль

Биты 10-9

Переопределение надежности сообщений (не реализовано, будет удалено).

: Если 1, не включать leaseSet в garlic с этим сообщением. Если

0, the router may bundle a lease set at its discretion.

Биты 7-4

Нижний порог тегов. Если доступно меньше этого количества тегов,

send more. This is advisory and does not force tags to be delivered. For ElGamal only. Ignored for ECIES-Ratchet.

: Количество тегов для отправки при необходимости. Это рекомендательное значение и не

force tags to be delivered. For ElGamal only. Ignored for
ECIES-Ratchet.

Описание

Уведомить клиента о статусе его сессии.

Отправляется от router к клиенту в ответ на CreateSessionMessage , ReconfigureSessionMessage или DestroySessionMessage . Во всех случаях, включая ответ на CreateSessionMessage , router должен отвечать немедленно (не ждать построения tunnel).

Содержание

1. Session ID
2. 1 байт Integer статус

Значения статуса определены выше. Если статус Created, то Session ID является идентификатором, который будет использоваться для остальной части сессии.

SetDateMessage

Описание

Текущие дата и время. Отправляется от Router к клиенту как часть начального рукопожатия. Начиная с релиза 0.9.20, также может отправляться в любое время после рукопожатия для уведомления клиента о сдвиге часов.

Содержание

1. Date
2. Версия I2CP API String

Заметки

Это обычно первое сообщение, отправляемое router’ом. Строка версии включается начиная с релиза 0.8.7. Это полезно только в том случае, если клиент и router не находятся в одной JVM. Если она отсутствует, то router имеет версию 0.8.6 или более раннюю.

Дополнительные сообщения SetDate не будут отправляться клиентам в той же JVM.

Ссылки

• Date
• Destination
• EncryptedLeaseSet
• Hash
• Обзор I2CP
• Javadocs I2CP
• Integer
• Lease
• LeaseSet
• LeaseSet2
• Mapping
• MetaLeaseSet
• Javadocs MessageStatusMessage
• PrivateKey
• PublicKey
• RouterIdentity
• SAMv3
• Signature
• SigningPrivateKey
• SigningPublicKey
• String
• TunnelId