Взаимодействие клиента с сервером в I2P выглядит так. Сервер публикует в NetDB Leaseset со списком входящих туннелей. Когда клиент хочет обратиться к серверу, то он получает Leaseset из NetDB, обращается к серверу через входящие туннели. Когда туннели сервера обновляются, клиент их получает не из NetDB, а непосредственно от сервера. Всем клиентам сообщается одинаковый список входящих туннелей.
Предлагаю улучшение для серверов, принимающих или раздающих большие файлы, т.е. использующих длительные соединения с непрерывной передачей данных.
Изначально все клиенты используют одни и те же входящие туннели сервера, получаемые из NetDB, других вариантов нет. Когда объем передаваемых данных (или время соединения) превысил заданный порог, сервер создает 1-2 входящих и исходящих туннеля, которые будет использовать исключительно с этим клиентом. Клиенту теперь отдает Leaseset с этими уникальными входящими туннелями. Постепенно клиент пересаживается на них.
Таким образом мы избегаем ситуации, когда большое количество клиентов совместно используют одни и те же туннели сервера и перегружают их. Описанная схема имеет общие черты с работой onion-сервисов, в которых к каждому к клиенту выстраивается своя цепочка.
Если клиент, посаженный на уникальные туннели, перестал использовать пропускную способность, сервер будет его пересаживать обратно на общие туннели и закрывать ненужные уникальные. Уникальные туннели отключившегося клиента можно перераспределить между другими клиентами или закрыть.
