Fonction OrderSendAsync() - page 4

[Denis Kirichenko]

Chers collègues, que pensez-vous de cette idée ? Dans une telle structure(MqlPacketTradeResult), vous pouvez écrire un champ indiquant le nombre d'ordres exécutés, etc.

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

[Yedelkin]

denkir:

Chers collègues, que pensez-vous de cette idée ? Dans une telle structure(MqlPacketTradeResult), vous pouvez écrire un champ indiquant le nombre d' ordres exécutés , etc.

Mais pour ce faire, nous devrions attendre une réponse du serveur dans la fonction OrderSendAsync(). Et l'asynchronisme de la fonction OrderSendAsync() sera réduit à néant. Renat a déjà promis qu'il y aura d'autres fonctions qui peuvent être utilisées pour essayer de semer la pagaille après le déclenchement de OrderSendAsync().

[Denis Kirichenko]

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

Oui, je n'avais pas pensé à l'asynchronie...

C'est tout, alors :

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

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

[Rashid Umarov]

denkir:

Oui, je n'avais pas pensé à l'asynchronie...

Eh bien, voilà :

Asynchrone signifie que l'on travaille sans attendre de réponse. Tirez (OrderSenAsync) et exécutez sans essayer de voir si la cible est touchée. Car il n'y a pas de temps.

Une réponse indirecte serait un son émis plus tard (OnTrade) - peut-être que le tir a atteint la cible, ou peut-être que quelque chose est tombé. C'est là que vous pouvez regarder et voir (vérifier tous les ordres, transactions, positions, etc.) si vous le souhaitez.

[Yedelkin]

denkir:

Oui, je n'avais pas pensé à l'asynchronie...

C'est tout, alors :

Bien, alors déjà OrderSendPacketAsync(), OrderReceivePacketAsync :) Ainsi, il est toujours possible d'envoyer une seule demande en mode asynchrone et de rechercher des informations à son sujet par la suite.

[hrenfx]

Rosh:

Asynchrone signifie que l'on travaille sans attendre de réponse. Tirez (OrderSenAsync) et exécutez sans essayer de voir si la cible est touchée. Car il n'y a pas de temps.

Une réponse indirecte est un son ultérieur (OnTrade) - il se peut que le tir ait touché la cible ou que quelque chose soit tombé. C'est là que vous pouvez regarder si vous le souhaitez (vérifier tous les ordres, transactions, positions, etc.).

Vous vous trompez soit à cause de votre manque d'expérience dans le trading en mode asynchrone, soit à cause de la faible fonctionnalité de MT5 pour ce type d'opération.

Vous n'avez pas besoin d'asynchronisme pour le plaisir de l'asynchronisme. Et elle n'est utilisée que lorsque c'est rentable. Par exemple, lors de la négociation d'un portefeuille, lorsque le portefeuille doit être acheté ou rééquilibré ici et maintenant. En d'autres termes, une douzaine d'ordres de négociation pour différents symboles aux prix actuels.

Et personne ne le fera, si vous traitez l'asynchronie comme vous l'avez décrit - tirer et oublier. Et les réactions aux coups de feu doivent être évaluées sur la base des positions nettes actuelles. Les réactions doivent être spécifiques à chaque ordre commercial.

S'il y a eu une redirection, nous devrions en être informés, ou nous devrions recevoir une autre réponse. Nous ne devrions pas deviner s'il y a eu une réenchère ou non, puisque la position nette n'a pas changé pendant une seconde ou deux.

Sur la première page de cette discussion, il y a des diagrammes et des événements de messages entrants. Ils ne sont pas apparus comme par enchantement, mais avec des années d'expérience asynchrone. Il vaut donc la peine de prêter attention à ce type d'architecture sans choquer.

[Mykola Demko]

denkir:

Chers collègues, que pensez-vous de cette idée ? Dans une telle structure(MqlPacketTradeResult), vous pouvez écrire un champ indiquant le nombre d'ordres exécutés, etc.

Vous partez du principe que le lot de commandes comporte toujours les mêmes champs ?

À mon avis, un lot de demandes identiques n'est nécessaire qu'à des fins de démonstration. Pour le travail, on utilisera des demandes de caractères différents, avec des volumes différents et, bien sûr, des directions différentes. Et par conséquent, chaque demande devra être vérifiée séparément, ce qui n'a aucun sens de leur envoyer un lot.

Et ce que vous supposez est juste une liaison de la boucle for.

[Denis Kirichenko]

Urain:

Suggérez-vous qu'une pile de candidatures a toujours les mêmes champs remplis ?

À mon avis, un lot d'applications identiques n'est nécessaire qu'à des fins de démonstration, les applications avec des caractères différents, des volumes différents et bien sûr des directions différentes seront utilisées pour le travail. Et par conséquent, chaque demande devra être vérifiée séparément, ce qui n'a aucun sens de leur envoyer un lot.

Et ce que vous supposez est juste une liaison de la boucle for.

Et qu'est-ce qui vous empêche de remplir chaque demande de manière cyclique? Et ensuite, tout aussi cycliquement, traiter chaque résultat?

[Mykola Demko]

denkir:
Qu'est-ce qui les empêche de remplir chaque demande de manière cyclique? Et ensuite, tout aussi cycliquement, traiter chaque résultat?

Si votre proposition ne fait que compléter la fonction existante, rien, sinon il n'est pas clair comment la structure simple MqlPacketTradeRequest ...

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

... Si la structure MqlPacketTradeRequest est la structure d'un tableau dynamique de structures MqlTradeRequest, cela peut casser toute la logique du serveur qui est conçu pour des structures de requête simples.

Sinon, au niveau du terminal, nous devrions diviser ce lot en demandes distinctes, ce qui annule tout l'intérêt d'introduire cette surcharge.

[Denis Kirichenko]

Urain:

Si votre proposition ne fait que compléter une fonction existante, alors rien, sinon on ne voit pas bien comment une simple structure MqlPacketTradeRequest ...

... Si la structure MqlPacketTradeRequest est la structure d'un tableau dynamique de structures MqlTradeRequest, cela peut casser toute la logique du serveur inondé de structures de requêtes simples.

sinon, au niveau du terminal, nous devrions diviser ce paquet en plusieurs requêtes distinctes, ce qui annulerait tout l'intérêt d'introduire cette surcharge.

Il semble que nous nous soyons "mis d'accord" sur une telle variante en raison de la structure asynchrone :

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

Où,

packet_request comprendra entre autres un tableau de structures MqlTradeRequest...

Alors toutes ces pensées sont de la matière première pour la discussion :-)