alpet В основе сбора данных лежат POST / GET запросы. Почему бы не использовать PHP для этого?
Lua выбрал из за компактности?
Topic: Вопросы, предложения и решения по API биржи BTC-E.COM - page 3. (Read 6294 times)
Получается, мы имеем, как минимум 4 временных промежутка:
1. Период опроса.
2. Задержка исполнения запроса.
3. "server_time":1342123547 и локальное время, разница между ними.
4. Время прошедшее с момента прихода последнего ответа сервера.
Надо как то определиться, что бы при беседе была однозначность у собеседников , о чем именно одет речь.
1. Период опроса.
2. Задержка исполнения запроса.
3. "server_time":1342123547 и локальное время, разница между ними.
4. Время прошедшее с момента прихода последнего ответа сервера.
Надо как то определиться, что бы при беседе была однозначность у собеседников , о чем именно одет речь.
Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.
Правда не очень понял, что именно он там выводит.
В Qt Bitcoin Trader хоть оно и называется Lаg-ом, фактически выводится время прошедшее с последнего полученного ответа, а не время обработки запроса. Правда не очень понял, что именно он там выводит.
Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.
Правда не очень понял, что именно он там выводит.
Данные эти в наших терминалах , даже близко не совпадают. Остальное все совпадает.
Тут можно прояснить кое что. Задержка запроса, это время от начала отправки GET реквеста серверу, до получения данных. Лаг данных, это отставание времени в данных полученных с биржи, относительно локального времени. Правда не очень понял, что именно он там выводит.
Данные эти в наших терминалах , даже близко не совпадают. Остальное все совпадает.
С лагом предполагается, что он может достигать при отсутствии прочих проблем, величины интервала опроса. Т.е. если опрашивать раз в 2 секунды, то лаг будет скорее всего более-менее Random от 0 до 2 секунд. Если опрашивать 10 раз в секунду, но минимальный лаг будет 100 мс каждые 2 секунды. Алгоритмически, если учитывать схему кэширования на стороне сервера - можно постоянно подбирать величину задержки, чтобы после получения данных лаг был минимальный. У меня в определенных местах этот подход используется, но под btc-e я его пока не стал прикручивать.
Давно не делал замеров специальных, когда-то было и под 2-3 секунды. Тогда ещё ддосили жестко походу.
Поставил вывод задержи при опросах на форму, сразу. Никакие замеры и не требуются. Наблюдаем в реальном времени.
Коллега, автор Qt Bitcoin Trader, тоже выводит лаги на форму, на постоянку.
Правда не очень понял, что именно он там выводит.
Данные эти в наших терминалах , даже близко не совпадают. Остальное все совпадает.
Как у Вас ?
Давно не делал замеров специальных, когда-то было и под 2-3 секунды. Тогда ещё ддосили жестко походу. Потоки, запускаете по таймеру ? Иль стоит еще какой метод глянуть ?
Просто запускаю подряд, у меня довольно изощренные наследники класса TThread. Каждый поток выполняет свою виртуальную машину Lua, и уже сценарии осуществляют запрос/парсинг данных. Так с некоторых пор сделал, чтобы легче было корректировать при изменениях API со стороны биржи, ну и пользователи программы смогут скрипты поправить чуть что. У меня разные запросы из разных ниток отправляются. Чтобы терминал хоть что-то отображал, надо постоянно синхронизировать котировки, заявки, сделки.
Потоки, запускаете по таймеру ? Иль стоит еще какой метод глянуть ?
С оценкой времени кэширования я не интересовался. Подозреваю, что облако тупо получает с торгового сервера данные каждые 2 секунды, и раздает их по запросам. У меня каждая нитка вроде имеет 1-секундный интервал опроса, что все-же желательно и даже при 2-секундной заморозке данных.
У меня примерно так же.
На 3 ТОП биржи совокупно запросы через 1500 - 2000 миллисекунд.
Хотя сам запросы выполняются гораздо быстрее. Опасаюсь уменьшать интервал опросов.
Заметим, самые медленное исполнение запроса по выдаче данных стакана у БТЦ-е.
Гокс и Штамп отдают данные (обычно) в десятки раз быстрее. Может что не так делаю ?
Как у Вас ?
Поясните, как отправление запросов из разных потоков (даже с разных компьютеров)
влияет на ситуацию с кэшированием стакана на бирже, (слышал про 2 секунды).
С оценкой времени кэширования я не интересовался. Подозреваю, что облако тупо получает с торгового сервера данные каждые 2 секунды, и раздает их по запросам. У меня каждая нитка вроде имеет 1-секундный интервал опроса, что все-же желательно и даже при 2-секундной заморозке данных. влияет на ситуацию с кэшированием стакана на бирже, (слышал про 2 секунды).
У меня разные запросы из разных ниток отправляются.
Поясните, как отправление запросов из разных потоков (даже с разных компьютеров)
влияет на ситуацию с кэшированием стакана на бирже, (слышал про 2 секунды).
Есть ли смысл, в столь частых запросах, при условии, что данные на бирже кешируются раз в 2 секунды ?
Или уже не 2 секунды кеширования ?
У меня разные запросы из разных ниток отправляются. Чтобы терминал хоть что-то отображал, надо постоянно синхронизировать котировки, заявки, сделки. Или уже не 2 секунды кеширования ?
У меня и так 3-4 запроса в секунду получается, что совсем не радует (на бирже FORTS можно десятки раз в секунду получать обновление данных).
Есть ли смысл, в столь частых запросах, при условии, что данные на бирже кешируются раз в 2 секунды ?
Или уже не 2 секунды кеширования ?
Кажется, если покурить выхлоп метода TransHistory то можно понять какие были заявки и, что было matched, а что cancelled.
У меня и так 3-4 запроса в секунду получается, что совсем не радует (на бирже FORTS можно десятки раз в секунду получать обновление данных). Тут получается что надо для получения информации об заявках, нужно двойной запрос делать. Как-бы облако не забанило в итоге за излишнюю активность )
Потом, данный метод сложно использовать, непонятно каким образом к заявкам привязку делать.
У меня вопрос пока такой: как получать заявки со статусами "matched" и "cancelled"?
Кажется, если покурить выхлоп метода TransHistory то можно понять какие были заявки и, что было matched, а что cancelled. можно подробней, что это за компоненты?
TIdHttp это компонент позволяющий делать POST запрос, в том числе через SSL, что нам и требуется. Распространяется с открытым исходным кодом. Согласно устоявшемуся мнению это полный шлак в плане концепции и реализации, но я уже привык )Для подписи сообщений легко можно использовать объект класса TIdHMACSHA512, причем это касается похоже всех криптовалютных бирж.
Сам я могу разъяснить нюансы торговли через существующее API, посредством компонентов Indy для Delphi/C++ Builder.
можно подробней, что это за компоненты?
Было бы интересно почитать ответы на данную тему.
И задать вопросы, при случае.
И задать вопросы, при случае.
Собственно сабж, официальная справка мне показалась неполной. Да и общаться тем кто ботов пишет нужно где-то.
У меня вопрос пока такой: как получать заявки со статусами "matched" и "cancelled"? Это очень важно для очередного релиза моего торгового терминала Trade Studio.
А в плане предложений, очень хочется поскорее веб-сокеты
Имхо реквестовый протокол ставит крест на очень многих торговых стратегиях требовательных к производительности.
Сам я могу разъяснить нюансы торговли через существующее API, посредством компонентов Indy для Delphi/C++ Builder.
У меня вопрос пока такой: как получать заявки со статусами "matched" и "cancelled"? Это очень важно для очередного релиза моего торгового терминала Trade Studio.
А в плане предложений, очень хочется поскорее веб-сокеты
Имхо реквестовый протокол ставит крест на очень многих торговых стратегиях требовательных к производительности. Сам я могу разъяснить нюансы торговли через существующее API, посредством компонентов Indy для Delphi/C++ Builder.
Jump to: