FORTS. Questions relatives à l'application de la loi - page 110
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
En termes de praticité, oui, c'est utile, mais il est difficile d'imaginer la lenteur du terminal à essayer de tout synchroniser... et je ne suis pas sûr que l'arrivée asynchrone de ces données ait un sens.
Cela ne ralentira pas du tout, les tables sont traitées de toute façon :)
Et la saisie d'un nouveau champ ne prendra pas de temps du tout (il est de toute façon consacré au traitement des tables).
Le serveur MT5 reçoit un paquet de 22 tables et afin de remplir les champs de la structureMqlBookInfo
il est nécessaire de "parcourir" les 22 tableaux (la direction est le dernier champ) !
Cela ne ralentira pas du tout, les tableaux sont traités de toute façon :)
Et la saisie d'un nouveau champ ne prendra pas de temps du tout (il est de toute façon consacré au traitement des tables).
Le serveur MT5 reçoit un paquet de 22 tables et afin de remplir les champs de la structureMqlBookInfo
vous devez "passer" par les 22 tables (direction - dernier champ) !
Si cela n'affecte pas la productivité, bien sûr, laissez-le faire.
Cependant, comment l'utiliser, car il est très difficile de traiter chaque événement de manière synchrone, c'est-à-dire que lorsque nous sommes informés de l'occurrence d'un événement, il peut être trop tard pour agir. À moins qu'il ne s'agisse de négocier des actions ou des contrats à terme lents. Je veux dire, le slippage sur les stops sur le marché est phénoménal - la dernière fois c'était 61 points à l'ouverture... et à en juger par les ticks, plus de 1000 lots ont été échangés en 24 ms.
mais il est difficile d'imaginer comment le terminal pourrait alors ralentir en essayant de tout synchroniser...
Le terminal n'a pas besoin de synchroniser quoi que ce soit... Il suffit de la donner au moment où la mise à jour arrive (ou avec un délai fixe). Ou même simplement donner en deux flux : un flux pour les tiques et un flux pour les perles. Mais avec l'heure exacte d'arrivée des deux, pour qu'ils puissent être amenés ensemble.
Il y aura de la valeur dans tous les cas !
Les gars !
La structureMqlBookInfo est remplie à partir de la table 22 (ou de FORTS_FUTORDERBOOK_REPL - Futures : Tranche de verre) !
Nous ajoutons le champ MOMENT et le remplissons simplement à partir de cette même table !
Pas de perte de temps, pas besoin de synchroniser quoi que ce soit, tout fonctionnera de la même manière qu'avant, seule l'heure sera modifiée.
apparaîtra ! TOUT !
Êtes-vous sûr que tous les événements sont maintenant affichés dans la coupe ? En général, ils sont traités, car il peut y avoir un filtre - disons pas plus de 100 événements par seconde. Et, probablement, le moment arrive de toute façon, mais il n'est tout simplement pas disponible pour l'utilisateur, sinon comment dessiner les mouvements dans la tasse ? Mais, s'il y a beaucoup de mouvements et qu'ils sont déjà obsolètes, alors peut-être sont-ils simplement rejetés par le filtre.
Comment est-il possible de vérifier cela ? Avec quoi pouvons-nous le vérifier ? Pas moyen, ou des idées ?
Êtes-vous sûr que tous les événements sont maintenant affichés dans la coupe ? En général, ils sont traités, car il peut y avoir un filtre - disons pas plus de 100 événements par seconde. Et, probablement, le moment arrive de toute façon, mais il n'est tout simplement pas disponible pour l'utilisateur, sinon comment dessiner les mouvements dans la tasse ? Mais, s'il y a beaucoup de mouvements et qu'ils sont déjà obsolètes, alors peut-être sont-ils simplement rejetés par le filtre.
Comment est-il possible de vérifier cela ? Avec quoi vérifier ? Pas possible, ou avez-vous une idée ?
Voulez-vous que je vous donne les spécifications du Plaza 2 ?
Lisez-le si vous êtes intéressé, peut-être comprendrez-vous comment tout cela fonctionne.
Ajouté
Mais en résumé.
L'échange produit des flux de données, mais nous ne pouvons pas les obtenir en temps réel, mais nous obtenons des "tranches" de ces flux.
avec un délai assez négligeable.
Une autre possibilité est de savoir pourquoi MQ ne veut pas faire de corrections et d'innovations.
Ils avaient besoin de réécrire rapidement le serveur MT5 pour CGate, afin de pouvoir embaucher...
pour la mise en œuvre de CGate.
Et ce n'est pas 2 lignes de code et il faut être très sérieux à ce sujet.
Ajouté par
J'ai essayé plusieurs fois d'écrire mon propre connecteur Plaza2, mais j'ai échoué (pas assez de cervelle).
Êtes-vous sûr que tous les événements sont maintenant affichés dans la coupe ? En général, ils sont traités, car il peut y avoir un filtre - disons pas plus de 100 événements par seconde. Et, probablement, le moment arrive de toute façon, mais il n'est tout simplement pas disponible pour l'utilisateur, sinon comment dessiner les mouvements dans la tasse ? Mais, s'il y a beaucoup de mouvements et qu'ils sont déjà obsolètes, alors peut-être sont-ils simplement rejetés par le filtre.
Comment est-il possible de vérifier cela ? Avec quoi vérifier ? Il n'y a aucun moyen, ou avez-vous une idée ?
Qu'ils fassent au moins une confirmation de tous les échanges. C'est-à-dire pour que le marché puisse confirmer les transactions passées. Cela signifie une précision à la milliseconde près. C'est tout, pas plus, ce qui est moins - laissez-les agréger/résumer/filtrer/découper, peu importe. Il faut juste que l'heure de la coupe soit aussi précise que l'heure actuelle.
Les gars, j'ai besoin de conseils sur la façon de fixer des limites sur les Forts, il y a un code, quand une position apparaît, le robot au-dessus et en dessous du prix met des ordres limites avec indentation.
Je veux savoir si j'ai normalisé correctement le prix du retrait pour les limiteurs ou si je dois utiliser la bibliothèque intégrée ou mieux normaliser le prix séparément.
Merci.
Créez un fil de discussion séparé.