Bybit MT5 - страница 4

 
Edgar Akhmadeev #:
Мне бы стратегию разработать, подходящую для BTC.

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

 
Edgar Akhmadeev #:

История крипты там с bybit. Иначе какой был у них смысл? Другие инструменты меня не интересуют.

Если история совпадает, через API я получу её же.

Приветствую! С API работали уже? Какую-то библиотеку использовали?

 
Dmitriy Skub #:

Приветствую! С API работали уже? Какую-то библиотеку использовали?

Работаю с API нескольких бирж. Никаких библиотек, только хардкор, только WebRequest. Скорость пока позволяет применять синхронный WR. И пока не нужны стримы. При необходимости всё можно сделать.

 
moskitman #:

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

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

 
Edgar Akhmadeev #:

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

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

 
Edgar Akhmadeev #:

Работаю с API нескольких бирж. Никаких библиотек, только хардкор, только WebRequest. Скорость пока позволяет применять синхронный WR. И пока не нужны стримы. При необходимости всё можно сделать.

Как часто запрашиваете цены и др данные? Раз в секунду? Чаще обычно не разрешают по АПИ.

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

Интересна надежная схема/алгоритм работы через АПИ, запрограммирую при необходимости сам.
 
Forester #:
Как часто запрашиваете цены и др данные? Раз в секунду? Чаще обычно не разрешают по АПИ.

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

Интересна надежная схема/алгоритм работы через АПИ, запрограммирую при необходимости сам.

На разные данные у них разные лимиты. На тяжёлые запросы реже, на обычные - гораздо чаще 1 сек. Все лимиты описаны, проще посмотреть, чем на пальцах объяснять.

Мне для моих целей нужно раз в секунду. А вообще для получения потока цен в реальном времени надо использовать WebSocket стримы.

Если полностью освоил АПИ, нет смысла брать цены с терминала для торговых запросов через АПИ. Цены с терминала нужны для отладки в тестере стратегии и индикаторов, а при работе эксперта - для работы индикаторов. Однако, если зондирование покажет, что цены совсем не отличаются, и в частном случае увеличенные по сравнению с биржевыми комиссии и свопы не сильно влияют на прибыльность конкретного эксперта, для простоты, в качестве неокончательного этапа, можно будет торговать через терминал традиционно.

Тут невозможно заранее продумать чёткую концепцию и реализовать сразу, и получать финансовые результаты в конце трудов. Так пропадает мотивация. Всё делается поэтапно, и потихоньку получая плюшки. У меня есть фраза "Совет желающим начать: начните".

Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).

Я считаю, что в области работы с АПИ бирж не стоит выкладывать готовые наработки. Лично я не зарабатываю на маркете, но нельзя лишать хлеба тех, кто да. Это действительно интеллектуальная работа, стоящая своих денег.

 
Edgar Akhmadeev #:

На разные данные у них разные лимиты. На тяжёлые запросы реже, на обычные - гораздо чаще 1 сек. Все лимиты описаны, проще посмотреть, чем на пальцах объяснять.

Мне для моих целей нужно раз в секунду. А вообще для получения потока цен в реальном времени надо использовать WebSocket стримы.

Если полностью освоил АПИ, нет смысла брать цены с терминала для торговых запросов через АПИ. Цены с терминала нужны для отладки в тестере стратегии и индикаторов, а при работе эксперта - для работы индикаторов. Однако, если зондирование покажет, что цены совсем не отличаются, и в частном случае увеличенные по сравнению с биржевыми комиссии и свопы не сильно влияют на прибыльность конкретного эксперта, для простоты, в качестве неокончательного этапа, можно будет торговать через терминал традиционно.

Тут невозможно заранее продумать чёткую концепцию и реализовать сразу, и получать финансовые результаты в конце трудов. Так пропадает мотивация. Всё делается поэтапно, и потихоньку получая плюшки. У меня есть фраза "Совет желающим начать: начните".

Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).

Я считаю, что в области работы с АПИ бирж не стоит выкладывать готовые наработки. Лично я не зарабатываю на маркете, но нельзя лишать хлеба тех, кто да. Это действительно интеллектуальная работа, стоящая своих денег.

Спасибо за информацию. С АПИ для сайтов работал, на PHP ключи несложно делаются, для терминала еще нет. Про сложности в терминале, только сейчас понял. Буду знать чем пользоваться, если займусь этим вопросом.
 
Edgar Akhmadeev #:

Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).


а основной тормоз - парсинг и генерация json ..

имеющиеся в доступности библиотеки MQL тормозны и печальны, сводят в 0 все преимущества WebSocket. (это при том что и WS тут самоделка)

 
Maxim Kuznetsov #:

а основной тормоз - парсинг и генерация json ..

имеющиеся в доступности библиотеки MQL тормозны и печальны, сводят в 0 все преимущества WebSocket. (это при том что и WS тут самоделка)

Ну у меня запрос/ответ занимает порядка 100-200мс из 1000мс цикла. Для входящего потока с WS будет минус отправка запроса, минус обработка на сервере. Да и входящий пакет будет приходить асинхронно. Парсинг одного тика будет занимать мизерное время. Можно ещё уменьшить, сделав урезанную специальную версию json-парсера без универсализма. Ломать - не строить. Тут было уже 3 версии.