Функция OrderSendAsync() - страница 4

[Denis Kirichenko]

Коллеги, а как вам такая идея? В такой структуре (MqlPacketTradeResult) можно прописать поле, указывающее кол-во выполненных заявок, ну и т.д.

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Yedelkin]

denkir:

Коллеги, а как вам такая идея? В такой структуре (MqlPacketTradeResult) можно прописать поле, указывающее кол-во выполненных заявок, ну и т.д.

Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().

[Denis Kirichenko]

Yedelkin:
Но для этого придётся дожидаться ответа от сервера в рамках функции OrderSendAsync(). И асинхронность функции OrderSendAsync() сойдёт на нет. Ренат же уже пообещал, что будут иные функции, с помощью которых можно попытаться похимичить после срабатывания OrderSendAsync().

Да, что-то не подумал про асинхронность...

Тогда так:

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   );

bool  OrderReceiveAsync(
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

[Rashid Umarov]

denkir:

Да, что-то не подумал про асинхронность...

Тогда так:

Асинхронность означает работу без ожидания ответа. Выстрелил (OrderSenAsync) и побежал, не пытаясь увидеть, что цель поражена. Ибо нет времени.

Косвенным ответом будет пришедший позже звук (OnTrade) - может это выстрел достиг цели, а может просто что-то упало. Тут при желании и можно выглянуть и посмотреть (проверить все ордера, сделки, позиции и т.д.).

[Yedelkin]

denkir:

Да, что-то не подумал про асинхронность...

Тогда так:

Ну, тогда уже OrderSendPacketAsync(), OrderReceivePacketAsync :) Чтоб оставалась возможность отправлять единичный запрос в уже имеющемся асинхронном режиме, и разыскивать информацию о нём впоследствии.

[Yedelkin]

Rosh:

Косвенным ответом будет пришедший позже звук (OnTrade) - может это выстрел достиг цели, а может просто что-то упало. Тут при желании и можно выглянуть и посмотреть (проверить все ордера, сделки, позиции и т.д.).

Вот он и предлагает использовать в OnTrade() некие функции OrderReceiveХХХ(), чтобы была возможность реагировать не на все подряд приходящие события  Trade, а только на те, которые относятся к асинхронным очередям.

[hrenfx]

Rosh:

Асинхронность означает работу без ожидания ответа. Выстрелил (OrderSenAsync) и побежал, не пытаясь увидеть, что цель поражена. Ибо нет времени.

Косвенным ответом будет пришедший позже звук (OnTrade) - может это выстрел достиг цели, а может просто что-то упало. Тут при желании и можно выглянуть и посмотреть (проверить все ордера, сделки, позиции и т.д.).

Немного привираете либо из-за малого опыта торговли в асинхронном режиме, либо из-за слабого пока функционала MT5 для такой работы.

Асинхронность не нужна ради асинхронности. И используется только тогда, когда это выгодно. Например, при торговле портфелем, когда портфель надо, например, купить или перебалансировать тут и сейчас. Т.е. совершить по текущим ценам сразу десяток-другой торговых приказов по разным символам.

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

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

На первой странице этого обсуждения приведены диаграммы и приходящие сообщения-события. Они не на ровном месте появились, а с многолетним опытом работы в асинхронном режиме. Поэтому стоит без брезгливости обратить на подобную архитектуру внимание.

[Mykola Demko]

denkir:

Коллеги, а как вам такая идея? В такой структуре (MqlPacketTradeResult) можно прописать поле, указывающее кол-во выполненных заявок, ну и т.д.

Вы предполагаете что пачка заявок всегда имеет одинаково заполненные поля?

ИМХО пачка одинаковых заявок нужна лишь для демонстрации, для работы будет использоваться заявки по разным символам, с разными объёмами и конечно разного направления. А следовательно каждый reguest придётся в отдельности проверить, так что смысла отправлять их пачкой нет.

А то что вы предполагаете это всего лишь обвязка цикла for.

[Denis Kirichenko]

Urain:

Вы предполагаете что пачка заявок всегда имеет одинаково заполненные поля?

ИМХО пачка одинаковых заявок нужна лишь для демонстрации, для работы будет использоваться заявки по разным символам, с разными объёмами и конечно разного направления. А следовательно каждый reguest придётся в отдельности проверить, так что смысла отправлять их пачкой нет.

А то что вы предполагаете это всего лишь обвязка цикла for.

А что мешает заполнить каждый reguest циклично? А потом так же циклично обработать каждый result? 

[Mykola Demko]

denkir:
А что мешает заполнить каждый reguest циклично? А потом так же циклично обработать каждый result? 

Если ваше предложение будет лишь дополнять существующую функцию то ничего, иначе не понятно как простая структура MqlPacketTradeRequest ...

bool  OrderSendAsync(
   MqlPacketTradeRequest&  packet_request,      // пакетная структура запроса
   MqlPacketTradeResult&   packet_result        // пакетная структура ответа
   );

... сможет передать запросы о разных заявках, если же структура MqlPacketTradeRequest есть структура динамичного массива структур MqlTradeRequest то это может поломать всю логику сервера который заточен под простые структуры запросов.

иначе говоря на уровне терминала придётся разделить этот пакет на отдельные заявки, что сводит на нет весь смысл введения данной перегрузки.