WebSocket даже в нормальных, быстрых и правильных реализациях довольно капризная штука. Её противопоказано делать на MQL
imho: или оно должно появится от разработчиков терминала или обеспечиваться внешними DLL
WebSocket даже в нормальных, быстрых и правильных реализациях довольно капризная штука. Её противопоказано делать на MQL
imho: или оно должно появится от разработчиков терминала или обеспечиваться внешними DLL
Чушь какая.
Вовсе не чушь относительно MQL. Тут с TLS как были проблемы (я о них писал на форуме, но решения не дождался), так и остались. Пример из статьи не работает. Лог я приложил к оригиналу английской статьи.
- 2020.11.25
- www.mql5.com
Чушь какая.
Там есть старая проблема wss: в штатной функции SocketIsReadable ()
Обходится элементарно, но уже без этой функции.
uint len = 1024; //SocketIsReadable(socket);
Там есть старая проблема wss: в штатной функции SocketIsReadable ()
Обходится элементарно, но уже без этой функции.
Есть какое-нибудь обоснование? Что за магическое число и почему оно подойдет для сообщения длиной 256 или 1500, например?
Там есть старая проблема wss: в штатной функции SocketIsReadable ()
Обходится элементарно, но уже без этой функции
Вы просто не понимаете и не умеете пользоваться этой функцией.
Эта функция моментально выдает доступное количество пришедших байт во входном буфере, а не говорит о том, что сокет живой. Функция очень важна и позволяет не уходить в синхронное ожидание, а вычитывать порционно данные, не теряя контроля над программой.
И TLS функции тоже правильные - они ведь даны для подготовленных пользователей, которые знают как и в какой последовательности ими пользоваться. Они не для тех, кто «вызвал и все».
Мало того, сокетные и tls функции в чистом виде те же самые, что использует терминал для raw/tls/https соединений терминал. То есть, все отлично работает. Эти же реализации работают в наших высоконагруженных решениях.
Сырые сетевые функции не для новичков и не для наивного использования. Надо достаточно хорошо понимать принципы и особенности сетевого взаимодействия. А если речь об TLS, то методы и последовательность обработки handshake процесса.Вы просто не понимаете и не умеете пользоваться этой функцией.
Эта функция моментально выдает доступное количество пришедших байт во входном буфере, а не говорит о том, что сокет живой. Функция очень важна и позволяет не уходить в синхронное ожидание, а вычитывать порционно данные, не теряя контроля над программой.
И TLS функции тоже правильные - они ведь даны для подготовленных пользователей, которые знают как и в какой последовательности ими пользоваться. Они не для тех, кто «вызвал и все».
Мало того, сокетные и tls функции в чистом виде те же самые, что использует терминал для raw/tls/https соединений терминал. То есть, все отлично работает. Эти же реализации работают в наших высоконагруженных решениях.
Сырые сетевые функции не для новичков и не для наивного использования. Надо достаточно хорошо понимать принципы и особенности сетевого взаимодействия. А если речь об TLS, то методы и последовательность обработки handshake процесса.Эта функция не имеет параметра буфера. О каком входном буфере речь?
Не знаю о каком понимании вы говорите и для каких юзеров, эту ошибку нашёл Ильяс и вроде принял за ошибку.
В том то и дело, что все пользователи ориентируются на примеры из документации для сокетов.
А продвинутые пользователи пишут спецификацию протокола, и апргрейды и разбор фрейма всё это понимаем.
Проблема в том, что функция SocketIsReadable(socket) не понятно что возвращает, для wss: фрейма.
- www.mql5.com
Есть какое-нибудь обоснование? Что за магическое число и почему оно подойдет для сообщения длиной 256 или 1500, например?
Обоснование? Да фиг его знает. С числом в переменной, читает без проблем. Длина выставлена на примерный максимальный размер входящего фрейма.
Можно и по максимуму поставить, не на что не влияет.
string CWs::Recv() { uchar rsp[]; //, res[]; string result = ""; //uint timeout_check = GetTickCount() + timeout; //do //{ uint len = 65536; //SocketIsReadable(socket); //if(len) //{ int rsp_len = SocketTlsReadAvailable(socket, rsp, len); //if(rsp_len > 0) //{ //ArrayInsert(res, rsp, ArraySize(res), 0); //break; //} //} //} //while(GetTickCount() < timeout_check && !IsStopped()); if(rsp_len > 0) //(ArraySize(res) > 0) result = Unpack(rsp, ArraySize(rsp)); return(result); }
А с функцией SocketIsReadable(socket) сам знаешь, что читает с ошибкой.
То что возвращает SocketIsReadable(socket) в len, не подходит в SocketTlsRead() и SocketTlsReadAvailable()
- www.mql5.com
Эта функция не имеет параметра буфера. О каком входном буфере речь?
Не знаю о каком понимании вы говорите и для каких юзеров, эту ошибку нашёл Ильяс и вроде принял за ошибку.
В том то и дело, что все пользователи ориентируются на примеры из документации для сокетов.
А продвинутые пользователи пишут спецификацию протокола, и апргрейды и разбор фрейма всё это понимаем.
Проблема в том, что функция SocketIsReadable(socket) не понятно что возвращает, для wss: фрейма.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья WebSocket для MetaTrader 5:
До появления сетевых функций в обновленном MQL5 API, приложения MetaTrader были ограничены в возможности подключаться и взаимодействовать с сервисами на основе протокола WebSocket. Сейчас ситуация изменилась. В этой статье мы рассмотрим реализацию библиотеки WebSocket на чистом MQL5. Будут представлены краткое описание протокола WebSocket и пошаговое руководство по использованию полученной библиотеки.
Ниже представлено видео программы, работающей при подключении к серверу.
Автор: Francis Dube