Последние недели две я вылизываю код своего робота (перфекционист хренов! 
), и на данный момент у меня осталась непричёсанной только функция OnTrade. Функция довольно неприятная: как известно, прерывания OnTrade (как и OnOrder) приходят пачками, и нет никаких признаков, что проблема эта будет когда-нибудь решена. Самое противное, что прерывания эти приходят не только пачками, но и вразнобой, т.е возможен последовательный приход прерываний по одной и той же заявке order_num, но с разными кодами сделки trade_num, например: trade_num1, trade_num1, trade_num2, trade_num2, trade_num1, то есть первое прерывание trade_num1 мы должны обработать, второе - игнорировать, третье (другая сделка по той же заявке) - обработать, четвёртое - игнорировать, пятое (предыдущая сделка по той же заявке) - тоже игнорировать. Когда я писал обработчик, я предположил, что такой ситуации быть не может "потому, что не может быть никогда". Увы, я ошибся. 
Очевидно, что снимать даже исполненные заявки просто так нельзя - обязательно напоремся на повторные прерывания с тем же кодом. Я и держал у себя айдишки заявок и сделок до конца сессии - всё равно они по окончанию снимаются автоматически. А чтобы не было вышеописанных глюков, поставил заглушку "1 заявка - 1 лот". Ни то, ни другое меня более не устраивает. От прерывания OnOrder (и его потенциальных глюков) я отказался с самого начала, но OnTrade хотелось бы сохранить - не в таблице же сделок ковыряться (тем более, там своих глюков наверняка предостаточно). Поэтому алгоритм торговли я сейчас вижу примерно так:
1. Обо всех "своих" заявках (либо сделанных самостоятельно, либо совершённых пользователем вручную через сервис контекстного меню) скрипт, конечно, знает, но ведь юзер может торговать и в обход скрипта, через стаканы! Поскольку скрипт ведёт учёт состояния портфеля, он должен знать и об этих сделках, и узнаёт он о них именно через OnTrade. При этом он способен определить, какая именно это сделка: своя или "левая", но для "левых" заявок он не знает, какой она величины (разве что получит статус "заявка исполнена").
2. Пользователь может не только подать заявку, но и снять её, причём не только свою, но и сделанную скриптом. О таких "подлянках" скрипт не может узнать в принципе (если отказаться от OnOrder и не ползать по таблицам).
3. В момент подачи заявки на покупку скрипт резервирует необходимое количество соответствующей валюты, но если заявку подаёт пользователь, такого резервирования нет, и потому он закрывает заявку не из резерва, а из свободной наличности.
4. Через некоторое время (скажем, 3-5 минут) скрипт должен принудительно снимать заявки. Собственно, закрытые заявки (здесь уже наверняка пришли все возможные прерывания) не снимаются - просто редактируется паспорт состояния соответствующего тикера, а вот активные (они могут быть только свои, заявки юзера скрипт снимать не имеет права) нужно убивать через KILL_ORDER.
Примерная структура паспорта (i-го тикера), касающаяся заявок/сделок:
[i]["Orders"] - сам паспорт (таблица Lua, то бишь дерево)
[i]["Orders"]["C"] - значение счётчика прерываний по таймеру, после которого можно снимать заявки (пока кажется разумным иметь общее для всех заявок, в противном случае нужно это поле воткнуть в паспорт заявки)
[i]["Orders"]["N"] - количество (незакрытых) заявок
[i]["Orders"][j] - массив паспортов заявок (я люблю C, так что нумерация с нуля).
[i]["Orders"][j]["ID"] - ID заявки в торговой системе
[i]["Orders"][j]["n"] - количество лотов в заявке (для "левых" заявок 0)
[i]["Orders"][j]["N"] - количество сделок по j-й заявке
[i]["Orders"][j][k] - массив паспортов сделок (нумерация с нуля) с (кажется) единственным значением в паспорте: [i]["Orders"][j][k] - ID сделки (чтобы игнорировать "лишние" прерывания)
Что-то громоздко получается... Где наврал?
), и на данный момент у меня осталась непричёсанной только функция OnTrade. Функция довольно неприятная: как известно, прерывания OnTrade (как и OnOrder) приходят пачками, и нет никаких признаков, что проблема эта будет когда-нибудь решена. Самое противное, что прерывания эти приходят не только пачками, но и вразнобой, т.е возможен последовательный приход прерываний по одной и той же заявке order_num, но с разными кодами сделки trade_num, например: trade_num1, trade_num1, trade_num2, trade_num2, trade_num1, то есть первое прерывание trade_num1 мы должны обработать, второе - игнорировать, третье (другая сделка по той же заявке) - обработать, четвёртое - игнорировать, пятое (предыдущая сделка по той же заявке) - тоже игнорировать. Когда я писал обработчик, я предположил, что такой ситуации быть не может "потому, что не может быть никогда". Увы, я ошибся. Очевидно, что снимать даже исполненные заявки просто так нельзя - обязательно напоремся на повторные прерывания с тем же кодом. Я и держал у себя айдишки заявок и сделок до конца сессии - всё равно они по окончанию снимаются автоматически. А чтобы не было вышеописанных глюков, поставил заглушку "1 заявка - 1 лот". Ни то, ни другое меня более не устраивает. От прерывания OnOrder (и его потенциальных глюков) я отказался с самого начала, но OnTrade хотелось бы сохранить - не в таблице же сделок ковыряться (тем более, там своих глюков наверняка предостаточно). Поэтому алгоритм торговли я сейчас вижу примерно так:
1. Обо всех "своих" заявках (либо сделанных самостоятельно, либо совершённых пользователем вручную через сервис контекстного меню) скрипт, конечно, знает, но ведь юзер может торговать и в обход скрипта, через стаканы! Поскольку скрипт ведёт учёт состояния портфеля, он должен знать и об этих сделках, и узнаёт он о них именно через OnTrade. При этом он способен определить, какая именно это сделка: своя или "левая", но для "левых" заявок он не знает, какой она величины (разве что получит статус "заявка исполнена").
2. Пользователь может не только подать заявку, но и снять её, причём не только свою, но и сделанную скриптом. О таких "подлянках" скрипт не может узнать в принципе (если отказаться от OnOrder и не ползать по таблицам).
3. В момент подачи заявки на покупку скрипт резервирует необходимое количество соответствующей валюты, но если заявку подаёт пользователь, такого резервирования нет, и потому он закрывает заявку не из резерва, а из свободной наличности.
4. Через некоторое время (скажем, 3-5 минут) скрипт должен принудительно снимать заявки. Собственно, закрытые заявки (здесь уже наверняка пришли все возможные прерывания) не снимаются - просто редактируется паспорт состояния соответствующего тикера, а вот активные (они могут быть только свои, заявки юзера скрипт снимать не имеет права) нужно убивать через KILL_ORDER.
Примерная структура паспорта (i-го тикера), касающаяся заявок/сделок:
[i]["Orders"] - сам паспорт (таблица Lua, то бишь дерево)
[i]["Orders"]["C"] - значение счётчика прерываний по таймеру, после которого можно снимать заявки (пока кажется разумным иметь общее для всех заявок, в противном случае нужно это поле воткнуть в паспорт заявки)
[i]["Orders"]["N"] - количество (незакрытых) заявок
[i]["Orders"][j] - массив паспортов заявок (я люблю C, так что нумерация с нуля).
[i]["Orders"][j]["ID"] - ID заявки в торговой системе
[i]["Orders"][j]["n"] - количество лотов в заявке (для "левых" заявок 0)
[i]["Orders"][j]["N"] - количество сделок по j-й заявке
[i]["Orders"][j][k] - массив паспортов сделок (нумерация с нуля) с (кажется) единственным значением в паспорте: [i]["Orders"][j][k] - ID сделки (чтобы игнорировать "лишние" прерывания)
Что-то громоздко получается... Где наврал?