Обмен данными с MT5. Многопотоковый Socket-сервер в виде dll.

[yu-sha]

Есть красивый ответ на вопрос "Как обмениваться данными с MT5" - это Socket-сервер. 

В dll засовываем серверную часть.

На стороне клиента работает, соответственно, клиентская часть.

Обработчик запросов пишется на MQL5.

Уже все сделано - РАБОТАЕТ! Сейчас идут тесты на прочность/производительность.

MT5 прекрасно справляется с многопотоковой схемой организации сервера в dll.

Код обработчика запросов (добавляет ОК к тексту запроса)))

#import "MT5DataServerDll.dll"
  bool StartServer (string host, string port);
  bool StopServer ();
  int  GetQuery (string& s);
  int  AddReplay (string s);
#import

void Init() {
  bool a=StartServer("localhost","8765");
  if (a) Print("Server started");
}

void Deinit(const int reason) {
  bool a=StopServer();
  if (a) Print("Server stoped");
}

void OnStart() 
{
  Init();
  string s;
  StringInit(s,1024,0);
  while (!IsStopped()) {
    GetQuery(s); 
    if (StringLen(s)>0) {
      AddReplay(s+" OK");
      StringInit(s,1024,0);
    }
    Sleep(100);
  }
  Deinit(0);
}

 А вот сеанс одновременной игры (на стороне сервера каждая часть обрабатывается в своем потоке)

 

 

 И не надо никаких "односторонних" DDE

Главное, чтобы клиентская программа могла открывать TCP-сокет и писать/читать в/из него 

[Alexander]

Отлично! Спасибо.

Интересуют тесты на производительность - сколько тиков в секунду может передавать? 

Может оформите статью? 

[yu-sha]

GarF1eld:

Отлично! Спасибо.

Интересуют тесты на производительность - сколько тиков в секунду может передавать? 

Может оформите статью? 

Задача не в передаче тиков, а в ответах на запросы

Скажем, запрашиваешь EURUSD CLOSE 2010-01-21 12:00 H1

Получаешь в ответ  1.4050

"Язык" запросов и ответов формируем на свое усмотрение

Можно запросить значение любого индикатора по любому символу, можно удаленно вызвать любую функцию MQL5

Скорость невелика - на моем стареньком одноядерном ноуте обрабатывалось 50-100 запросов в секунду

Не стоит забывать, что вся передача идет в текстовом виде. Т.е. производительность можно улучшить в разы - в этом я не сомневаюсь

Для меня была важна сама идея - возможность управлять терминалом удаленно , своего рода RPC для MQL5 

[Alexander]

Хороший результат.

Попадет ли библиотека в комьюнити?

[yu-sha]

GarF1eld:

Хороший результат.

Попадет ли библиотека в комьюнити?

Не вопрос - сам пользуюсь наработками других людей, поэтому выложить библиотеку не составит труда

В каком виде - вот вопрос

На данный момент все очень сырое

Для решения своих частных задач этого достаточно, для того чтобы выложить "для других" - явно недостаточно

Если будет интерес со стороны посетителей форума, приведу в надлежащий вид, опишу и выложу

[pisara]

Этот вариант МТ5 "сервера" подходит для создания более сложных систем с "головой" вне МТ5 терминала. Напимер, подзаливка кеширующихся в МТ5 терминале котировок во внешнюю базу данных, и/или синхронное управление торгами по разным брокерам.

Однако, при создании автономной ТС, может потребоваться реверс направления: советник захочет данные извне, и будет являться, по сути, клиентом, т.е. начинать связь. Это даёт возможность свободнее проходить через NAT firewall (так, вероятно, построены агенты тестера). Скажем, запрос динамического ключа разрешения торговли, сопоставление котировок с не МТ-шным брокером и т.п.

Короче, возможность инициализации связи с любого конца могла бы дать такой библиотеке весьма неплохую перспективу развития.

[yu-sha]

pisara:

Этот вариант МТ5 "сервера" подходит для создания более сложных систем с "головой" вне МТ5 терминала. Напимер, подзаливка кеширующихся в МТ5 терминале котировок во внешнюю базу данных, и/или синхронное управление торгами по разным брокерам.

Однако, при создании автономной ТС, может потребоваться реверс направления: советник захочет данные извне, и будет являться, по сути, клиентом, т.е. начинать связь. Это даёт возможность свободнее проходить через NAT firewall (так, вероятно, построены агенты тестера). Скажем, запрос динамического ключа разрешения торговли, сопоставление котировок с не МТ-шным брокером и т.п.

Короче, возможность инициализации связи с любого конца могла бы дать такой библиотеке весьма неплохую перспективу развития.

Клиентская часть строится за 5 минут

Не нужны:

- учет клиентов

- синхронизация запросов

- синхронизация потоков

- и т.д. и т.п. 

В клиентской части 95% нагрузки приходится на парсинг ответа сервера, из оставшихся 5% половина времени уйдет на стыковку Unicode String )))))) До сих пор не пойму ЗАЧЕМ в аскетичной программерской среде нужны двухбайтовые string ??? 

[pisara]

yu-sha: ... До сих пор не пойму ЗАЧЕМ в аскетичной программерской среде нужны двухбайтовые string ???

Наверно к этому сильно привыкли, кому-то просто не охота экономить... Для передачи больших масс однородных данных неплохо бы передавать нечто поприличнее string-мешанины в несколько гигов :))  (типа "как хочешь так Это и читай"), например стандартные массивы котировок/буферов индюков и структы (Pascal/Delphi records).

[yu-sha]

Допускаю, что я "залип" в delphi-стереотипах s[i] - это i-ый символ/байт string'a

Но как же это было удобно! )) И на этапе отладки - посмотрел в Watch и все понятно, не нужно "натягивать" всяко-разно structure

Эх, молодежжжь 

[Renat Fatkhullin]

yu-sha:

До сих пор не пойму ЗАЧЕМ в аскетичной программерской среде нужны двухбайтовые string ??? 

Многие удивляются, когда выясняется, что за пределами их страны существует огромный мультиязычный мир, которому не подходит мультибайтовая вакханалия.

Китайцы хотят видеть свой текст как есть в любой части программы, японцы хотят писать названия торговых символов иероглифами, а европейцы желают видеть эти символы в оригинале, а не в виде "ЖоLtrsjkhd".

Но для упрощения работы с мультибайтовыми строками мы в очередных билдах включим тип строк cstring со штатными функциями перекодировки в любые кодировки.

[pisara]

Renat:

Многие удивляются, когда выясняется, что за пределами их страны существует огромный мультиязычный мир, которому не подходит мультибайтовая вакханалия.

Китайцы хотят видеть свой текст как есть в любой части программы, японцы хотят писать названия торговых символов иероглифами, а европейцы желают видеть эти символы в оригинале, а не в виде "ЖоLtrsjkhd".

Но для упрощения работы с мультибайтовыми строками мы в очередных билдах включим тип строк cstring со штатными функциями перекодировки в любые кодировки.

Зачем что-то включать, когда всё это давно реализовано? Сколько ещё обёрток вам предстоит навертеть, не лучше было бы дать прямой доступ к нормальной среде разработки, которую не надо разрешать спец. wrapper-ами, и потом отлавливать в них глюки и нестыковочки? Каков к.п.д. всего этого??