sam063rus пишет: т.е. - я вообще ничего не делал: я просто кинул его в папку LuaIndicators и включил квик - в итоге, не будучи ни на одном графике - он сам запустился.
Да, действительно. Если на графике добавлен хоть один Lua-индикатор, то при старте QUIK будут запускаться все скрипты из папки LuaIndicators. Причём столько раз, сколько открыто Lua-индикаторов. Это ещё один повод, чтобы вне колбеков ничего лишнего не размещать.
Цитата
sam063rus пишет: но он всё-равно запускается. И причём, несколько раз
Очевидно, у вас добавлено несколько Lua-индикаторов на графиках.
Надо делать так, как надо. А как не надо - делать не надо.
sam063rus пишет: чем не основа для вирусописательства?
А вообще, конечно, да. Пользователям нужно внимательно следить за тем, какие скрипты они помещают в папку LuaIndicators, т.к. с их помощью можно выполнять различные действия (в т.ч., отправку транзакций) без ведома пользователя. Только не при старте QUIK, а при добавлении индикаторов. Надеюсь это пофиксят. После прочтения - удалить.
Надо делать так, как надо. А как не надо - делать не надо.
Выше, глагол "добавлении" используется в настоящем времени несовершенного вида, т.е. указанные действия выполняются в момент добавления индикатора на график.
Надо делать так, как надо. А как не надо - делать не надо.
1. Не стоит размещать в папке LuaIndicators никаких файлов, кроме самих индикаторов, поскольку при добавлении любого индикатора каждый файл в этой папке сканируется минимум два раза:
Цитата
При добавлении нового индикатора на график плагин qlua сканирует папку LuaIndicators, проверяет файлы с расширением lua и luac (скомпилированные скрипты lua) [брехня! проверяются все файлы. Примеч. автора, т.е. меня] на соответствие следующим требованиям
2. Не стоит делать в теле индикатора (вне функций) что-либо, кроме объявления таблицы Settings, поскольку эти действия также будут выполняться минимум два раза при добавлении любого индикатора. Лучше сделать инициализацию в Init()
3. Если очень хочется, то вместо getScriptPath() можно использовать
Код
getWorkingFolder().."\\LuaIndicators"
Надо делать так, как надо. А как не надо - делать не надо.
Николай Камынин пишет: Это результаты на моем реальном счете и соответственно рабочем сервере в реальном времени.
В таком случае, вам надо настроить интервал обновления данных, чтобы не вводить людей (и себя в первую очередь) в заблуждение своими тестами. Информация как настроить есть в указанной выше мной теме. Почитайте, не ленитесь. ;-)
Надо делать так, как надо. А как не надо - делать не надо.
sam063rus пишет: Если расхождение между локальным и серверным временем > 1 сек то это простой способ определить нагрузку на канал брокера.
Наблюдал расхождение между локальным временем и серверным более 40 сек. Это расхождение было не в течение какого-то короткого времени, а нескольких дней. Причём наблюдалось не только у меня. Так что считать разницу между локальным и серверным временем - это простой способ определить несинхронизованность локального времени вашего компьютера и времени сервера QUIK у брокера, не более.
Цитата
sam063rus пишет: Но, если параметры не соответствуют "ожиданиям" - то, нет смысла торговать в это время
По одному счёту могут быть запущены несколько торговых роботов. Либо вестись торговля руками. Так что, в общем случае, текущая позиция по счёту может и не совпадать с ожиданиями робота.
Надо делать так, как надо. А как не надо - делать не надо.
lergen пишет: Не отображались изменения позиций по срочному рынку.
В смысле, при покупке/продаже контрактов не изменялись позиции по клиентским счетам? Такие проблемы на бирже часто случаются. Очевидно, текущую позицию нужно считать в каждом роботе самостоятельно, а не полагаться на биржу. И при большом расхождении значений отправлять уведомления по sms и e-mail. И копию отправлять брокеру и на биржу, чтоб не расслаблялись. :D
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: на случай "потери" части свечей сервером
а как робот поймёт, что это "потеря", а не неликвид?
А как человек это понимает (если заметит, конечно :) )? Наверное, надо прописать какой-то алгоритм. Хотелось бы услышать, какие варианты можно использовать.
Цитата
sam063rus пишет: для себя - сделал таблицу: критичных и некритичных параметров, а также контроль так сказать целостности данных на случай намеренного и ненамеренного "технического сбоя"
Можете подробнее описать, каким образом вы реализуете контроль целостности данных?
Цитата
sam063rus пишет: Также мониторится серверное время и локальное - при слишком большой разнице - некоторые алгоритмы - отменяются
Вот тут не понятно. Какие ошибки таким образом вы пытаетесь устранить?
Надо делать так, как надо. А как не надо - делать не надо.
Там, если покопаться, много чего интересного можно найти. Вот, например, инструмент линейка, о котором пользователи QUIK просят несколько лет; процентная шкала:
Надо делать так, как надо. А как не надо - делать не надо.
Старатель пишет: установил терминал одного из "конкурентов" Квика, который является его ровесником. И что же? Визуально - тот же самый QUIK, только отстал на несколько лет...
Хотя и у "отсталого" терминала есть чему поучиться. Вот, например, как выглядит настройка свойств трендовой линиии:
Надо делать так, как надо. А как не надо - делать не надо.
sam063rus пишет: Хотя стать Вашим конкуреном - дело весьма небольшого времени.
Да вот, к сожалению, что-то не видно этих конкурентов-то. Каких вы можете назвать потенциальных конкурентов? По вашим оценкам, сколько нужно времени, чтобы создать конкурентоспособный программный продукт с нуля. И какие для этого потребуются финансовые ресурсы?
Не поленился: установил терминал одного из "конкурентов" Квика, который является его ровесником. И что же? Визуально - тот же самый QUIK, только отстал на несколько лет...
Цитата
sam063rus пишет: моя компания - мне прмо предложила - если сделаете софт нетолько для клиентов НО!!! и для брокеров - они поддержат.
sam063rus, вашу энергию, да, как говорится, в нужное русло. Вы могли бы объединить талантливых программеров-энтузиастов для разработки такого ПО. От себя могу предложить тестирование данного продукта. Думаю, сотрудники ARQA не в восторге от моих тестирований. :D Я уже сам сбился со счёта, сколько багов, они обещали мне исправить.
Надо делать так, как надо. А как не надо - делать не надо.
sam063rus пишет: поставлена задача - дать пользователям полный доступ из квика- к архивным данным (из папки Archive) - и что мы видим? А ыидим мы - тысячу и одну отговорок.
Видимо, функционал этот платный. И, если дать пользователям возможность работать с архивом графиков, то у брокеров отпадёт необходимость в его покупке.
Надо делать так, как надо. А как не надо - делать не надо.
Alexey Ivannikov пишет: На наш взгляд в данном случае имеется некоторое недопонимание, не более того
Значит, брокер не достаточно информирован об этой возможности. Я и говорю, донесите до сведения брокеров, что трансляция архивных графиков "на ваш взгляд не создаёт серьёзной нагрузки для серверов."
Надо делать так, как надо. А как не надо - делать не надо.
s_mike@rambler.ru пишет: когда вы спрашиваете сервертиме, то получаете время в момент прихода запроса на сервер. Далее оно возвращается вам.
Никакой запрос никуда не отправляется. "SERVERTIME" вы получаете вместе с приходом параметров из ТТП. И оно корректируется на разницу времени, прошедшего с момента его прихода. А в остальном всё верно. В этом легко убедиться, убрав из списков принимаемых параметров все "галки". Время сервера продолжит тикать синхронно с вашими часами. Но после переподключения к серверу "SERVERTIME" уже не отображается.
Надо делать так, как надо. А как не надо - делать не надо.
to techsupport: У меня в папке archive сохранились файлы SPBFUT_RIH5_Х.dat. Почему нельзя открыть графики по данному инструменту? Сделайте возможность открывать графики архивных инструментов.
Надо делать так, как надо. А как не надо - делать не надо.
sam063rus пишет: Но, спрашивается, кому нужен стакан, несоответствующи реальному timestamp.
С одной стороны, да. А с другой, может кто-то сохраняет историю стакана. Может, стоит сделать настройку: если на сервере скопилась очередь OnQuote, то, в зависимости от этой настройки выдавать на рабочее место либо всю очередь в хронологическом порядке (как сейчас) либо только последнее состояние стакана.
Надо делать так, как надо. А как не надо - делать не надо.
Какую БД и библиотеку лучше использовать в Lua? Сейчас использую SQLite 3 через LuaSQL. Но есть проблемы при одновременном доступе к БД из разных потоков/скриптов даже при чтении.
Надо делать так, как надо. А как не надо - делать не надо.
Что за ошибка? Связана с какими-то частными настройками прав пользователя в Administrator? Или ошибка общего характера и проявляется у всех пользователей?
Надо делать так, как надо. А как не надо - делать не надо.
Alexandr Shumilin пишет: В общих чертах можно сказать, что "как правило" соблюдается следующий порядок рассылки на клиентские места QUIK — таблица текущих параметров, котировки, сделки, заявки, стоп-заявки, лимиты, графики, все-сделки.
Вот тут у меня есть сомнения: графики обновляются с большой задержкой по сравнению с ТВС. Хотя это может быть результатом частного случая настройки частоты обновлений графиков на сервере. В моём случае частота обновлений графиков - примерно 1 раз/сек.
Надо делать так, как надо. А как не надо - делать не надо.
Максим пишет: Так OnParam на кучу всего реагирует, так что частота не показатель.
Цитата
Максим пишет: И ещё, у вас же в скрипте хитрость - если между двумя вызовами OnQuote действительно стакан может несколько раз туда-сюда сходить, то вы на второй вызов ничего не напечатаете, т.к. best bid/offer "те же".
Частоту вызовов OnParam и OnQuote имеет смысл сравнивать только при изменении одинаковых параметров. В данном случае при изменении bid/offer. Поэтому я написал так, как написал - сравниваем только те колбеки, которые дают новую котировку bid/offer. По другому никак.
Цитата
Максим пишет: Может статься, что в OnParam показывается вообще не та же котировка, что потом покажется в OnQuote.
А по логу разве не видно, что в большинстве случаев OnQuote приносит туже котировку, что до этого нам показал OnParam?
Надо делать так, как надо. А как не надо - делать не надо.
Максим пишет: Сомнительные выводы из эксперимента (что непременно через OnParam надо котировки доставать). Там разница в пределах погрешности измерения + время на вызов колбека.
Ну наконец-то хоть кто-то решил оспорить мои выводы. Парирую: Да, действительно, в большинстве случаев разница небольшая. Среднее значение за рассматриваемый период порядка 22 мс. Но погрешность тут ни при чём: и без времени видно, что в большинстве случаев OnParam даёт котировку раньше.
Цитата
Максим пишет: Кроме того, в привидённом примере есть запись, противоречащая (по крайней мере на первый взгляд) утверждению о последовательности
Есть такая запись. Но это единственный случай из приведённого фрагмента лога, когда OnQuote оказывается "быстрее".
Очевидно, OnParam, как и OnAllTrade, приходят "пачками". Немного подчистил лог, удалив из него близкие по времени записи OnParam:
Не трудно заметить, что помимо того, что OnParam приходит раньше (в большинстве случаев), но и несколько чаще (незначительно, но факт). Уверен, это зависит от настроек сервера. Поэтому у каждого могут быть свои результаты. Но в моём случае, очевидно, работа с OnParam позволит раньше, пусть и ненамного, среагировать на изменение котировок.
Надо делать так, как надо. А как не надо - делать не надо.
Кстати, я специально даю фрагменты кода, чтобы каждый мог самостоятельно проверить на своём рабочем месте и опровергнуть мои доводы. Пока этого никто не сделал.
Надо делать так, как надо. А как не надо - делать не надо.
Это значит, что после такого колбека обязательно должен прийти OnOrder с заполненным UID? Какие ещё параметры могут быть не заполненными в колбеках OnOrder, OnTrade? Можете отметить их в руководстве.
Надо делать так, как надо. А как не надо - делать не надо.
Скрипт выводит в лог последнюю котировку bid/offer из OnParam и OnQuote:
Скрытый текст
Код
function OnQuote(class_code, sec_code)
if not bRun or sec_code ~= sSecCode or class_code ~= sClassCode then return end
local tStakan = getQuoteLevel2(class_code, sec_code)
local nBid_Count, nOffer_Count = tonumber(tStakan.bid_count), tonumber(tStakan.offer_count)
if nBid_Count ~= 0 then
local nBid = tonumber(tStakan.bid[nBid_Count].price)
if nBid ~= nBid_Q then
_toLog('[OnQuote] bid='..nBid); nBid_Q = nBid
end
end
if nOffer_Count ~= 0 then
local nOffer = tonumber(tStakan.offer[1].price)
if nOffer ~= nOffer_Q then
_toLog('[OnQuote] offer='..nOffer); nOffer_Q = nOffer
end
end
end
function OnParam(class_code, sec_code)
if not bRun or sec_code ~= sSecCode or class_code ~= sClassCode then return end
local nOffer = tonumber(getParamEx(class_code, sec_code, "OFFER").param_value)
local nBid = tonumber(getParamEx(class_code, sec_code, "BID").param_value)
if nBid ~= nBid_P then
_toLog('[OnParam] bid='..nBid); nBid_P= nBid
end
if nOffer ~= nOffer_P then
_toLog('[OnParam] offer='..nOffer); nOffer_P = nOffer
end
end
sam063rus пишет: Таким образом: заводим в классе булевую переменную, которая будет флагом нажатия определённой клавиши, которую мы получим в другом коллбеке (QTABLE_VKEY). далее, при приходе LBUTTONUP проверяем установлен ли этот флаг (полученный VKEY) and находимся ли мы в заданной ячейке. И если "Да" - do smth
Примерно так я и сделал. Так называемый, эффект залипания клавиши. :)
Надо делать так, как надо. А как не надо - делать не надо.
Очевидно, да, клик мышью при зажатой клавише (в частности Ctrl/Alt/Shift) Должно происходить, естественно, то событие, которое назначено в SetTableNotificationCallback
Надо делать так, как надо. А как не надо - делать не надо.
Sergey Gorokhov пишет: Спорный момент, буферизация есть не только на стороне сервера но и на стороне клиента. Скажем так, какого-то улучшения настройками сетевой карты добиться можно, вопрос только насколько значимыми они будут.
Ок, задам вопрос по-другому. Архитектура сервера QUIK построена таким образом, что он (рассмотрим ТВС) отдаёт сделку клиенту немедленно по факту получения с биржи или же отдаёт пачками через интервал времени (не меньше определённого значения)?
Надо делать так, как надо. А как не надо - делать не надо.