Comment se protéger contre la copie des transactions longues du testeur ? - page 2
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
J'ai rapidement pensé, écrire le fichier et lire l'heure de sa création, mais là encore un utilisateur sournois peut transférer l'heure de l'ordinateur.
ZS : si pour le quadruple, lire le fichier historique, rechercher la dernière barre (zéro) et arrêter le test n barres avant la dernière barre.
mais même dans ce cas, un utilisateur astucieux (avec une connaissance supérieure à la moyenne du terminal) peut ajouter un historique pour N barres )
ZS : oui, le plus simple est d'obtenir le nombre de barres sur le graphique(iBars), à partir du temps actuel, soustraire le temps de la première (la plus à gauche) et lorsque la différence sera inférieure ou égale à n barres pour arrêter le test.
Bien que les iBars ne fonctionnent pas, vous devez regarder dans le fichier historique.
pensée rapide, écrire le fichier et lire l'heure de sa création, mais là encore l'utilisateur rusé peut passer outre l'heure de l'ordinateur.
Exactement. C'est le seul moyen de connaître le temps réel de l'ordinateur du testeur. C'est comme ça que je fais.
Mais, l'utilisateur peut transférer le temps comme vous l'avez dit correctement.
Alexandr Bryzgalov:
ZS : si pour le quadruple, alors lire le fichier historique par lequel les hiboux commencent, chercher la dernière barre (zéro) et arrêter le test pour n barres avant la dernière.
Quels paramètres doivent être insérés et où ? TimrCurrent() - heure du serveur. Dans le testeur, il s'agit de l'heure d'arrivée des ticks sur l'heure du serveur. Tant que j'écris des hiboux à l'heure locale de l'ordinateur jamais attaché.
Dimitri, le défi consiste à arrêter le traitement des ticks dans le testeur avant la date réelle. Pour cela, vous devez connaître cette date réelle. Le testeur ne peut le trouver que de la manière décrite ci-dessus - par une opération de fichier. Mais si un utilisateur rusé avance l'heure sur l'ordinateur, l'opération sur le fichier ne donnera pas non plus l'heure réelle, mais l'heure décalée.
Le problème, en fait, est que si l'expert travaille sur la trame de temps M5 et plus (un problème spécial sur le quotidien) - il devient possible de l'exécuter dans un testeur de stratégie et de lire la dernière action, en la transférant à un autre terminal et de ne pas acheter un EA, en utilisant seulement la version de démonstration.
Pas bon. Dans le testeur de stratégie, l'historique n'est pas donné dans son intégralité, mais par ticks, et il est impossible d'"arrêter le testeur en quelques barres". Et l'ouverture du fichier d'historique est une option avec une DLL auto-écrite, ce que nous voudrions éviter. Si c'est avec la DLL, alors la demande d'heure depuis Internet me semble la plus fiable.
N'y a-t-il aucun moyen de connaître la date finale de l'épreuve ?
signifiait que l'EA cessait de répondre aux signaux.
Même si c'était le cas, ça ne fait rien. La tâche est de trouver l'heure actuelle réelle du testeur sans utiliser l'API.
Si vous pouviez - tout est résolu.
L'heure actuelle du testeur est trouvée au moyen d'une opération de fichier. Il s'agit bien sûr d'une perversion, mais cela fonctionne vraiment.
Si quelqu'un a des idées sur la fin du temps de test du testeur, merci de les partager.