Comment se protéger contre la copie des transactions longues du testeur ? - page 7

 
Dmitry Fedoseev:
Je l'ai essayé maintenant. Ça marche. Je l'ai essayé dans MT4 en mode testeur et en mode expert.
Voici donc la solution, qui a été proposée à la première page du fil de discussion. L 'auteur a répondu que WebRequest n'est pas exécuté dans le testeur.
 
Dmitry Fedoseev:
Je l'ai essayé maintenant. Ça marche. Je l'ai essayé dans MT4 dans le testeur, dans l'expert.
Il s'agit alors de la solution la plus fiable.
 
Il y a un hic. Dans le fichier hosts, nous pouvons faire une redirection.
 
Dmitry Fedoseev:
Il y a un hic. Dans le fichier hosts, nous pouvons faire une redirection.
Mais le protocole de communication avec le serveur peut être caché ou crypté. À quoi cela servirait-il si un attaquant parvenait à usurper le serveur, car il ne saurait pas comment communiquer avec le logiciel.
 
Vasiliy Sokolov:
Mais le protocole de communication avec le serveur peut être caché ou crypté. À quoi cela servirait-il si un attaquant parvenait à usurper le serveur, car il ne saurait pas comment communiquer avec le programme.
Il faut inventer quelque chose.
 
Vasiliy Sokolov:

Le problème n'est pas aussi simple qu'il n'y paraît à première vue. On peut suggérer ce qui suit (suivez la pensée) :

  1. Pour la première exécution, le conseiller expert effectue des transactions dans le testeur de stratégie jusqu'à la date de protection dans celui-ci (ou un mois avant cette date, les conditions sont à la discrétion de l'auteur).

Oui, cela me semble être une bonne option. A mon avis, on ne devrait même pas prendre le fichier, mais utiliser une variable globale. Nous y cryptons la date de la dernière citation dans le testeur.

Lorsque nous le lançons dans le testeur, nous lisons cette variable globale et traitons les ticks soit à la date, qui est rigidement écrite dans l'EA (s'il n'y a pas de variable globale), soit au mois précédant la date cryptée, mais nous obtenons toujours des ticks et mettons à jour la variable globale en fonction du dernier tick.

Merci, je vais essayer cette variante, je l'aime beaucoup.

 
Dmitry Fedoseev:
Il y a un hic. Dans le fichier hosts, nous pouvons faire une redirection.

Le fait que WebRequest ne fonctionne pas dans le testeur - je ne l'ai appris que dans l'aide, je n'ai pas essayé de demander des données.

La redirection dans le fichier hosts est inutile, alors qu'il faut répondre aux demandes. C'est-à-dire que la quantité de travail est sensiblement différente - qu'il s'agisse simplement d'avancer l'heure ou d'organiser une tricherie par le biais d'un faux serveur de temps.

De même, je n'aime pas WebRequest précisément à cause des actions de résolution supplémentaires. Non, la variante proposée par Vasiliy Sokolov me semble la plus prometteuse.

 
George Merts:

Non, l'option proposée par Vasiliy Sokolov me semble la plus prometteuse.

L'option infaillible, si vous le souhaitez, peut être contournée en modifiant l'heure dans les barres du fichier historique...
 
Honnêtement, les gars, je pense que vous auriez dû commencer la discussion sur ce sujet pour rien. Je pense que beaucoup de gens ne pensaient même pas qu'il était possible de le faire avant, et ici vous avez discuté de tout cela et donné aux gens une excellente idée et un moyen de mettre en œuvre la façon de ne pas payer pour les conseillers travaillant sur les anciennes TF.
 
Alexandr Bryzgalov:
Protection du fou, si vous voulez elle peut être contournée en changeant l'heure dans le fichier de la barre d'historique...

C'est loin d'être stupide ou paresseux)).

Imaginez le nombre de manipulations qu'il faudrait effectuer :

1. Ecrivez un script qui remplace les heures des barres dans l'historique.

2. se déconnecter d'internet, afin que les nouvelles barres réelles ne soient pas mélangées aux barres substituées.

3. Exécutez le script, en substituant les heures.

4. Commencez les tests. Obtenez la direction du commerce.

5. Exécutez le script pour ramener les temps de barre à la normale.

6. Connectez-vous à l'Internet.

Ce n'est plus un "cadeau"...