Fonction OrderSendAsync() - page 8
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
Parce que les paquets cassés, les connexions interrompues, etc. sont des conneries. Peu fiable. Peu fiable... vous devez rebondir.
Gardons les mouches séparées et les escalopes séparées.
Les paquets brisés constituent une situation anormale pour le terminal et doivent être traités par des exceptions, notamment par une analyse de l'historique.
Mais il est trop coûteux d'analyser l'historique de chaque commerce. L'arrivée d'un commerce est une situation normale et doit être traitée de manière peu coûteuse.
Salut. Savez-vous seulement ce qu'est l'asynchronie ?
D'après ce que je comprends, l'introduction de cette fonction pour les EA multi-devises (pour les EA mono-devises l'initiative n'a aucun sens), le seul but est de gagner du temps en évitant le retard dans l'exécution des ordres du côté du serveur. Corrigez-moi si je me trompe.
En dehors de cela, il ne reste qu'une portion de temps critique - la transmission des paquets de données sur les canaux de communication. Si vous essayez de repousser la "frontière de l'inconnu" au niveau de "laisser tomber (le paquet) et continuer", vous aurez plus de problèmes que d'avantages. Il est important d'évaluer le problème de manière holistique. Un éventuel temps mort, s'il y en avait un, est susceptible d'affecter non seulement la capacité de négocier sur un instrument particulier, mais aussi, en principe, l'absence de communication avec le serveur.
En outre, il n'est pas évident d'estimer à partir du conseiller expert: l'ordre de transaction a-t-il été perdu dans la transmission des données, ou attend-il son tour sur le serveur depuis si longtemps ? Et cela signifie qu'il y aura des erreurs avec des ordres de transaction en double, ce qui entraînera des violations du MM et, par conséquent, des risques accrus. A mon avis, tout trader professionnel (Expert Advisor) doit s'assurer que son ordre de transaction est accepté par le serveur. En outre, afin d'identifier clairement l'état d'un certain ordre commercial (dans la fonction OnTrade()), vous avez besoin d'une valeur unique reçue du serveur pour l'appliquer au traitement ultérieur (jusqu'à ce que la transaction soit exécutée (ouverture/fermeture d'une position).
Il est similaire au modèle de réseau OSI. Nous n'avons pas besoin d'entrer dans le canal ou la couche physique de l'exécution des ordres commerciaux. Laissez le client (MT5) exécuter cette fonction de transport. Opérer au niveau de la couche application.
Gain de temps grâce à l'absence de délai d'exécution de la commande au niveau du serveur. Corrigez-moi si je me trompe.
Au prix de ne pas attendre les résultats de la demande. D'une manière générale, oui. C'est-à-dire que pour les ordres et l'exécution du marché, il peut être très utile.
En dehors de cela, il ne reste qu'une partie du temps critique - la transmission du paquet de données sur les canaux de communication. Si vous essayez de repousser la "frontière de l'inconnu" au niveau de "laisser tomber (le paquet) et continuer", vous aurez plus de problèmes que d'avantages.
Eh bien... non. Il faut juste l'utiliser quand les avantages l'emportent sur les problèmes.
À mon avis, tout trader professionnel (conseiller) doit s'assurer que son ordre de transaction est accepté pour exécution par le serveur.
Dans ce cas, l'option asynchrone ne vous convient pas. Tout est soluble.
LeXpert
On recommence, sur les doigts. Structurer grossièrement les retards :
1. Il est temps pour le terminal de pré-vérifier l'ordre de transaction, de l'"emballer" dans le lot sortant et de le placer dans la "file d'attente du réseau".
2. Heure de transmission d'un paquet de données contenant un ordre de transaction du client au serveur.
3. Heure à laquelle le serveur reçoit un ordre de transaction, le place dans le pool de traitement et envoie au client un identifiant unique de ce ticket.
4. Le temps de prétraitement de l'exactitude de l'ordre de transaction et de son placement sur la salle des marchés.
Si j'ai indiqué quelque chose de faux, veuillez corriger. Je comprends que vous ne voulez pas attendre après le premier point ? En revanche, je préconise la disponibilité obligatoire des trois premiers.
Il convient de répondre à deux questions pour poursuivre la discussion :
1. Le rapport proportionnel des retards. C'est-à-dire, en moyenne, le temps en pourcentage que prend chacun des quatre éléments ci-dessus. Si la distribution est, par exemple, "0,5 %-1,0 %-1,0 %-97,5 %", cela ne vaut pas la peine.
2) Le Time-out et son impact sur la stratégie de trading. Franchement, je ne peux pas citer un seul service d'assistance technique qui ne nécessite pas de savoir clairement si une commande a été envoyée au serveur ou non. Ceci est pertinent tant pour l'arbitrage à long terme que pour l'arbitrage multidevises. C'est-à-dire que la garantie d'exécution d'un ordre de bourse ne peut être remise en cause. Veuillez fournir un contre-exemple si vous n'êtes pas d'accord.
À mon avis, la façon la plus simple de résoudre le problème d'exécution lors d'une pause est de ne pas créer de file d'attente d'exécution (annuler l'exécution) et de notifier l'utilisateur de l'annulation lors de la reconnexion. De cette façon, il y aura moins d'ambiguïté.
Un ticket serveur doit être retourné. Cela permettra de s'assurer que la commande atteint le serveur et est acceptée pour traitement.
Construire des pools d'attente astucieux côté client n'est pas seulement une solution peu pratique, je dirais même que c'est un défaut de conception flagrant dans l'architecture client-serveur de MT5.
Les pools d'attente encombrants du côté client ne sont pas une solution élégante.
C'est ce qui a été demandé. Personne ne vous oblige à l'utiliser si vous n'y êtes pas obligé.
LeXpert
On recommence, sur les doigts. Structurer grossièrement les retards :
1. le temps pour le terminal de pré-vérifier l'ordre de bourse, de l'"emballer" dans un paquet expédiable et de le mettre dans la "file d'attente du réseau".
2. Temps d'envoi d'un paquet de données contenant un ordre de transaction du client au serveur.
Heure à laquelle le serveur reçoit un ordre de transaction, le place dans le pool de traitement et envoie au client un identifiant unique de ce ticket.
4. Temps de prétraitement de l'exactitude de l'ordre de transaction et de sa mise en place dans la salle des marchés.
3 est mieux divisé.
3.1 placement
3.2 envoi de l'uid.
Si j'ai indiqué quelque chose de faux, veuillez corriger. Je comprends que vous ne voulez pas attendre après le premier article ?
Oui.
En revanche, je suis favorable à ce que les trois premiers soient obligatoires.
Et si le ping est d'une demi-seconde ? C'est asynchrone. Quel est l'intérêt d'utiliser ce mode ?
C'est ce qui a été demandé. Personne ne vous oblige à l'utiliser si vous n'y êtes pas obligé.
Vous n'avez toujours pas répondu à ma question. Veuillez me donner un exemple concret des cas dans lesquels vous pouvez ignorer la garantie d'exécution des ordres de bourse au profit de la rapidité de leur envoi à différents caractères ?
Vous n'avez toujours pas répondu à ma question. Veuillez me donner un exemple concret de cas où vous pouvez ignorer les garanties d'exécution des ordres de bourse au nom de la rapidité de leur envoi vers différents symboles ?
Pas de problème - négociation de portefeuille + exécution du marché.
Pas de doute : négociation de portefeuille + exécution du marché.
Compte tenu de la vitesse d'exécution requise, vous pourriez être plus précis - arbitrage multidevises. Je ne vois pas d'autre application (peut-être que je ne cherche pas assez ?).
Dans quelle mesure cette technologie est-elle applicable dans la pratique ? Pour autant que je sache, au niveau de la cotation d'une société de courtage, de telles collisions ne se produisent pas. Peut-être, sur ECN... Mais tout de même : 1) mode Kamikaze, 2) événement rare + faible volume. Cela en vaut-il la peine ? J'en doute.