на мой взгляд тёмные тона - жалкая подъ..бка под QT-интерфейс. И более того, - от тёмных тонов - устают глаза. А для трейдера, особенно если он часто сидит за монитором - это основное.
Николай Камынин написал: Информация о тиках одна и та же для обоих колбеков.
как-то уже упоминалось, что получение данных с помощью createdatasource - идёт отдельным запросом на сервер. Возможно это было сделано для того, чтоб разгрузить и разделить очереди сообщений с сервера. А если так - то, опять же, получается, - что раньше сработает onaalltrade или createdatasource- , будет зависеть от ещё более многих факторов: от того - насколько занята очередь основных данных для основных коллбеков и от того - как быстро обработает запрос на получение инфы по createdatasource - сервер.
____________
я думаю, нет смысла обсуждать этот вопрос - "ЧТО быстрее". Нам остаётся лишь оптимизировать свои алгоритмы таким образом, - чтоб минимизировать возможныенегативные последствия - т.е. убрать фактор очерёдности. вообще же, - как уже говорил - нет смысла писать и пользоваться стандартными коллбеками на QLUA - это слишком низкоуровневые операции. Есть смысл абстрагироваться от всего этого - но, для этого, придётся писать свой торговый движок (или как сейчас модно говорить - Framework) - и... уже потом, и на него и под него - писать плагины/скрипты на LUA. Как-раз именно этим - и занимаюсь.
bondar написал: Всё зависит от долгосрочных намерений камрада, если цель – просто попробовать в принципе как на автомате улетают приказы по случайному алгоритму(болинж, машка….), то конечно нет смысла изучать С#\С++\Java
lua даже в сервера встраивают и в маршрутизаторы и причём уже - довольно часто. Бо как просто, быстро и эффективно.
bondar написал: Lua не позволяет выйти за пределы Quik, например получить дынные из другого источника данных, приложения или веб страницы
хто тебе енто сказал??)))) делай свою библиотеку на LUA C API. И будет тебе щасье))) уже были примеры и на этом и на других форумах, как с помощью LUA и библиотек к ней - можно: слать алерты хоть по аське, хоть по мылу создавать свои мини сервера брать/передавать инфу на http и прочие сервера.
Лень искать? гугл в помощь.
_______________________________
p.s. правильно. изучать LUA C API и программирование на C++ в частности - это тебе на в тапки с..рать на шарпах. Зато отдача потом - всё окупит.
Николай Камынин написал: Таким образом, будут ли эти функции вызываться в разных потоках или в одном не имеет значение. Вопрос лишь в том в какой последовательности они вызываются.
вот только всё дело в том, что потоки могут выбыть приостановлены и вызваны в любой момент на усмотрение планировщика. Всё зависит от их текущих приоритетов. И даже, если он у них - одинаковый - то, вовсе не значит, что первым - выдаст колбек именно тот поток, который, как Вам кажется должен.
поясняю: возможно... есть 2 потока: главный поток квика и обработка коллбека OnAllTrade и.. возможно, ещё один поток cratedatasource
таким образом, вы никогда не узнаете и не сможете гарантировать, какой из них быстрее сработает и обработает долгожданный коллбек. Бо как помимо потоков - есть ещё и системный планировщик, а также целас система (ОС), которая всё переиграет так - как ей это будет нужно - в данный момент
более того, также известно, что все эти ваши QLUA-коллбеки - работают в основном потоке терминала. т.е. опросив все QLUA-коллбеки всех скриптов - идёт обработка главной очереди сообщений главного потока.
единственное чисто событийное - это немаскируемое прерывание процессора и переход по соответствующему вектору, а всё остальное - все "эти ваши" потоки - всё это завуалированная работа с теми же циклами.
СОП можно также определить как способ построения компьютерной программы, при котором в коде (как правило, в головной функции программы) явным образом выделяется главный цикл приложения, тело которого состоит из двух частей: выборки события и обработки события.
Николай Камынин написал: Во-вторых, в колбеке CreateDataSource
могу ошибаться, конечно (не работаю с CreateDataSource ввиду его "сырости") - под него, если не изменяет память (читал где-то) - заводится отдельный поток ОС. Поэтому - сравнивать его с OnAllTrade - было бы неверно.
тот самый написал: показывает наиболее загруженные IP брокера и предлагает переподключиться на другой канал.
Как это выглядит? мониторинг загрузки серверов на стороне брокера? Если так, то наверное это единственный надежный способ. Все остальные способы дают оценку некоторых несвязанных между собой параметров.
я не могу Вам сказать, как это выглядит. Исходного кода - у меня нет...)) Дело в том, что это предстартовая проверка: т.е. сначала проверяешь - потом - запускаешь. А надо - динамическую проверку. Я уже предлагал до этого: в квике - транслируется время в нижнем левом углу (я так понимаю, это время сервера брокера). Перед началом торгов - синхронизируемся с этим временем (т.е. измерили начальную дельту между временем ОС и сервера и далее, динамически её мониторим) - потом, в процессе торгов - динамически сверяем его с временем операционной системы. И если время отличается, скажем, на секунду-две - то "что-то не так". Надо, стало быть перенастроить ботов на дальний таймфрейм, убрав высокочастотные алгоритмы из пула. Что касается остальных серверов - то, это уже Вам решать, как Вы это сделаете и будете ли это делать для нас, клиентов. Варианты есть - разные.
Michael Bulychev написал: На мой взгляд в том что Вы предлагаете больше вопросов чем реальной пользы. Это касается и синхронизации времени в отдельном приложении и повышения приоритета данных.
есть вопросы? предлагайте:))
В данный же момент мы имеем, что:
у меня есть время операционной системы (которое у меня "какбы" успешно синхронизируется с серверами точного времени)
есть время, которое мне показывается в квике, которое частенько - не укладывается ни в какие рамки (особенно после выходных)
есть время, которое мне транслирует квик в сделках
ни одно из этих трёх "времён" - не синхронизировано и очень часто - отличается.
тот самый написал: ничто не мешает Вам, как разработчикам - повысить приоритет клентского запроса на пинг по его требованию.
а чтоб не было DDOS и флуда, просто сделать ограничение на приём такой приоритетной команды по времени.
Цитата
тот самый написал: Более того, клиент имеет право знать, что есть ли задержка со связью с брокером или нет, чтоб если что - оперативно на это отреагировать, сменив маршрут на другой сервер.
At this time... Мой брокер соорудил такую приблуду - но, ... хотелось бы вариант от разработчиков - т.е. встроенный в QUIK.
s_mike@rambler.ru написал: Надежность важнее удобств. Поэтому появление (намеренное) в финансовом ПО дыр, облегчающих жизнь одному отдельно взятому администратору сервера за счет потенциальной угрозы всем конечным пользователям - это нонсенс..
тот самый написал: Что значит "...в ближайшее время..."? т.е. Вы хотите сказать, что контент старого форума будет вновь доступен??
Старый форум уже не работает.
Цитата
тот самый написал: Если Вы - окончательно "распрощались" со старым форумом - могу ли я в таком случае - свободно выкладывать сохранённые материалы с него (топики и комментарии) для пользователей, с которыми В так обошлись?...
А раньше что мешало?
т.е. если я реанимирую Ваш старый форум - Вы не станете возражать?
Michael Bulychev написал: Сервер 10 секунд занимался тем, что отдавал вам очередь более приоритетных данных. По моему, наиболее адекватная оценка будет по времени последней сделки на ликвидном рынке.
скажем, так...: в других системах - есть такая фича, что сервер - прямо синхронизирует время на клиенте (время, скажем, в самом торговом терминале НО! не время операционной системы) - со своим. А что касается пинга и его реализации - то, ничто не мешает Вам, как разработчикам - повысить приоритет клентского запроса на пинг по его требованию. Всё остальное - пустые отговорки. Более того, клиент имеет право знать, что есть ли задержка со связью с брокером или нет, чтоб если что - оперативно на это отреагировать, сменив маршрут на другой сервер. Или даже перераспределить свои транзакции на другого брокера
тот самый написал: в детстве, я много раз видел когда из вполне нормального велосипеда - делают непойми что, - обматывая его светоотражающей лентой и ставя катафоты на каждой спице. Везде - итог один: дети взрослеют, а изуродованный велосипед - в утиль.
но!... дети-то, понятно, развиваются/взрослеют - но Вы-то, как компания??? Сколько Вы уже на рынке? 16-ый год?..))) А вереница из нескончаемых багов и недоделок - так и тянется за Вами... Аж старый форум потёрли, чтоб не позориться..)))
Sergey Gorokhov написал: И мы не считаем это изъяном, а скорее великим благом для решения конкретных задач отдельно взятого брокера.
а Вы что? Фирма, которая делает софт исключительно только в интересах так называемого "отдельно взятого брокера"? Суть описанной выше проблемы то, - что из-за всех этих Ваших галочек в многочисленных настройках, будь-то clientside или serverside (которые ещё далеко невсегда можно отследить и учесть с помощью скриптов) - проще и безопасней нанять "девочку", которая будет пялиться в монитор и "фильтровать" все Ваши "прибамбасы и несросты".
в детстве, я много раз видел когда из вполне нормального велосипеда - делают непойми что, - обматывая его светоотражающей лентой и ставя катафоты на каждой спице. Везде - итог один: дети взрослеют, а изуродованный велосипед - в утиль.
насчёт шарпа - соглашусь: иметь тормознутый квик, над ним ещё QLUA (виртуальную машину) да потом ещё и виртуальную машину Си Шарпа - это, конечно...... (ну вы поняли...:))) ) к сожалению, новые поколения тупеют с каждым поколением... Отсюда и такая повальная любовь ко всяким "шарпам"... особенно веселит, когда они искренне думают, что если на шарпе это занимает одну строчку кода - то это и действительно короче и быстрей:
Виталий Комаров написал: Здравствуйте уважаемые коллеги трейдеры, подскажите пожалуйста, где можно подсмотреть пример реализации какого ни будь не хитрого торгового робота, например машек или линий болинджера на C# с данными получаемыми из Quik(DDE, ODBC), без ММ, без рисования графиков, нейронных сетей, бэктестирования и тп. Только голый принцип, чтобы принимало данные, тривиальная аналитика и отправляло ордера.
Egor Zaytsev написал: К сожалению, старый форум в ближайшее время работать не будет.
Прошу дать полный и аргументированный ответ:
Что значит "...в ближайшее время..."? т.е. Вы хотите сказать, что контент старого форума будет вновь доступен??
Если Вы - окончательно "распрощались" со старым форумом - могу ли я в таком случае - свободно выкладывать сохранённые материалы с него (топики и комментарии) для пользователей, с которыми В так обошлись?...
в данном контексте: приложение - и есть процесс. никакие другие процессы при открытии вкладок (листов) в Excel - не создаются, что честно было показано Вам в Диспетчере Задач. запустив 2 процесса - Excel - разумеется будут 2 не связанных между собой процесса. Что также, честно Вам было показано в Диспетчере Задач. Сеанс - это не процесс и не приложение. Это - текущий пользователь, подключенный к системе (в данном случае, - к Операционной Системе).
написал: Старатель пишет: подстановка значения 0 или "" вместо nil там, где значения в принципе нет, приводит к неопределённому поведению программы. В программировании это недопустимо. А суть такова, что проставлять нужно только те параметры, которые заведомо имеют какое-то значение. Параметры, не имеющие значений должны быть nil . Тогда робот, получивший колбек, в котором, не проставлены интересующие его параметры, будет понимать, что нужно ждать следующего колбека. В данной ситуации это выглядело бы так: При получении сделки с бижи, если сервр не успел проставить номер транзакции, то он так и отправляет сделку с trans_id=nil (а не 0 ). После, когда сервер будет отправлять следующий колбек, он уже проставит номер транзакции.
проще и безопасней, в таком случае, передавать параметры в строковом типе и если параметра нет - ставить "" - т.е. ничего не ставить. присваивая же "nil" в LUA. Может получится так, что сборщик мусора - совсем избавится от этого параметра (честно говоря, давно не проверял - но, уже писалось кажется об этом).
Выскажу свою точку зрения (ни на чём, не основанную):
Заявки бывают двух видов: лимитированные и рыночные (и то, на рынке - они все рыночные. Это уже сам QUIK и брокеры - делают их лимитированными). Сами по себе - лимитированные заявки - не могут создать Событие подачи рыночной заявки.
Таким образом, Направление "покупка" или "продажа" - определяется по тому - кто первый: продавец или покупатель - кинул Рыночный ордер. Далее, биржевой алгоритм - выбирает подходящую лимитную заявку для исполнения из всего пула лимитников. Выбор оптимального лимитника - осуществляется по релевантности и небольшой случайной составляющей.
Николай Камынин написал: почему LUA-поток - сродни корутинам. это и есть корутины других луа потоков я не знаю а Вы?
сумничал, что ль?
т е сам не знаешь что сказал? Бывает, не переживайте.
я сказал - лишь то, что написано. А ты - только троллишь и убиваешь темы. корутины - это не LUA-потоки. В LUA - корутины используют LUA-потоки - НО! Это не LUA-потоки. И уж тем более - НЕ - потоки ОС.
Вячеслав написал: Да, создаются 2 системных потока, да, в каждом из них выполняется lua_pcall
Всегда, при разговоре на эту тему - разделяйте понятия: системный поток - это НЕ LUA-поток, а поток ОС LUA-поток - это не поток ОС. LUA-поток - сродни корутинам.
В самой LUA - никакие системные потоки - не создаются
Вячеслав написал: если выполнение потока main будет приостановлено системным планировщиком на середине выполнения Lua-команды (luaV_execute) и в этот момент начнёт выполняться основной поток Quik, который захочет вызвать наш callback, то основной поток Quik будет ждать на lua_lock операции (планировщик переключит выполнение на другой поток вместо основного потока Quik), т. к. поток main в данный момент владеет мьютексом, который предотвращает одновременное выполнение двух Lua-комманд из разных потоков.
1. по понятным причинам, не ручаюсь на 100% но, код работы с коллбеками, завязан на отдельный LUA-поток в контексте одной виртуальной машины. Другой поток (и физический и LUA-поток) - это, ещё один коллбек - функция "main". Таким образом, никаких проблем там - уже давно не возникает. 2. любой доступ к глобальным переменным - обёрнут критическими секциями. Это уже было сказано Михаилом Булычевым. Строго говоря, такие вопросы Вам - и надо ему задавать, а не "бодаться" с другими.