Обмен данными между двумя советниками, работающими в разных терминалах

 

Данная ветка является техническим продолжением ветки "NFA запрещает локирование с 15 мая 2009"

В частности начиная вот с этого поста:

'NFA запрещает локирование с 15 мая 2009'

solandr 26.04.2009 12:06

2. Разбить имеющийся счёт у американского брокера на 2 отдельных счёта с равным объёмом средств. На одном счёте все позиции по всем инструментам будут только BUY, а на другом счёте все позиции по всем инструментам будут только SELL. Это не нарушает этого правила о запрете хеджирования на одном счёте, так как счетов у нас 2. Далее нужно разработать метод каким образом сделки от единственного эксперта рассовывать по этим 2м разным счетам. Поскольку раньше такой задачи передо мной не стояло, то хотелось бы узнать какие методы существуют для чёткого исполнения ордеров одного эксперта на 2х разных счетах?

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

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

То есть каждому из советников нужно иметь полную информацию об ордерах из другого терминала. Как это организовать?

Очень прошу обсуждать в этоуй ветке лишь технические детали. Заранее благодарю!

 
Все технические детали, как и реализация алгоритма уже давно описаны. Поиск используйте.
 
HIDDEN >>:
Все технические детали, как и реализация алгоритма уже давно описаны. Поиск используйте.

Имеется в виду вот эта статья или же что-то другое?

'Автоматизированный выбор ДЦ для эффективной работы экспертов'

 

Для вашей задачи использование инструментария, описанного в статье про автоматизированный отбор ДЦ - это из пушки по воробью стрелять. Без всяких dll одними файлами сможете обойтись.

 

Использование одним из терминалов sqllite3 подсказывает что это один из самых простых путей.

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

Тогда обычными функциями получим доступ к чтению более структурированой информации...

Например сейчас провести анализ логов на предмет скажем оценки качества открытия позиций совсем нетривиальная задача.

*

Сорри если не в тему...

*

Уж если пошла речь о БД, то ищу способы, которые кстати пригодятся и при обмене между счетами,

как записывать и считывать одни и теже ячейки базы?

То есть, для своих целей заводим таблицу exch, и в ней поля, назовём условно А, В, С, Д, с одним рядом.

Схематично так:


А
В
С
Д
данные
123
1.2548
12.04.2009
бай
 
solandr >>:

Данная ветка является техническим продолжением ветки "NFA запрещает локирование с 15 мая 2009"

В частности начиная вот с этого поста:

'NFA запрещает локирование с 15 мая 2009'

solandr 26.04.2009 12:06

2. Разбить имеющийся счёт у американского брокера на 2 отдельных счёта с равным объёмом средств. На одном счёте все позиции по всем инструментам будут только BUY, а на другом счёте все позиции по всем инструментам будут только SELL. Это не нарушает этого правила о запрете хеджирования на одном счёте, так как счетов у нас 2. Далее нужно разработать метод каким образом сделки от единственного эксперта рассовывать по этим 2м разным счетам. Поскольку раньше такой задачи передо мной не стояло, то хотелось бы узнать какие методы существуют для чёткого исполнения ордеров одного эксперта на 2х разных счетах?

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

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

То есть каждому из советников нужно иметь полную информацию об ордерах из другого терминала. Как это организовать?

Очень прошу обсуждать в этоуй ветке лишь технические детали. Заранее благодарю!

как идея вариантов несколько

1-файловый обмен

2-можно использовать различные методы событий windows

3-передача по TCP/IP


с точки зрения сложности, файловый обмен проще


с файловым обменом надо аккуратно

обращение к одному файлу разными программами должно грамотно разделяться

в любом случае нужно хорошо представлять как работает совместный доступ к файлам

 
kombat >>:


Уж если пошла речь о mysql, то ищу способы, которые кстати пригодятся и при обмене между счетами,

как записывать и считывать одни и теже ячейки базы?


Элементарно, Ватсон. Через SQL запросы.

 
Reshetov >>:

Элементарно, Ватсон. Через SQL запросы.

Спасибо Холмс! ;)))

проблема лишь в том как это осуществить...

Мне например до сих пор не поддалась эта задача.

(правда и работаю над ней от случая к случаю)

*

Если серьёзно, то проблема составить запрос чтения\записи по конкретным координатам таблицы.

 
kombat >>:

Спасибо Холмс! ;)))

проблема лишь в том как это осуществить...

Мне например до сих пор не поддалась эта задача.

(правда и работаю над ней от случая к случаю)

*

Если серьёзно, то проблема составить запрос чтения\записи по конкретным координатам таблицы.


через SQL тоже можно

есть одна токость неприятная ... как два советнка узнают что надо лезть в SQL что бы обменятся

прийдется писать монитор в обоих экспертах который будет с квантом времени лазить в SQL что бы узнать не "написал" ли чего "товарищь"

аналогично с файловым обменом ! там тоже прийдется мучаться - и лазить в файл с каждым квантом времени

а не изменилось ли что то, не сообщил ли "друг торгующий на другом счете" чего то


--

с точки зрения экономии ресурсов и в общем то грамотней и лучше сделать через событие

событие возникло пинаем!

не возникло не пинаем

т е у каждого эксперта может возникнуть "позыв" сообщить другу о своих намерениях

это и будет событие... которым он и пнет спящего друга

windows событийная операционка - в общем лучше в этом направлении двигаться

--

 

Мне в принципе через равные кванты времени более чем достаточно проводить проверку/запись файла.

По поводу доступа к файлам мне тут коллега по работе подсказал такую идею. Пока пишем в файл называем его как-нибудь file.running. Как только закончили писать в него, то переименовываем его в file.output. После чтения файла вторым советником удаляем файл. Таким образом даём понять первому советнику что можно записать новый файл с передаваемой информацией на следующем цикле работы первого советника (через заданный квант времени). Возможно для надёжности разделения доступа можно было бы применять какие-то файлы-флаги.


Я видел некоторые примеры использования передачи информации через TCP/IP когда идёт передача данных через локальный хост 127.0.0.1 с каким-либо портом. Каждый из советников знает порт другого и передаёт данные в него, также параллельно производится прослушка своего порта на предмет перехвата данных от другого советника. У меня есть пример осуществления такой работы на VB script. Только вот не знаю как это можно переделать для применения в советнике.

Есть ли какие-то уже готовые примеры для передачи данных через TCP/IP для советников?

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