Вторник 27 Октября 2020 12:45:06, Vitold Sedyshev писал(а) к Jaroslav Bespalov:
VS>>> Значит мы говорим о том, что в GoldEd есть проблема. JB>> Да. Нет желания исправить? :)
VS> Я смотрел исходный код GoldEd+ и в целом даже думал как можно решить VS> проблему.
VS> У меня было пару мыслей, но мне не понравился код и структурирование VS> проекта, так что я не стал этого делать.
Я сам не в состоянии толком проанализировать такой объем, но от знающих людей слышал, что проще переписать. Это да.
VS>>> Еще вопросы? JB>> Как научить binkd дропать соединение, если на другой стороне твой JB>> GP? VS> Когда binkd принимает соединение он получает пакеты с тегами, VS> так вот Golden Point отправляет свой идентификатор GoldenPoint/1.2.14
Да. Команда M_NULL "VER..."
VS> Где-то на стадии подключения в коде binkd можно добавить проверку и VS> сбрасывать подключение.
В том то и дело, что я надеялся обрабатывать это чем-то вроде перл-хука, но пока не соображу - реально ли это вообще.
VS> В целом можно просто в правилах для новых пользователей узла указать VS> рекомендуемый софт.
Это я уже донес.
Если я правильно понял, GP не говорит M_EOB, когда нечего отправлять. То есть, получив от вызываемой M_OK, он должен ответить M_EOB? (не уверен, но похоже на то). Из-за этого принимающая система видит неожиданный разрыв. Это стандарт binkp 1.1. Цитата: "Для того, чтобы иметь возможность принимать запросы (FREQs, в частности) и отправлять их результаты назад за одну сессию, в случае, если с другой стороны binkp/1.1 и выше, binkd 9.0 следует следующему соглашению -- когда обе стороны обменялись EOB, сессия не завершается, а перезапускается сбросом binkp в состояние, которое он имел сразу после логина (то есть выполняется рескан и начинается отсылка найденных файлов). Сессия считается успешно завершенной, если между двумя последовательными обменами EOF стороны не передали и не приняли ни одной команды binkp."
А так как GP явно не говорит, что он binkp/1.0, принимается, что он работает по протоколу версии 1.1
