Не получается прочитать данные от сервера с помощью SocketRead. ERR_NETSOCKET_IO_ERROR код 5273 - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Посмотрите точное объяснение в комментарии 5.
TLS - это блочный логический режим, который не имеет отношения к физическому количеству сырых байт в сокете. TLS расшифровка работает блоками вплоть до 16-32 кб и поэтому наличия 1292 сырых байт может быть недостаточно для расшифровки блока.
Поэтому алгоритм чтения при TLS должен быть такой:
Посмотрите точное объяснение в комментарии 5.
TLS - это блочный логический режим, который не имеет отношения к физическому количеству сырых байт в сокете. TLS расшифровка работает блоками вплоть до 16-32 кб и поэтому наличия 1292 сырых байт может быть недостаточно для расшифровки блока.
Поэтому алгоритм чтения при TLS должен быть такой:
Можете привести пример кода, как правильно читать TLS данные?
Можете привести пример кода, как правильно читать TLS данные?
Привел выше псевдокод.
Давайте сами - самое сложное в понимании "сырые байты != расшифрованные".
Функцией SocketIsReadable?
Функцией SocketTlsReadAvailable? Если да, то с каким значением параметра buffer_maxlen?
Что является признаком конца?
a)функция SocketTlsReadAvailable возвращает -1?
б)возникает ошибка 5273 после вызова SocketTlsReadAvailable?
Функцией SocketIsReadable?
Да.
Функцией SocketTlsReadAvailable? Если да, то с каким значением параметра buffer_maxlen?
Да.
Какой размер - это вам решать, так как это ваш протокол внутри TLS.
Если бинарный типа [type,size, data], то все понятно как и сколько читать. Если же текстовый HTTP/FIX, то выставьте buffer_maxlen например в 16 кб и читайте блоками сколько отдадут. Гибкость функции SocketTlsReadAvailable как раз в том, что она сразу без ожидания отдаст тот объем, что уже можно декодировать.
А вот SocketTlsRead будет ждать доступности точного количества указанных байт. Что чревато зависанием до таймаута.
Что является признаком конца?
a)функция SocketTlsReadAvailable возвращает -1?
б)возникает ошибка 5273 после вызова SocketTlsReadAvailable?
Возврат -1 означает ошибку с закрытием сокета, если в _LastError находится ошибка 5273 (ERR_NETSOCKET_IO_ERROR).
Вообще TLS категорически плохо подходит для шифрации low latency потоковых данных типа ценовых потоков или сделок.
Все из-за того, что:
Какой размер - это вам решать, так как это ваш протокол внутри TLS.
Это WebSocket API криптобиржи (в частности Bybit). Сообщения могут быть любой длины в Jason формате. Признаком конца сообщения является символ "}". Так что длина заранее неизвестна.
выставьте buffer_maxlen например в 16 кб и читайте блоками сколько отдадут.
Выше писал, что при выставлении значения больше, чем позиция первого символа с нулевым кодом (в данном случае > 1263), возвращает -1 и ошибку 5273. А заранее его позиция в дешифрованном сообщении неизвестна.
Вообще TLS категорически плохо подходит для шифрации low latency потоковых данных типа ценовых потоков или сделок.
Выше писал, что при выставлении значения больше, чем позиция первого символа с нулевым кодом (в данном случае > 1263), возвращает -1 и ошибку 5273. А заранее его позиция в дешифрованном сообщении неизвестна.
Проверю сегодня сам и отпишусь.
Проверил - у меня все работает с вебсокетами правильно.
Скорее всего у вас ошибка с передачей лишнего нулевого байта в SocketTlsSend, когда обычно строку перекодируют в uchar массив и забывают про конечный 0:
Тестовая заготовка приложена.
a)функция SocketTlsReadAvailable возвращает -1?
б)возникает ошибка 5273 после вызова SocketTlsReadAvailable?
Если код выполняется в конце сессии и сервер закрыл соединение, то на вашей стороне даже при возврате -1 и коде ошибки 5273 в приемный массив записываются остаточные данные (если они пришли и расшифровались).
Скорее всего у вас ошибка с передачей лишнего нулевого байта в SocketTlsSend, когда обычно строку перекодируют в uchar массив и забывают про конечный 0:
Пробовал разные варианты, даже посимвольное заполнение массива в цикле. Результат тот же. Но похоже дело в сервере конкретной биржи, т.к. другие биржи работают нормально.
Если код выполняется в конце сессии и сервер закрыл соединение, то на вашей стороне даже при возврате -1 и коде ошибки 5273 в приемный массив записываются остаточные данные (если они пришли и расшифровались).
Так и есть, но похоже с одной поправкой: если указываешь длину меньше сообщения, то ошибка не возвращается.
Проблема видимо с неправильным запросом для установки соединения:
Возвращает:
Может кто знает, что не так в запросе?