Связка MQL4 + .Net

 

Интересует такая интерпретация, есть бизнес-логика на дот нет(.NET) и нужно получать данные с метатрейдера, а так же делать на нем ставки


как это можно реализовать?

 
JTOne >>:

Интересует такая интерпретация, есть бизнес-логика на дот нет(.NET) и нужно получать данные с метатрейдера, а так же делать на нем ставки


как это можно реализовать?

У меня реализовано, сделал через named pipes

Структура такая:

MT<->dll<->nimed pipe channel<->.NET program

На МТ сидит простенький советник, который с интервалом в 200 мс постоянно гонит тики по всем парам, на стороне .NET это дело анализируется на изменения и пишется в историю тиков.

Также советник принимает сообщения с торговыми приказами, дешифрует их и исполняет. 

Вся информация между МТ и .NET передается в спец-формате. Заложена возможность торговать с нескольких счетов.

Сделана связь между .NET & MATLAB.

Что еще.. dll написана на С++, дотнет на шарпе.

А в чем проблемы-то собственно? 

 
JTOne >>:

Интересует такая интерпретация, есть бизнес-логика на дот нет(.NET) и нужно получать данные с метатрейдера, а так же делать на нем ставки


как это можно реализовать?

У меня реализировано через длл. Проблема будет с дебаггингом. Поиск ипользовать пробовали?

 

Проблема с отладкой решается очень просто - не надо делать ошибок :)))

А если серьезно, я длл отлаживал в тестовом приложении и только потом подключал к МТ.

 

MT<->dll<->nimed pipe channel<->.NET program


dll<->nimed pipe channel<->.NET program - тут все понятно


MT<->dll - что это за длл такая? Эта какая то сборка дот нета? тогда зачем делать аж так dll<->nimed pipe channel<->.NET program


Можно кусочек кода, примера работы с длл, или ссылочку какую то!

 
JTOne >>:

Можно кусочек кода, примера работы с длл, или ссылочку какую то!

Присоединяюсь к просьбе!

 
JTOne >>:

MT<->dll - что это за длл такая? Эта какая то сборка дот нета?


написали, что dll написана на c++. поэтому связь через Named Pipes

 
GarF1eld >>:

написали, что dll написана на c++. поэтому связь через Named Pipes

Совершенно верно, МТ может работать тошько с DLL, написанной на С/С++. НО!!! эта DLL может быть написана с использованием .NET!! 

Главное требование со стороны МТ к длл - соблюдение формата вызова функций и передачи параметров в стандарте С/С++.

С++ длл может использовать классы из дотнет, для этого надо всего лишь в свойствах проекта указать версию фреймворка, который будет использоваться. 

Длл на С# напрямую с МТ работать не будет, помешает маршаллинг при вызове функций. 

Но никто не мешает написать длл-обертку лдя вызовов на С++ и основную длл на С#, которая будет грузиться из С++ длл. Ну это если вам С++ совсем не люб :)

Далее, нам надо связать программу на дотнете с этой длл, я использовал пайпы, примеры в мсдн, ничего сложного.


Можно использовать shared memory, memory mapped files, sockets etc. Для memory mapped придется придумать протокол обмена, ибо mm file для вас будет рассматриваться

как массив с произвольным доступом. 

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

Теперь больной вопрос о ссылках. Ребята, вы ж понимаете, эта информация сугубо секретная, о ней знаю тока я и гугл (запрос http://www.google.com/search?client=opera&rls=ru&q=named+pipes+.NET&sourceid=opera&ie=utf-8&oe=utf-8 ) :)))

Так что если вы прочитаете эти ссылки, нам с гуглом придется вас убить :))) 

http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c7259/

http://www.codeguru.com/csharp/.net/net_general/patterns/article.php/c7261

Пример работы с длл есть в МТ, смотри в папке \experts\samples\DLLSample


О безвозмездной передаче "кусочков кода". 

Я пишу программу на продажу и не могу выкладывать какие-либо части, сорри, это часть Trader Assistant.

 
VDev писал(а) >>

Совершенно верно, МТ может работать тошько с DLL, написанной на С/С++. НО!!! эта DLL может быть написана с использованием .NET!!

...

Я пишу программу на продажу и не могу выкладывать какие-либо части, сорри, это часть Trader Assistant.

Все верно, и даже много проще чем Вы сделали... Во первых нинужны никакие пайпы, в арсенале нета, есть возможность межпроцессного взаимодействия, причем даже между разными машинами... Достаточно сделать маршалинг, и вызов методов класса, при этом если имплементация класса находится не в данном процессе то вызов методов класса все равно будет... :)

Как грится - учите мат.часть... Но это не Вам, лично...

Вот только скоро выдет пятерка MQL и надобность подобных извратов вроде как отпадет... :) Но когда он выдет... хз

 
LProgrammer >>:

Все верно, и даже много проще чем Вы сделали... Во первых нинужны никакие пайпы, в арсенале нета, есть возможность межпроцессного взаимодействия, причем даже между разными машинами... Достаточно сделать маршалинг, и вызов методов класса, при этом если имплементация класса находится не в данном процессе то вызов методов класса все равно будет... :)

Как грится - учите мат.часть... Но это не Вам, лично...

Вот только скоро выдет пятерка MQL и надобность подобных извратов вроде как отпадет... :) Но когда он выдет... хз

Это Вы про WCF, я так понимаю? Да, это сняло бы проблему с парсингом байтовых сообщений по пайпу. Я использовал пайпы просто для скорости разработки, WCF только еще изучаю ))

Да и не требуется особого интеллекта от этого канала связи, все равно 90% кода сидит в парсинге сообщений на стороне МТ... у меня зубы сводит от этого недоязыка))

Лирическое отступление - работал в нескольких крупных (одна ОЧЕНЬ) иностранных компаниях, производящих процы для различных областей применения.

Ни в одной не пытались делать свой компилятор С (даже просто С, не С++), везде использовали порты GCC (да, я знаю, что он С++), иногда заказные порты от коммерческих компилеров.

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

Уточню, эти компиляторы использовались в области embedded, то есть на разных платформах, от ARM до процов собственной разработки. И я четко знаю, что GCC в умелых руках + оптимизирующий ассемблер генерит великолепно оптимизированный код даже для DSP, выполняющую до 7 операций за такт. Ято я о гибкости старых технологий. Что же касается .NET, который мне откровенно симпатичен, тут вообще ничего не надо придумывать, встраваем компилятор в терминал за 5 минут и наслаждаемся.

Неа...русские идут своим путем... пусть убого, зато свое. Да, сам терминал мне нравится, устойчив и надежен на 5, удобен на 3. Но этот язык встроенный... язык программируемого калькулятора(

И меня удивляют люди, ждущие чуда от MQL5. Чуда не будет. Бедные ежики и дальше будут плакать и колоться, но продолжать юзать кактус.

Мой прогноз - при таком подходе МТ4 через пару лет уйдет в небытие, природа не терпит пустоты, достаточно сильной команды при мощной финансовой поддержке, чтобы за пару лет столкнуть убогого на обочину. 

Эк меня занесло))) Это я синтаксическую ошибку 20 минут в mql редакторе ловил, как обычно, убогий указывал пальцем в небо

 

 
VDev писал(а) >>

Это Вы про WCF, я так понимаю? Да, это сняло бы проблему с парсингом байтовых сообщений по пайпу. Я использовал пайпы просто для скорости разработки, WCF только еще изучаю ))

Да и не требуется особого интеллекта от этого канала связи, все равно 90% кода сидит в парсинге сообщений на стороне МТ... у меня зубы сводит от этого недоязыка))

Лирическое отступление - работал в нескольких крупных (одна ОЧЕНЬ) иностранных компаниях, производящих процы для различных областей применения.

Ни в одной не пытались делать свой компилятор С (даже просто С, не С++), везде использовали порты GCC (да, я знаю, что он С++), иногда заказные порты от коммерческих компилеров.

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

Уточню, эти компиляторы использовались в области embedded, то есть на разных платформах, от ARM до процов собственной разработки. И я четко знаю, что GCC в умелых руках + оптимизирующий ассемблер генерит великолепно оптимизированный код даже для DSP, выполняющую до 7 операций за такт. Ято я о гибкости старых технологий. Что же касается .NET, который мне откровенно симпатичен, тут вообще ничего не надо придумывать, встраваем компилятор в терминал за 5 минут и наслаждаемся.

Неа...русские идут своим путем... пусть убого, зато свое. Да, сам терминал мне нравится, устойчив и надежен на 5, удобен на 3. Но этот язык встроенный... язык программируемого калькулятора(

И меня удивляют люди, ждущие чуда от MQL5. Чуда не будет. Бедные ежики и дальше будут плакать и колоться, но продолжать юзать кактус.

Мой прогноз - при таком подходе МТ4 через пару лет уйдет в небытие, природа не терпит пустоты, достаточно сильной команды при мощной финансовой поддержке, чтобы за пару лет столкнуть убогого на обочину.

Эк меня занесло))) Это я синтаксическую ошибку 20 минут в mql редакторе ловил, как обычно, убогий указывал пальцем в небо

Вы знаете, вы немного не правы - если внимательно присмотреться то MQL это просто си. Его компилятор даже делать не надо. Я вот тут собрался делать оптимизатор советников, и решил пока отложить - подождать MQL5 ... Но пока раздумывал - понял, что MQL совершенно в легкую ложиться в си, просто на уровне препроцессора ... И библиотек. И это очень правильно. Ну сделалали они свой компилятор но язык-то СИ.

Причина обращения: