Problème de saisie d'ordres multiples pour un compte en direct avec un courtier spécifique - page 5
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Alain, pas de problème, vous n'avez pas à répondre, car vous ne trouverez probablement jamais de cas, puisque c'est obligatoire dans tout bon protocole OMS.
De plus, vous n'avez pas besoin de dire pourquoi vous n'avez pas posé de question après le premier message, puisque c'est probablement hors sujet.
Quoi qu'il en soit, notez que FOK est une ancienne politique de remplissage, que MQ a introduit probablement pour traiter la communication avec OMS, donc vous le trouverez dans tous les bons protocoles OMS, comme FIX, par exemple(comme ce sujet de forum de l'année 2009, avant que MT5 existe).
Donc, à mon avis, je ne vois aucune raison de demander le code de retour 10010 pour un ordre Fill ou Kill, et c'est le point, puisque cette règle est obligatoire et les courtiers et les fournisseurs OMS doivent la respecter.
Bien sûr, vous n'avez pas à répondre à ces questions, Rogerio, vous ne pouvez pas connaître toutes les réponses. Mais je pensais qu'un trader expérimenté comme toi pourrait m'éclairer.
Ce n'est pas du tout un hors-sujet. Ne pensez-vous pas qu'une compréhension complète du code de retour de la demande peut aider à résoudre le problème du "double ordre" ?
Merci pour votre opinion... Ce n'est pas mon intention d'apporter de la "confusion" dans l'esprit des gens.
Cependant, je ne pense pas que ce soit hors sujet car si vous ne vérifiez pas le code 10010, votre conseiller expert pourrait contourner cette possibilité et envoyer des ordres multiples (totalement lié au sujet, vous ne pensez pas ?)...
C'est ce que nous "essayons" d'alerter depuis les deux derniers messages sur ce même sujet...
Mais que faites-vous après avoir reçu un 10010 dans ce cas ? N'est-ce pas la même chose que Print() l'erreur, comme tous les codes le font ici ?
Quoi qu'il en soit, si vous déboguez le protocole FIX ou le codage OMS, cela me semble logique, mais je pense que ce n'est pas le cas.
Dans mon exemple, je parlais de volumes d'environ 200 000 USD... Donc, pour autant que je sache, plusieurs d'entre nous négocient plus de 200 000 USD par transaction... :-)
Bonjour, je voulais dire combien vous risquez par transaction et je ne parlais pas de la taille des lots. Par exemple, si quelqu'un risque 2% de son capital et est autorisé à perdre 200.000 dollars US par transaction. Cela signifie que la taille de son compte est de près de 10 millions de dollars US. Je pense qu'un compte de cette taille peut être considéré comme un petit fonds spéculatif ou une petite société de prop trading. À mon avis, dans ce cas, un arrangement un peu différent peut être nécessaire par rapport aux petits traders privés. Je veux dire que négocier avec des courtiers de détail comme les petits traders privés n'est probablement pas une chose sage.
Salutations.
Réponse créative, peut-être qu'en testant de telles choses, comme 10010 après un ordre FOK, nous pouvons découvrir quelque chose de nouveau, comme un bug du serveur MQ.
Mais que faites-vous après avoir reçu un 10010 dans ce cas ? N'est-ce pas la même chose que Print() l'erreur, comme tous les codes le font ici?
En tout cas, si vous déboguez le protocole FIX ou le codage OMS, cela me semble logique, mais je pense que ce n'est pas le cas.
Je n'ai pas dit qu'il était possible d'obtenir un code 10010 après une commande FOK... J'ai seulement dit que vous devez également vérifier le code 10010.
Et mon approche pour traiter les remplissages partiels n'est pas une simple instruction Print()... parfois il faut être "créatif" pour trouver des solutions à des problèmes spécifiques... :-)
Bonjour, je voulais dire combien vous risquez par transaction et je ne parlais pas de la taille des lots. Par exemple, si quelqu'un risque 2% de son capital et est autorisé à perdre 200.000 dollars US par transaction. Cela signifie que la taille de son compte est de près de 10 millions de dollars US. Je pense qu'un compte de cette taille peut être considéré comme un petit fonds spéculatif ou une petite société de prop trading. À mon avis, dans ce cas, un arrangement un peu différent peut être nécessaire par rapport aux petits traders privés. Je veux dire que négocier avec des courtiers de détail comme les petits traders privés n'est probablement pas une chose sage.
Salutations.
Bien sûr, vous n'avez pas à répondre à ces questions, Rogerio, vous ne pouvez pas connaître toutes les réponses. Mais je pensais qu'un trader expérimenté comme toi pourrait m'éclairer.
Ce n'est pas du tout hors sujet. Ne pensez-vous pas qu'une compréhension complète du code de retour de la demande peut aider à résoudre le problème de la "double commande" ?
Alain, je te répondrai toujours, et parfois ma réponse est je ne sais pas, j'ai tort, mon erreur, etc. Après tout, nous sommes tous des humains, et personne n'est parfait ici.
Pour ce sujet, 10009 = 10008 + 1, puisque c'est le code original posté ici (pas mon code) et qu'il ne concerne pas le bug demandé (mon opinion).
Quoi qu'il en soit, si vous pensez que cela est pertinent, vous êtes invités à créer un sujet à ce sujet et à nous inviter.
"Future proof" et "Safe enough" signifient que la gestion des commandes est un processus et que les règles, protocoles, architecture, etc. de MQ/courtiers/fournisseurs changent tous les jours, donc ne le considérez pas comme une solution définitive.
L'absence de code de retour est due au fait que le second code de FinanceEngineer utilise checkOrderSend (code ci-dessous) mais ne teste jamais vraiment cette variable.
S'il y a quelque chose qui n'a pas été répondu, vous êtes le bienvenu, il suffit de demander à nouveau.
Bonjour FinanceEngineer, vous avez raison. Je ne parlais pas du risque par transaction, donc je suis désolé si j'ai mal compris votre point de vue. Je parlais plutôt de la taille des transactions...
Bonjour :)
Pas besoin d'être désolé.
Ici, nous discutons des choses avec un esprit ouvert.
Peu de choses dans ce monde peuvent être résolues par une logique en noir et blanc.
Comme vous l'avez mentionné plus tôt, un peu de créativité vient lorsque vous parlez à quelqu'un.
Nous appelons cela une discussion.
En ce qui concerne le code 10010, je serais assez surpris si quelqu'un obtenait un code 10010 alors qu'il n'a envoyé que 10 lots ou moins.
Avez-vous déjà fait l'expérience d'une telle exécution partielle avec votre EA ? Dans ce cas, combien de lots avez-vous envoyés ? :)
Salutations.
Alain, je te répondrai toujours, et parfois ma réponse est je ne sais pas, j'ai tort, mon erreur, etc. Après tout, nous sommes tous des humains, et personne n'est parfait ici.
Pour ce sujet, 10009 = 10008 + 1, puisqu'il s'agit du code original posté ici (pas mon code) et ne concernant pas le bug demandé (mon opinion).
Quoi qu'il en soit, si vous pensez que cela est pertinent, vous êtes invités à créer un sujet à ce sujet et à nous inviter.
Je n'ai pas besoin d'ouvrir un sujet, nous avons déjà celui-ci. Ne voyez-vous pas dans ce sujet comment une discussion ouverte, non limitée à ce que le PO a strictement demandé, peut conduire à une explication complète de la raison pour laquelle nous avons eu des doubles trades?
Bien sûr, cela ne signifie pas que nous ne pouvons pas obtenir des ordres doubles pour d'autres raisons, et c'est ce que nous explorons dans ce sujet. Mais il semble que vous ne preniez pas cela très au sérieux (10009=10008+1 ?). Il semble que personne ici ne comprenne la signification réelle de ces codes.
Future proof" et "Safe enough" signifient que la gestion des commandes est un processus et que les règles, protocoles, architectures, etc. de MQ/courtiers/fournisseurs changent tous les jours, donc ne le considérez pas comme une solution définitive.
L'absence de code de retour est due au fait que le second code de FinanceEngineer utilise checkOrderSend (code ci-dessous) mais ne teste jamais vraiment cette variable.
Vous insistez sur ce point, mais il n'est pas vraiment pertinent. Si le code renvoyé est 10009 ou 10008, alors checkOrderSend ne peut être que vrai, sinon il ne peut être que faux. La vérification de 10009 et 10008 implique la vérification de checkOrderSend, sauf si le code 10008 ou 10009 signifie une erreur, d'où ma question précédente.
...
En ce qui concerne le code 10010, je serai assez surpris si quelqu'un a obtenu le code 10010 alors qu'il n'a envoyé que 10 lots ou moins.
En ce qui concerne le code 10010, je serais assez surpris si quelqu'un obtenait un code 10010 alors qu'il n'a envoyé que 10 lots ou moins.
Avez-vous déjà fait l'expérience d'une telle exécution partielle avec votre EA ? Dans ce cas, combien de lots avez-vous envoyés ?)