Вопросы, предложения и решения по API биржи BTC-E.COM

[alpet]

Собственно сабж, официальная справка мне показалась неполной. Да и общаться тем кто ботов пишет нужно где-то.
У меня вопрос пока такой: как получать заявки со статусами "matched" и "cancelled"? Это очень важно для очередного релиза моего торгового терминала Trade Studio.
А в плане предложений, очень хочется поскорее веб-сокеты Имхо реквестовый протокол ставит крест на очень многих торговых стратегиях требовательных к производительности.

Сам я могу разъяснить нюансы торговли через существующее API, посредством компонентов Indy для Delphi/C++ Builder.

[1713560159]

1713560159

[hazarun]

Было бы интересно почитать ответы на данную тему.
И задать вопросы, при случае.

[Sergauskazz]

Сам я могу разъяснить нюансы торговли через существующее API, посредством компонентов Indy для Delphi/C++ Builder.

можно подробней, что это за компоненты?

[alpet]

можно подробней, что это за компоненты?

TIdHttp это компонент позволяющий делать POST запрос, в том числе через SSL, что нам и требуется. Распространяется с открытым исходным кодом. Согласно устоявшемуся мнению это полный шлак в плане концепции и реализации, но я уже привык )
Для подписи сообщений легко можно использовать объект класса TIdHMACSHA512, причем это касается похоже всех криптовалютных бирж.

[XBOCT]

У меня вопрос пока такой: как получать заявки со статусами "matched" и "cancelled"?

Кажется, если покурить выхлоп метода TransHistory то можно понять какие были заявки и, что было matched, а что cancelled.

[alpet]

Кажется, если покурить выхлоп метода TransHistory то можно понять какие были заявки и, что было matched, а что cancelled.

У меня и так 3-4 запроса в секунду получается, что совсем не радует (на бирже FORTS можно десятки раз в секунду получать обновление данных).
Тут получается что надо для получения информации об заявках, нужно двойной запрос делать. Как-бы облако не забанило в итоге за излишнюю активность )
Потом, данный метод сложно использовать, непонятно каким образом к заявкам привязку делать.

[hazarun]

У меня и так 3-4 запроса в секунду получается, что совсем не радует (на бирже FORTS можно десятки раз в секунду получать обновление данных).

Есть ли смысл, в столь частых запросах, при условии, что данные на бирже кешируются раз в 2 секунды ?
Или уже не 2 секунды кеширования ?

[alpet]

Есть ли смысл, в столь частых запросах, при условии, что данные на бирже кешируются раз в 2 секунды ?
Или уже не 2 секунды кеширования ?

У меня разные запросы из разных ниток отправляются. Чтобы терминал хоть что-то отображал, надо постоянно синхронизировать котировки, заявки, сделки.

[hazarun]

У меня разные запросы из разных ниток отправляются.

Поясните, как отправление запросов из разных потоков (даже с разных компьютеров)
влияет на ситуацию с кэшированием стакана на бирже, (слышал про 2 секунды).

[alpet]

Поясните, как отправление запросов из разных потоков (даже с разных компьютеров)
влияет на ситуацию с кэшированием стакана на бирже, (слышал про 2 секунды).

С оценкой времени кэширования я не интересовался. Подозреваю, что облако тупо получает с торгового сервера данные каждые 2 секунды, и раздает их по запросам. У меня каждая нитка вроде имеет 1-секундный интервал опроса, что все-же желательно и даже при 2-секундной заморозке данных.

[hazarun]

С оценкой времени кэширования я не интересовался. Подозреваю, что облако тупо получает с торгового сервера данные каждые 2 секунды, и раздает их по запросам. У меня каждая нитка вроде имеет 1-секундный интервал опроса, что все-же желательно и даже при 2-секундной заморозке данных.

У меня примерно так же.
На 3 ТОП биржи совокупно запросы через 1500 - 2000 миллисекунд.
Хотя сам запросы выполняются гораздо быстрее. Опасаюсь уменьшать интервал опросов.

Заметим, самые медленное исполнение запроса по выдаче данных стакана у БТЦ-е.
Гокс и Штамп отдают данные (обычно) в десятки раз быстрее. Может что не так делаю ?

Как у Вас ?

[hazarun]

У меня разные запросы из разных ниток отправляются. Чтобы терминал хоть что-то отображал, надо постоянно синхронизировать котировки, заявки, сделки.

Потоки, запускаете по таймеру ?  Иль стоит еще какой метод глянуть ?

[alpet]

Как у Вас ?

Давно не делал замеров специальных, когда-то было и под 2-3 секунды. Тогда ещё ддосили жестко походу.

Потоки, запускаете по таймеру ?  Иль стоит еще какой метод глянуть ?

Просто запускаю подряд, у меня довольно изощренные наследники класса TThread. Каждый поток выполняет свою виртуальную машину Lua, и уже сценарии осуществляют запрос/парсинг данных. Так с некоторых пор сделал, чтобы легче было корректировать при изменениях API со стороны биржи, ну и пользователи программы смогут скрипты поправить чуть что.

[hazarun]

Давно не делал замеров специальных, когда-то было и под 2-3 секунды. Тогда ещё ддосили жестко походу.

Поставил вывод задержи при опросах на форму, сразу. Никакие замеры и не требуются. Наблюдаем в реальном времени.
Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.

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

[alpet]

Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.

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

Тут можно прояснить кое что. Задержка запроса, это время от начала отправки GET реквеста серверу,  до получения данных. Лаг данных, это отставание времени в данных полученных с биржи, относительно локального времени.
С лагом предполагается, что он может достигать при отсутствии прочих проблем, величины интервала опроса. Т.е. если опрашивать раз в 2 секунды, то лаг будет скорее всего более-менее Random от 0 до 2 секунд. Если опрашивать 10 раз в секунду, но минимальный лаг будет 100 мс каждые 2 секунды. Алгоритмически, если учитывать схему кэширования на стороне сервера - можно постоянно подбирать величину задержки, чтобы после получения данных лаг был минимальный. У меня в определенных местах этот подход используется, но под btc-e я его пока не стал прикручивать.

[XBOCT]

Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.

Правда не очень понял, что именно он там выводит.

В Qt Bitcoin Trader хоть оно и называется Lаg-ом, фактически выводится время прошедшее с последнего полученного ответа, а не время обработки запроса.

[hazarun]

Получается, мы имеем, как минимум 4 временных промежутка:

1. Период опроса.
2. Задержка исполнения запроса.
3. "server_time":1342123547   и локальное время, разница между ними.
4. Время прошедшее с момента прихода последнего ответа сервера.

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

[zulunation]

alpet В основе сбора данных лежат POST / GET запросы. Почему бы не использовать PHP для этого?
Lua выбрал из за компактности?

[IGHOR]

В Qt Bitcoin Trader хоть оно и называется Lаg-ом, фактически выводится время прошедшее с последнего полученного ответа, а не время обработки запроса.

Так было в первых версиях. Сейчас Soft Lag показывает время прошедшее с момента отправки до момента получения текущего пакета.

[alpet]

alpet В основе сбора данных лежат POST / GET запросы. Почему бы не использовать PHP для этого?
Lua выбрал из за компактности?

Lua выбрал давно из-за... STALKER, очень хорошо разобрался в этой штуке. Изначально в терминале были реализованы только скрипты для создания ботов на этом языке, но потом дошла очередь и до торговых API.
Да и очень хорошо в Delphi код VM подключается в виде DLL, думаю можно и 64-бита сделать сборки. Сейчас моя программа может подключаться сразу к нескольким биржам, и позволяет сделать даже арбитраж между ними (прообраз скрипт уже есть).