Ошибки, баги, вопросы - страница 2706
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
В том то и проблема, что для вкладки Errors в ME журнала нет.
Моя невнимательность...
что за код 556?
30 графиков с экспертом, при компиляции часть не восстановилась с этим кодом, другая - успешно.
что за код 556?
30 графиков с экспертом, при компиляции часть не восстановилась с этим кодом, другая - успешно.
Ошибка открытия файла dip.ex5
Покажите полный лог, а не кусок скриншота
Ошибка открытия файла dip.ex5
Покажите полный лог, а не кусок скриншота
см. вложение
Кто-нибудь может подсказать, как подружить TLS-сокеты с эхо-сервером? Взял исходник из примера, допилил заголовки. На порту 80 делает апгрейд, а на 443 - коннектится, получает сертификат, но потом ничего не может прочитать из заголовков. Если выполнять под отладчиком, видно что SocketIsReadable возвращает похожее на правду число, типа 245, но SocketTlsRead по таймауту отваливается, ничего не возвращая. Видимо, требуются сакральные знания от MQ.
Баг МЕ (build 2380) некорректная сигнатура шаблонного параметра функции в Error Description и Parameter info.
Кто-нибудь может подсказать, как подружить TLS-сокеты с эхо-сервером? Взял исходник из примера, допилил заголовки. На порту 80 делает апгрейд, а на 443 - коннектится, получает сертификат, но потом ничего не может прочитать из заголовков. Если выполнять под отладчиком, видно что SocketIsReadable возвращает похожее на правду число, типа 245, но SocketTlsRead по таймауту отваливается, ничего не возвращая. Видимо, требуются сакральные знания от MQ.
У меня тоже не получилось получить байтовый массив ответа с помощью HTTPRecv, для дальнейшего разбора протокола.
Отваливается по таймауту, потому что не организован ping pong, но чтоб его организовать нужно сперва получить байтовый ответ от сервера, да и сама функция HTTPRecv содержит таймаут.
Но почему то HTTPRecv не парсит этот байтовый ответ.
У меня тоже не получилось получить байтовый массив ответа с помощью HTTPRecv, для дальнейшего разбора протокола.
Отваливается по таймауту, потому что не организован ping pong, но чтоб его организовать нужно сперва получить байтовый ответ от сервера, да и сама функция HTTPRecv содержит таймаут.
Но почему то HTTPRecv не парсит этот байтовый ответ.
Это только самое подключение. Там еще нет никакого пин-понга - он может случиться потом в протоколе вебсокетов. Затык происходит на ответном заголовке сервера, когда он должен подтвердить апгрейд. Когда не используется TLS, подключается нормально. Но и с TLS, суда по всему заголовок в терминал приходит, но не возвращается из SocketTlsRead.
Это только самое подключение. Там еще нет никакого пин-понга - он может случиться потом в протоколе вебсокетов. Затык происходит на ответном заголовке сервера, когда он должен подтвердить апгрейд. Когда не используется TLS, подключается нормально. Но и с TLS, суда по всему заголовок в терминал приходит, но не возвращается из SocketTlsRead.
Ага, понял о чём речь.
Да действительно в вашем коде, на 80 порт заголовок возвращается, на 443 нет.
Пересмотрел ваш код ещё раз, и не увидел там функцию SocketTlsHandshake.
Ваш код не производит рукопожатия. Возможно в этом дело.
Хотя в справке к этой функции говорится, что она не обязательна, если коннект идёт на 443 порт.
Странно в общем.
UPD:
Как не составлял заголовок запроса, всё равно приходит ошибка
или
Может разработчик запретил получение апгрейда на TLS?
UPD:
С вашим заголовком ошибок нет, но и заголовка ответа нет.
В функции HTTPRecv поставил принт, чтоб посмотреть что вообще приходит
Принтует только один символ H
По символу можно предположить, что это первая буква заголовка ответа,
остальное содержимое заголовка почему то не выводит.
Уважаемые разработчики, подскажите как быть?
Это намеренное ограничение, или всё таки ошибка в TLS ?
Просто тоже давно бьюсь с этой проблемой, и безуспешно.