
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Мне бы стратегию разработать, подходящую для BTC.
Практически любая флетовая стратегия с ограничением по времени чтобы работала только в европейскую сессию.
История крипты там с bybit. Иначе какой был у них смысл? Другие инструменты меня не интересуют.
Если история совпадает, через API я получу её же.
Приветствую! С API работали уже? Какую-то библиотеку использовали?
Приветствую! С API работали уже? Какую-то библиотеку использовали?
Работаю с API нескольких бирж. Никаких библиотек, только хардкор, только WebRequest. Скорость пока позволяет применять синхронный WR. И пока не нужны стримы. При необходимости всё можно сделать.
Практически любая флетовая стратегия с ограничением по времени чтобы работала только в европейскую сессию.
Ну не знаю. BTC - самая волатильная, флет там гораздо меньше половины времени. Но эксперименты покажут. Пока они показывают строгую необходимость учитывать тренд. Возможно, во внутридневной торговле придёт к этому. А время учитывать да, обязательно.
Ну не знаю. BTC - самая волатильная, флет там гораздо меньше половины времени. Но эксперименты покажут. Пока они показывают строгую необходимость учитывать тренд. Возможно, во внутридневной торговле придёт к этому. А время учитывать да, обязательно.
ВТС в евро-сессию практически никогда не делает безоткатных движений, ждёт америку и там уже балуется. Да - это меньше половины времени, но надёжно.
Работаю с API нескольких бирж. Никаких библиотек, только хардкор, только WebRequest. Скорость пока позволяет применять синхронный WR. И пока не нужны стримы. При необходимости всё можно сделать.
А если цены брать с терминала, а торговые запросы через WebRequest? Но тут высказывали идею, что будут отличия...
Интересна надежная схема/алгоритм работы через АПИ, запрограммирую при необходимости сам.
Как часто запрашиваете цены и др данные? Раз в секунду? Чаще обычно не разрешают по АПИ.
А если цены брать с терминала, а торговые запросы через WebRequest? Но тут высказывали идею, что будут отличия...
Интересна надежная схема/алгоритм работы через АПИ, запрограммирую при необходимости сам.
На разные данные у них разные лимиты. На тяжёлые запросы реже, на обычные - гораздо чаще 1 сек. Все лимиты описаны, проще посмотреть, чем на пальцах объяснять.
Мне для моих целей нужно раз в секунду. А вообще для получения потока цен в реальном времени надо использовать WebSocket стримы.
Если полностью освоил АПИ, нет смысла брать цены с терминала для торговых запросов через АПИ. Цены с терминала нужны для отладки в тестере стратегии и индикаторов, а при работе эксперта - для работы индикаторов. Однако, если зондирование покажет, что цены совсем не отличаются, и в частном случае увеличенные по сравнению с биржевыми комиссии и свопы не сильно влияют на прибыльность конкретного эксперта, для простоты, в качестве неокончательного этапа, можно будет торговать через терминал традиционно.
Тут невозможно заранее продумать чёткую концепцию и реализовать сразу, и получать финансовые результаты в конце трудов. Так пропадает мотивация. Всё делается поэтапно, и потихоньку получая плюшки. У меня есть фраза "Совет желающим начать: начните".
Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).
Я считаю, что в области работы с АПИ бирж не стоит выкладывать готовые наработки. Лично я не зарабатываю на маркете, но нельзя лишать хлеба тех, кто да. Это действительно интеллектуальная работа, стоящая своих денег.
На разные данные у них разные лимиты. На тяжёлые запросы реже, на обычные - гораздо чаще 1 сек. Все лимиты описаны, проще посмотреть, чем на пальцах объяснять.
Мне для моих целей нужно раз в секунду. А вообще для получения потока цен в реальном времени надо использовать WebSocket стримы.
Если полностью освоил АПИ, нет смысла брать цены с терминала для торговых запросов через АПИ. Цены с терминала нужны для отладки в тестере стратегии и индикаторов, а при работе эксперта - для работы индикаторов. Однако, если зондирование покажет, что цены совсем не отличаются, и в частном случае увеличенные по сравнению с биржевыми комиссии и свопы не сильно влияют на прибыльность конкретного эксперта, для простоты, в качестве неокончательного этапа, можно будет торговать через терминал традиционно.
Тут невозможно заранее продумать чёткую концепцию и реализовать сразу, и получать финансовые результаты в конце трудов. Так пропадает мотивация. Всё делается поэтапно, и потихоньку получая плюшки. У меня есть фраза "Совет желающим начать: начните".
Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).
Я считаю, что в области работы с АПИ бирж не стоит выкладывать готовые наработки. Лично я не зарабатываю на маркете, но нельзя лишать хлеба тех, кто да. Это действительно интеллектуальная работа, стоящая своих денег.
Хочу сказать, что основная сложность в работе с АПИ - аутентификация запросов. Генерация подписи для каждого запроса шифрованием HMAC. Сразу не смог, сначала вызывал программу ssl с WinAPI. Потом научился использовать CryptEncode(CRYPT_HASH_SHA256).
а основной тормоз - парсинг и генерация json ..
имеющиеся в доступности библиотеки MQL тормозны и печальны, сводят в 0 все преимущества WebSocket. (это при том что и WS тут самоделка)
а основной тормоз - парсинг и генерация json ..
имеющиеся в доступности библиотеки MQL тормозны и печальны, сводят в 0 все преимущества WebSocket. (это при том что и WS тут самоделка)
Ну у меня запрос/ответ занимает порядка 100-200мс из 1000мс цикла. Для входящего потока с WS будет минус отправка запроса, минус обработка на сервере. Да и входящий пакет будет приходить асинхронно. Парсинг одного тика будет занимать мизерное время. Можно ещё уменьшить, сделав урезанную специальную версию json-парсера без универсализма. Ломать - не строить. Тут было уже 3 версии.