Нужна помощь в тестировании API

[Indacoin]

Всем привет,
Недавно запустили апи на нашем сайте, нужно тестить.
Предлагаю следующее - вы тестите апи, пишете развернутый отзыв в главную тему, а мы в свою очередь компенсируем вам комиссию до 0,1 BTC (любую комиссию, в том числе для ввода/вывода любым из способов)
Предложение действительно для пользователей этого форума, зарегистривовавшихся до сегодняшнего дня.
После регистрации сразу напишите в службу поддержки что помогаете в тесте АПИ, комиссия возмещается после написания отзыва само собой.
инфо по api https://indacoin.com/api
Заранее спасибо!

[rPman]

забыли добавить получение истории торгов в API

Пока вы только развиваетесь, у вас еще есть время передумать о методах публикации информации по ордерам трейдерам - https://bitcointalk.org/index.php?topic=638536.msg7177890#msg7177890
p.s. Для примера, за 6 суток, скрипты сбора данных с некоторых торговых (depth и trades) бирж нагенирировали трафика (это еще в щадящем режиме):

Code:

total: 23.872g speed:51.193kb/s btc-e.com:2362.6m www.okcoin.cn:317.4m pubapi.cryptsy.com:10947.1m api.bitfinex.com:5672.8m api.kraken.com:991.1m www.bitstamp.net:2383.3m goc.io:1198.0m
Собранная информация хранится в виде diff-ов (собственный текстовый формат, далекий от оптимального), за сутки набирая 70мб-логи (т.е. в 60 раз меньше загружаемых данных).

т.е. это один трейдер способен так нагрузить ваш сервер, а если их будут сотни? тысячи? это ведь дорогой anti-ddos трафик! Не говоря о том что трейдеры, как бы часто они не опрашивали биржу тупыми push запросами, своевременной информации все равно не получают!

Некоторые биржи вводят http-push нотификацию и даже websocket, но публикуемая этими методами информация сильно ограничена (например bitstamp выдает только 20 ближайших ордеров к рынку, а cryptsy вообще не выдает информации по стакану, только сообщения о торгах).

Может быть вы сделаете как все надо?

[rPman]

Вы наверное не прочитали ничего.
Я предложил РЕШЕНИЕ, которое способно решить проблемы с трафиком для биржи и доступностью и оперативностью информации для трейдеров.

Проблема в том, что нужная трейдеру информация в готовом виде - это текущее состояние по списку отложенных ордеров (depth) и история торгов (trades)

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

В случае с trades, некоторые биржи предоставляют возможность указать в запросе время (чаще это science в виде timestamp) начиная с которого необходимо вывести список торгов. Этого более чем достаточно, чтобы минимизировать трафик для биржи, но такие запросы все равно генерируют нагрузку на сервер (но не фатальную)

Сложнее с depth - чем популярнее биржа, тем больше записей в этом запросе (bitstamp - например 400кб), некоторые биржи ограничивают этот список по количеству ордеров (btc-e  например 150 в обе стороны) ближайших к рынку. Возможно кто то посчитает это достаточным, но не я...

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

Но самое правильный метод, я описал в том посте - просто публикуйте события изменения в depth (события создания отложенных ордеров, события их частичного исполнения и отмены) и торговые события (записи trades). Публиковать эту информацию лучше всего (проще) с помощью websocket, но и http push метод тоже терпимый.
А для того, чтобы у клиентов, после временного разрыва связи или отключения, не было 'дыр' в логе этих событий, при подключении выдавать их историю начиная с указанного момента времени.

Чтобы разгрузить основной сервер, от запросов слишком старых данных, можно выдавать эти дампы в виде статических файлов, за период (часы/сутки/месяцы), трейдеры, последовательными запросами данных за большие и малые интерваллы, смогут загрузить данные обо всех событиях на бирже. Дополнительнок этим данным можно так же раздавать классический дамп depth в виде списка ордеров, но не на любой момент времени, а например раз в сутки... используя их и данные лога событий с момента после времени создания этих дампов, позволят трейдерам быстро досчитать состояние depth на любой момент времени.
При этом, раздача этих данных на сервере очень легко горизонтально масштабируется уже давно отточенными технологиями (это обычная статика, имена файлов содержат тип/размер и время начала интервала)

Почему оперативность предоставления данных так важна? Это важно не только для трейдеров (некоторые стратегии строятся на скорости и оперативности), но следовательно и для биржи, ведь чем чаще трейдер торгует, тем больше доход у биржи, выше ликвидность, и соответственно по кругу - это привлекательно для трейдеров.

И еще, не забывайте снабжать все дампы и записи лога временными метками, и не жадничайте, пользуйтесь microtime(true) для выдачи точного времени с микросекундами. Не забывайте про сервисы точного времени (linux - ntpd), так как многие хостеры, чаще VPS-ки, об этом забывают, и время на сервере убегает от реальности на десятки секунд...

[Indacoin]

забыли добавить получение истории торгов в API

Пока вы только развиваетесь, у вас еще есть время передумать о методах публикации информации по ордерам трейдерам - https://bitcointalk.org/index.php?topic=638536.msg7177890#msg7177890
p.s. Для примера, за 6 суток, скрипты сбора данных с некоторых торговых (depth и trades) бирж нагенирировали трафика (это еще в щадящем режиме):

Code:

total: 23.872g speed:51.193kb/s btc-e.com:2362.6m www.okcoin.cn:317.4m pubapi.cryptsy.com:10947.1m api.bitfinex.com:5672.8m api.kraken.com:991.1m www.bitstamp.net:2383.3m goc.io:1198.0m
Собранная информация хранится в виде diff-ов (собственный текстовый формат, далекий от оптимального), за сутки набирая 70мб-логи (т.е. в 60 раз меньше загружаемых данных).

т.е. это один трейдер способен так нагрузить ваш сервер, а если их будут сотни? тысячи? это ведь дорогой anti-ddos трафик! Не говоря о том что трейдеры, как бы часто они не опрашивали биржу тупыми push запросами, своевременной информации все равно не получают!

Некоторые биржи вводят http-push нотификацию и даже websocket, но публикуемая этими методами информация сильно ограничена (например bitstamp выдает только 20 ближайших ордеров к рынку, а cryptsy вообще не выдает информации по стакану, только сообщения о торгах).

Может быть вы сделаете как все надо?

Историю торгов недавно добавили, можете ознакомиться с нашими новыми функциями на сайте.
Мы планируем представить push-notification в публичном доступе, единственное, мы пока не думали об оповещении изменений в целом стакане, а не только в его видимой части.
Вы можете нам объяснить, для чего требуется выкладывать логи по полному стакану? Какие действия трейдеры совершают с логами?

[rPman]

Необходимость в полном стакане - не столь важна, но проблема в определении границ, до какого расстояния от текущей биржи трейдер готов строить свои стратегии.. bitstamp думает что трейдерам хватит и 20 записей, btc-e - 300, mtgox выкладывали все (но не предоставляли возможность догрузить пропущенные записи, и отсутствовали тайминги в depth дампах, что не позволяло тчоно восстановить стакан на момент времени)... я считаю, пусть трейдеры сами решают, до каких пределов собирать данные.

Что именно могут трейдеры получить из стакана? Например анализ поведения других трейдеров, попытки предсказания путем выявления принадлежности отложенных ордеров отдельным трейдерам (по размерам ордеров и последним торговым операциям, к примеру, делая предположение что трейдер вычисляет объем ордера исходя из % объма средств на депозите), так же возможет статистический анализ, численной оценки качества ликвидности биржи на момент времени, на основе скорости наполения стакана, например после больших торговых операций.

Приведу аналогию - попытка оценить и предсказать поведение трейдеров на бирже (я про алготрейдинг) только по истории trades (а некоторые считают что им хватает агрегированных свечек min/max/open/close/volume) это как попытка представить, что из себя представляет тропинка, пользуясь исключительно следами людей, идущих по ней. Так вот информация по стакану, в данной аналогии, это не только собственно сама тропинка, но и следы вокруг нее (как пешеходы срывают листья окружающих ее кустов, оставляют следы от рук на бордюрах и т.п.) по этим следам не только можно сделать точную картину дороги, но и о весе/росте/поведении пешеходов.

p.s. о чем я говорил выше, вот пример лога (один из тестов, разрабатываемой сейчас мною Fast Trades биржи, до HFT боюсь мне не дотянуть )
https://docs.google.com/document/d/1SLgBTQXvdP2LmDCb3Hv7_qOkyCjUVoGwoZV-76CL7fU/edit
формат сообщений еще не причесан, черным цветом выделил - события trades, серым - depth

[icreator]

не в тему
вы на чем морду сайта сделали?

я подобный дизайн хочу - посоветуете к кому обратиться?

[hazarun]

Необходимость в полном стакане - не столь важна, но проблема в определении границ, до какого расстояния от текущей биржи трейдер готов строить свои стратегии.. bitstamp думает что трейдерам хватит и 20 записей,
btc-e - 300,
mtgox выкладывали все

Внесу уточнения. БТЦ-е сейчас дает возможность трейдеру решать,
сколько записей в стакане и сколько стаканов требовать в запросе.

Очень простое и экономичное решение. Один запрос = все стаканы, скажем по 5 ближних ордеров.
Работает быстрее чем  выдается  ОДИН стакан, но с тысячей ордеров. Столько обычно и не нужно.

В АПИ 2 у БТЦ-е да, надо было требовать стаканы отдельными запросами.
Глубину стакана они сразу дали регулировать трейдеру.
А потом добавили в АПИ 3 вывод стаканов по списку в запросе.