Блог им. facevalue

Мост NinjaTrader -> OEC Trader

Господа кодеры, прошу идейного совета, но с практическими направлениями. Есть задача портировать генерируемые стратегией в NT трейды на OEC Trader. Т.к. я сишарплю, а парни за стенкой ноудджиесят, получить у них качественный совет не получилось.

Текущее решение сделано в режиме хелоуворлда — пишем генерируемые трейды StreamWriter'ом в ТХТ, потом слушаем ТХТ файл FileSystemWatcher'ом и торгуем в ОЕС.

Когда работает одна стратежка, то все выглядит чин-чин, но ессно когда одновременно работают 2+ стратежки, то при вызове StreamWriter по концу часа несколькими идеями код матерится (файл блаблабла занят другим процессом). Делать многопоточный кастыль для передачи трейдов через ТХТ? Мне кажется это некошерно… Смотрю в сторону WCF… Но там не нашел применимых примеров. Там только калькуляторы, которые я не могу в мозгу перевернуть в то, что мне нужно.

Так вот вопрос — абстрагируясь от NT и ОЕС (они умеют обычный C# без проблем), что лучше выбрать для решения задачи? Если аргументы в пользу ТХТ+Thread, то я готов подвинуться религией. Если в сторону WCF, то пните в нормальный пример. Не калькулятор, а где через службу одна прога отправляет что-то как команду, а вторая прога глотает как команду.

Есть вариант через базу данных, но как «слушать» БД? Timer?

PS Прошу, если что, кодерам с вопросов не ржать. Просто пните правильно, я умею быстро плавать. )

PPS Спросили в личке «Зачем такие сложности». Объясню. В NT есть частный рукописный индюк, который на моем уровне сложно портировать в  ОЕС (там синхронизация потоков и прочая высшая математика, к которой я не готов). Вот этот индюк используется для генераций трейдов. Под NT я все написал чЬОтенько, работает как правительство Германии часы. Все тоже самое сделать под ОЕС нет смысла, проще сменить платформу и брокера. Но частный случай требует частного решения — трейдить в ОЕС полученную идею. Поэтому требуется Solution.sln )))

★2
25 комментариев
«Просто пните правильно, я умею быстро плавать.»

+ интересно сказано
avatar
копайте в сторону pipe (именованные и анонимные каналы).
avento (О.К.), А можно ссылку какую-то? Буду должен. UPDATE: это вроде больше про UNIX… В Вики написано, что форточка тоже поддерживает, но было бы коленнопреклонно полезно увидеть пример. Желательно с биржевой семантикой.
avatar
facevalue, когда-то давно из любопытства изучал (ну или пытался изучать) код то ли арбитражера, то ли копировщика сделок. Актуальной ссылки нет, но мне запомнилось там довольно изящное в своей простоте использование именованных каналов для обмена информацией между различными терминалами. Это похоже на работу с файлами, только без задержек и взаимных блокировок.

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

avento (О.К.), Спасибо за пример! Первый к изучению.
ПС Никогда не думал, что передавать инфу из проги в прогу такая сложность. )
avatar
facevalue, для c# кстати есть вот такие примерчики, возможно с ними тема прояснится чуть лучше:

— кусок из лекции по программированию
пример на msdn

Посижу тоже послушаю. Софт такой не использую, но ход мысли и решение тоже будет интересно послушать.
avatar

WCF — оверкилл для данной задачи, хотя проблему и решит

еще варианты (чем выше в списке, тем более адекватный на мой взгляд)
1)quick&dirty оставить все как есть, но использовать файлик на рамдиске (к примеру, https://www.softperfect.com/products/ramdisk/). Все станет работать шустрее, и ошибки станут реже. Если писать в цикле, пока не запишет, используя try catch, может быть и ок

2)использовать шаред мемори, к примеру https://sharedmemory.codeplex.com/

3)использовать zmq

4)читальщик сделать на простеньком веб сервере типа http://nancyfx.org/ писать в него пост запросами

5)использовать WebApi2 или Owin

6)если все таки БД, то in-memory базы вроде redis, aerospike должны зайти ок, их можно опрашивать с очень большой частотой, но это оверкилл тоже

7)использовать сокеты (TcpClient, TcpListener)

8)использовать полноценную очередь сообщений (не zmq)

для сериализации вне зависимости от варианта 1-7 можно использовать protobuf-net (если надо бороться за доли миллисекунд), или Newtonsoft.Json (если надо удобно отлаживать)

avatar
Lafert, Первый скорее всего не подойдет, трейды пушаться с точностью миллисекунд. try/catch тоже скорее всего не решит проблему одновременности, разве что через кастыль обработки ошибок, но это ж кастыль… Остальные завтра рассмотрю. Кстати, веб-запросы это же SQL. Тот же БД получается. Я ошибаюсь?
avatar

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

Нет, веб-запросы, это не SQL, гуглите GET, POST

avatar
Lafert, Кстати, пока что из всего (бегло просмотрев) хорошо описан в сети именно WCF. Ну и SQL — общение через БД. Вроде решает вопрос «многозапросности». Чувствую копать придется туда. Сокеты, как мне только что сказали, требуют отдельной подготовки, очередь сообщений говорят тот же малтиThread. Вы бы что выбрали для реализации, если бы скилл был на года два «ниже»? )
avatar
facevalue, наверное, заказал бы проект у фрилансера с условием, что он объяснит код)
avatar
Lafert, Можно маленький вопросик, а почему сокеты на седьмом месте? На мой взгляд второе по оптимальности решение после named pipes.
avatar

Dzam, потому, что zmq превосходит сокеты 

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

avatar
Lafert, Так как ZeroMQ это обертка на те же сокеты, то вряд ли они будут быстрее работать. Разве что только в каких то специфических условиях. Что касается удобства тут действительно проще работать чем с «оригинальными».
avatar
Dzam, там кроме tcp/ip еще есть inproc и ipc, то есть, в рамках одной машины можно быстрее, чем сокеты. Хотя, сам не проверял перфоманс, и не уверен, что все это добро под виндой работает.
avatar
Посмотрите в сторону серверов сообщений, реализаций — масса, в том числе кроссплатформенные и под Windows. Использовал в бою Gearman, Redis, RabbitMQ, ActiveMQ. Первые два — наиболее легковесные по ресурсам.

avatar
Lev, Коллега выше упомянул этот вариант, но если бы кто-то из вас мог дать ссылку на приближенный к биржевой теме пример, я был бы безмерно благодарен. 
avatar
facevalue, биржевых нет, увы (я из web).
Посмотрите примеры, может так понятнее станет сама идеология.
avatar
Lev, БЛИН! Кажется, это то что нужно. По крайней мере, читаю и понимаю. СПАСИБО! С меня граппа. )
avatar
Lev, 
Биржевые примеры
An easy to use .NET API for RabbitMQ
github.com/MerlinBrasil/EasyNetQ

Examples to work with Metatrader 4 (MT4 build >= 500) and RabbitMQ.
github.com/femtotrader/rabbit4mt4
avatar
named pipes, sockets (все есть под Windows)
ТС, если это сложно, то может программировать Вам кажется, что умеете?)
пару универсальных сотен строк кода для обеих сторон в виде библиотеки на уровне лабораторной работы универа
а не использовать какие-то сторонние инструменты, тем более такие монструозные как RabbitMQ или SQL
avatar
cfree0185, Я кодирую непрофессионально, о чем не скрываю. Учусь, но делаю это быстро. Проблема в том, что очень много общих знаний, которые без практики ессно применить сложно. Примеров биржевой реализации вообще как кот наплакал. «пару универсальных сотен строк кода для обеих сторон в виде библиотеки на уровне лабораторной работы универа» — пример сможете показать такой лабораторки? Если есть простое негромоздкое решение, то было бы не круто, но очень удобно. Заранее благодарен
avatar
Вы говорите: «по итогу часа».
Правильно я понимаю, что торговля ведется на часовике и решение принимается по закрытию часа?
avatar
gib, 15М или часовик, верно
avatar

теги блога facevalue

....все тэги



UPDONW
Новый дизайн