Синхронность выставления/отмены заявок
Atom Ответить
30.01.2012


В Альфе API при подаче/отмене заявок есть параметр timeout.

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


Сейчас в качестве значения передается -1 и далее слушаются обновления таблицы ордеров, чтобы выловить id по комметарию, в котором записан transaction id.

Мне эта схема не особо нравится, т.к. потенциально возникает ряд проблем, например, при котировании.

Вопросы к публике - имеет ли смысл сделать выставление ордеров синхронным (т.е. ждать пока ордер выставится)? имеет ли смысл сделать опцию в коннекторе для выбора режима (либо синхронный, либо асинхронный, т.е. как сейча) ?

Теги:


Спасибо:



Скидка 15% на все продукты до 5 апреля (осталось 3 дней).

6 Ответов
seashaman

Фотография
Дата: 30.01.2012
Ответить


Sergey Masyura Перейти
В Альфе API при подаче/отмене заявок есть параметр timeout.

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


Сейчас в качестве значения передается -1 и далее слушаются обновления таблицы ордеров, чтобы выловить id по комметарию, в котором записан transaction id.

Мне эта схема не особо нравится, т.к. потенциально возникает ряд проблем, например, при котировании.

Вопросы к публике - имеет ли смысл сделать выставление ордеров синхронным (т.е. ждать пока ордер выставится)? имеет ли смысл сделать опцию в коннекторе для выбора режима (либо синхронный, либо асинхронный, т.е. как сейча) ?

меня глюк двойного ордера(второй пропадет без ответа и привета) вынудил это место обвесить горой своих проверок, которые реализуют гарантированный возврат статуса ордера с некоторым ожиданием. В своей реализации коннектора(не S#) делал ордера с некоторым тайм аутом, проблем не возникало.
Вообще если не сложно, то я за галку )

PS Немного не в тему, но глюк CandleManager с альфовским коннектором, для меня лично, создает больше потенциальных проблем чем синхронность-асинхронность ордеров
Спасибо:

Sergey Masyura

Фотография
Автор статей
Дата: 31.01.2012
Ответить


Цитата:

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


В Альфе свой механизм свечек, у трейдера надо регистрировать свечки и будут приходить события о начале/изменении/завершении свечки. Что за глюк с CandleManager, можно описание?
Автор топика
Спасибо:

seashaman

Фотография
Дата: 31.01.2012
Ответить


Sergey Masyura Перейти
Цитата:

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


В Альфе свой механизм свечек, у трейдера надо регистрировать свечки и будут приходить события о начале/изменении/завершении свечки. Что за глюк с CandleManager, можно описание?

копипастю свои записи из топика пожеланий:
Ковыряюсь в процессах, меня терзают смутные сомнения что ошибка в самом коннекторе, событие ProcessHistoryCandles отрабатывается отлично, и свечки, которых не видно в кандле менеджере стратегии, успешно проходят через CandlesChanged.SafeInvoke(token, new [] {candle}); Куда они дальше идут я не вижу, но есть подозрение что это место сбоит. Можно предположить что по неким причинам в хранилище складываются только свечки с последнего секьюрити. Причем первую свечку успешно выдаем всем, а вот следующую только последнему секьюрити зарегестрированному.

Все-ж CandleManager неправильно выбирает свечки из коннектора.

trader.CandlesFinished += (t, candlesLocal) =>
{
...
// вот это НЕ работает
var candles = candleManager.GetTimeFrameCandles(strategy.Security, timeFrame, bounds);

// это работает
var candles2 = trader.GetLocalHistoryData(strategy.Security, timeFrame, bounds);
....
}
Выход сейчас один, напрямую по событию конца свечи скармливать в стратегию напрямую данные, в обход кэндле-менеджера. Надеюсь баг локализован окончательно и не заживется долго )
Спасибо:

Sergey Masyura

Фотография
Автор статей
Дата: 31.01.2012
Ответить


seashaman Перейти
Sergey Masyura Перейти
Цитата:

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


В Альфе свой механизм свечек, у трейдера надо регистрировать свечки и будут приходить события о начале/изменении/завершении свечки. Что за глюк с CandleManager, можно описание?

копипастю свои записи из топика пожеланий:
Ковыряюсь в процессах, меня терзают смутные сомнения что ошибка в самом коннекторе, событие ProcessHistoryCandles отрабатывается отлично, и свечки, которых не видно в кандле менеджере стратегии, успешно проходят через CandlesChanged.SafeInvoke(token, new [] {candle}); Куда они дальше идут я не вижу, но есть подозрение что это место сбоит. Можно предположить что по неким причинам в хранилище складываются только свечки с последнего секьюрити. Причем первую свечку успешно выдаем всем, а вот следующую только последнему секьюрити зарегестрированному.

Все-ж CandleManager неправильно выбирает свечки из коннектора.

trader.CandlesFinished += (t, candlesLocal) =>
{
...
// вот это НЕ работает
var candles = candleManager.GetTimeFrameCandles(strategy.Security, timeFrame, bounds);

// это работает
var candles2 = trader.GetLocalHistoryData(strategy.Security, timeFrame, bounds);
....
}
Выход сейчас один, напрямую по событию конца свечи скармливать в стратегию напрямую данные, в обход кэндле-менеджера. Надеюсь баг локализован окончательно и не заживется долго )


CandleManager не имеет ничего общего с реализацией механизма получения свечек через альфа-трейдер - понятно, что GetTimeFrameCandles не будет работать при этом.
Автор топика
Спасибо:

seashaman

Фотография
Дата: 01.02.2012
Ответить


Sergey Masyura Перейти

CandleManager не имеет ничего общего с реализацией механизма получения свечек через альфа-трейдер - понятно, что GetTimeFrameCandles не будет работать при этом.

Ну да. Эмпирически в итоге я вывел что проблема в CandleManager(изначально то не было понятно почему null в ответе вместо свечей). Причем ошибка возникает когда присутствует несколько секьюрити. Сейчас у меня стратегия берет свечки напрямую с АД через trader.GetLocalHistoryData. Метод часто дающий сбои(Иногда он не дает свечей посреди рабочей сессии). Очень хотелось бы нормально формировать свечи с поступающих заявок кэндле менеджером и не мучаться.
Спасибо:

OvcharenkoVI

Фотография
Автор статей
Дата: 01.02.2012
Ответить


А я вообще не использую GetLocalHistoryData. Просто регистрирую токен и с событий Trader.CandlesStarted/Changed/Finished посылаю свечи в метод, где они обрабатываются
Спасибо:


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy