Непонятки с пассивным и активным режимом пользователей в протоколе ADC, Как однозначно определить режим пользователей в протоколе ADC?

Ссылка ADC портал: http://adcportal.sourceforge.net/ нерабочая. А также они закрыли форум... видимо потому что он пустовал. Описание протокола чересчур минималистичное, а вопросы задавать негде...
К сути, не могу понять, в протоколе не описано вообще про пассивный/активный режим. Многим кажется это очевидным, а мне вот нет.
Подсказали тут что если ipv4 адрес хабом не передан, пользователь пассивный, иначе активный.
Но углубляясь в детали я заметил что некоторые хабы шлют ipv4 адрес отдельно, через некоторое время плсле присоединения.
В таком случае до этого клиент определяется как пассивный, хотя на деле он может таковым и не являться.
Также некоторые хабы вообще не отсылают ip адрес после входа, а отсылают только по команде CTM. До этого все пользователи получается считаются в пассивном режиме? В общем не понятно.
В NMDC к примеру и пассивный и активный режими идентифицировались однозначно и получалось всего 3 - активный, пассивный, неизвестный (если MyINFO не отослана). А в ADC получается всего 2 - активный и неизвестный.
В общем разъясните кто понял.
И также с поисковыми запросами, неуловил никакой корреляции между режимами пользователей и отправляемыми ими поисковыми запросами.
Тут http://mydc.ru/topic2033s20.html?p=37962#entry37962 приведены примеры и показана разница между пассивами FSCH и BSCH, но на практике и то и другое шлют как пассивы, так и активы, если следовать из логики их определение по ip адресу.

В ADC пассивные пользователи не отсылают на хаб ip адрес в команде INF. Действительно зачем этот адрес если с пользователем всё равно соединиться нельзя, ведь обычно это адрес не пользователя, а маршрутизатора, за которым он находится.

Активные пользователи обязаны отправлять на хаб свой ip адрес. Причём если они отправляют адрес 0.0.0.0 для ipv4 (или :: для ipv6), то хаб должен заменять его на соответствующий адрес пользователя.

А как поисковые запросы идентифицировать? Ведь надо знать режим пользователя, чтобы правильно ему ответ отослать

всё определяется из параметра SU команды INF

В ADC протоколе в поле SU команды INF указываются характеристики клиента. Именно исходя из наличия тех или иных характеристик можно судить о пассивности пользователя.

Вы меня еще больше запутали.
Вот пример INF строки

В ней передан I4 - т.е. по прошлой логике это активный пользователь. Но в ней передана в SU и NAT0, т.е. по вашим словам пользователь пассивный.
Но есть клиенты, которые не поддерживают NAT0 и не отсылают его в SU, т.е. тогда они все у меня будут активные, что неправильно.
Как именно по SU определять? Что это за те или иные характеристики?

Про ip адрес я наверное неправильно сказал, хотя это справедливо для некоторых клиентов.

Вообще в ADC нельзя точно сказать: "вот этот пользователь пассивный, а вот этот пользователь - активный". Речь идёт только о степени пассивности. То есть, в каких-то случаях он пассивный, а в каких-то - активный. Всё зависит от типа взаимодействия и от характеристик того или иного пользователя в параметре SU.

А как же мне тогда отвечать на поисковый запрос? Если пользователь активный - мне надо отвечать по UDP, если пассивный, то по TCP через хаб. Если хаб не передает адреса пользователей, тогда все ответы на все поисковые запросы поплывут через него. Все активы будут ждать ответов по UDP и не получат их.
Нужно жесткое определение пассивов и активов, чтобы система функционировала правильно.

Если отошлёшьто ответят по TCP естественно через хаб.

Если отошлёшьто ответят напрямую либо по UDP, либо по TCP, в зависимости от того что ты поддерживаешь в SU.

В общем понятно, введние этих параметров в запрос очередная, непонятно зачем введенная, избыточность, т.к. в конечном итоге все сходится с параметрами INF

Каких именно параметров? Всё параметры нужны без них ничего работать не будет

Ну я проверил, если в SU у пользователя есть TCP4, он шлет BSCH, если нет, он шлет FSCH.
Т.ч. режим однозначно идентифицируется TCP4.

Капитальный форум и был на ADC портале, и он отнюдь не пустовал.