вопрос закрыт, причина была в банальной невнимательности и к сокетам никакого отношения не имела
Есть сервер аутентификации 'hAuthD', который, почему-то, не очень дружит с .NET-сокетами. Хотя, скорее, я просто не учитываю какую-то специфику и потому нуждаюсь в помощи коллективного разума.
Т.е. этот auth-сервер корректно обрабатывает запросы от нативного клиента, от тестового модуля на Pascal, от тестового модуля на Java. Но тот же самый код, реализованный на .NET, провоцирует странное поведение.
Дабы исключитль некоторые варианты:
1. Инициализирующий пакет от сервера обрабатывается корректно, т.е. получается в полном объёме (186 байт), раскодируется по blowfish константным ключом, разксоривается, после чего из него извлекается ID-сессии, RSA и bf-ключ для последующего шифрования. Ответный пакет для сервера (42 байта) также формируется корректно (делал дампы пакетов от других клиентов и прогонял через "свою" реализацию для сравнения).
2. Тестовое окружение полностью идетнично. Файрвол ничего не режет. Антивирусы выключены.
3. Опенсурсный .NET-бот, который есть на GIT-е, демонстрирует аналогичное ошибочное поведение.
Типовой проблемный сценарий:
1. Открыть подключение.
2. Получить 186 байт инит-пакета.
3. Отправить пакет на сервер.
4. Попытаться считать ответ сервера.
На п.4. сокет задумывается на несколько секунд и возвращает '0', сигнализирующий, что сервер закрыл подключение.
При этом, если в п.3, вместо корректного пакета, отправить какой-нибудь хлам, то сервер рвёт соединение мгновенно.
В попытках разобраться, установил на сервер сниффер и обнаружил, что когда идёт работа через .NET-сокеты, на сервер улетают какие-то дополнительные системные TCP-пакеты, которые я сам явно не отправляю и, вроде бы, установкой никаких опций в коде не провоцирую.
На приложенном скрине пример такого пакета. При работе через другие клиенты этот пакет отсутствует. Хотя, вероятно, проблема и не в нём, но пока это единственное отличие, которое мне удалось выявить.
Ещё была мысль, что .NET-сокет вовсе не отправляет маленький пакет, т.к. он маленький и система ждёт ещё немного данных, чтобы отправить их одним общим пакетом. Однако, сниффер на стороне сервера показывает получение пакета размером 42 байта. И опция сокета "NoDelay", которая, судя по документации, имеет к этому прямое отношение, на результате никак не сказывается.
Есть сервер аутентификации 'hAuthD', который, почему-то, не очень дружит с .NET-сокетами. Хотя, скорее, я просто не учитываю какую-то специфику и потому нуждаюсь в помощи коллективного разума.
Т.е. этот auth-сервер корректно обрабатывает запросы от нативного клиента, от тестового модуля на Pascal, от тестового модуля на Java. Но тот же самый код, реализованный на .NET, провоцирует странное поведение.
Дабы исключитль некоторые варианты:
1. Инициализирующий пакет от сервера обрабатывается корректно, т.е. получается в полном объёме (186 байт), раскодируется по blowfish константным ключом, разксоривается, после чего из него извлекается ID-сессии, RSA и bf-ключ для последующего шифрования. Ответный пакет для сервера (42 байта) также формируется корректно (делал дампы пакетов от других клиентов и прогонял через "свою" реализацию для сравнения).
2. Тестовое окружение полностью идетнично. Файрвол ничего не режет. Антивирусы выключены.
3. Опенсурсный .NET-бот, который есть на GIT-е, демонстрирует аналогичное ошибочное поведение.
Типовой проблемный сценарий:
1. Открыть подключение.
2. Получить 186 байт инит-пакета.
3. Отправить пакет на сервер.
4. Попытаться считать ответ сервера.
На п.4. сокет задумывается на несколько секунд и возвращает '0', сигнализирующий, что сервер закрыл подключение.
При этом, если в п.3, вместо корректного пакета, отправить какой-нибудь хлам, то сервер рвёт соединение мгновенно.
В попытках разобраться, установил на сервер сниффер и обнаружил, что когда идёт работа через .NET-сокеты, на сервер улетают какие-то дополнительные системные TCP-пакеты, которые я сам явно не отправляю и, вроде бы, установкой никаких опций в коде не провоцирую.
На приложенном скрине пример такого пакета. При работе через другие клиенты этот пакет отсутствует. Хотя, вероятно, проблема и не в нём, но пока это единственное отличие, которое мне удалось выявить.
Ещё была мысль, что .NET-сокет вовсе не отправляет маленький пакет, т.к. он маленький и система ждёт ещё немного данных, чтобы отправить их одним общим пакетом. Однако, сниффер на стороне сервера показывает получение пакета размером 42 байта. И опция сокета "NoDelay", которая, судя по документации, имеет к этому прямое отношение, на результате никак не сказывается.
![[Изображение: 4e38c909fcd08c5fcdf363b54a62.png]](http://klikr.org/4e38c909fcd08c5fcdf363b54a62.png)