MQL : sécurité ou opportunité - page 7
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
C'est n'importe quoi. Ce n'est pas comme si tu faisais tourner des gigaoctets 24 heures sur 24.
Le système d'exploitation et les processus système ont des ordres de grandeur plus importants à faire avec le disque.
Il y avait une question
komposter:
... ou existe-t-il un logiciel pour le vérifier ?
...Et pour autant que je sache, ce n'est pas la taille, mais l'emplacement du fichier.
Si un fichier réinscriptible en permanence se trouve toujours au même endroit (vous pouvez y réparer l'échange), le disque commencera à s'effriter physiquement à cet endroit précis.
(Une défragmentation hebdomadaire selon un calendrier précis résoudra le problème).
Dans l'ensemble, ce n'est pas vraiment stupide.
C'est n'importe quoi. Ce n'est pas comme si tu faisais tourner des gigaoctets 24 heures sur 24.
Le système d'exploitation et les processus système travaillent beaucoup plus durement avec le disque.
Bonjour Renat, je voudrais préciser ma question sur la notion de sandbox de fichiers dans MT et sur le rôle qui lui est attribué.
Le bac à sable est une permission pour le conseiller expert d'écrire ou de lire quelque chose uniquement dans un endroit limité.
Ceci est fait explicitement dans le but d'assurer la sécurité des données informatiques.
Cela signifie que nous limitons le conseiller expert à un bac à sable, de sorte qu'il est impossible pour un cheval de Troie d'ouvrir un fichier quelconque des données privées du client en dehors du bac à sable.
Sinon, il faudrait l'autorisation explicite d'une DLL pour le conseiller expert.
OK.
Et si vous autorisez le conseiller expert à écrire non pas sur le disque, mais au moins sur des fichiers en mémoire ?
La sécurité de l'utilisateur / du MK est-elle compromise ?
Et si nous autorisons le conseiller expert à écrire non pas sur le disque, mais au moins sur des fichiers en mémoire ?
Cela entraîne-t-il une perte de sécurité pour les utilisateurs et les MC ?
Quel est le besoin pour cela ?
Nous avons donné des fichiers, des pips et des variables globales, tous les experts sur un terminal peuvent communiquer entre eux normalement et sans problèmes. Mais la tâche consistant à "communiquer avec quelqu'un à l'extérieur en mode libre" n'est pas devant nous. Au contraire, notre tâche est de ne jamais laisser l'information s'échapper.
ps : cherchez des solutions de contournement de la méthode de communication entre les terminaux - nous ne le ferons pas.
OK. Merci.
et d'autres questions :
1. pouvez-vous mettre en place des plans de développement - transfert d'informations de l'EA aux agents locaux pendant un test ?
2. une application de place de marché qui utilise Pipes sera-t-elle certifiée ?
1. pouvez-vous mettre en place des plans de développement - transfert d'informations de l'expert aux agents locaux pendant le test ?
Pour commencer, veuillez justifier la nécessité de ce type d'intervention.
À notre avis, il est méthodologiquement incorrect de transmettre des informations supplémentaires à l'EA testé en plus des informations fournies par le testeur (jeu de paramètres et fichiers de données, et même des indicateurs personnalisés que nous fournissons maintenant sur demande).
D'ailleurs, les agents locaux ont accès au dossier partagé de tous les terminaux clients sur cet ordinateur.
Pour commencer, veuillez justifier la nécessité de ce type d'intervention.
À notre avis, il est méthodologiquement incorrect de donner des informations supplémentaires au testeur au-delà de ce qu'il fournit (jeu de paramètres et fichiers de données, et même des indicateurs personnalisés que nous fournissons désormais sur demande).
à titre d'exemple - leur GA
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
dll et du marché.
joo, 2013.04.18 21:51
Vous êtes dans le vrai. <...> et sur ce qui a été discuté 100 fois - le transfert d'informations aux agents et "l'étroitesse du champ" dans le nombre de paramètres optimisés.
<...>1. limiter le nombre de paramètres optimisables.
2. Monocritères d'optimisation (désolé pour cette nouvelle combinaison de mots).
Impossibilité de contrôler le processus d'évaporation du sable.
Ce n'est pas du tout un reproche aux développeurs. Au contraire, c'est une fantaisie pour les développeurs de programmes MQL5 !
<...> si la transférabilité bilatérale apparaît - les problèmes sont résolus. Il ne sera pas nécessaire de mettre en œuvre les trois éléments ci-dessus - tout se développera de lui-même.
D'ailleurs, les agents locaux ont accès au dossier partagé de tous les terminaux clients sur cet ordinateur.
Pour information - nos serveurs en nuage du MQL5 Cloud Network génèrent normalement environ 5 téraoctets de trafic par jour , parfois jusqu'à 10 Tb.
Si l'on laisse entrer dans ce réseau un trafic personnalisé sans restriction avec une garantie d'arriver à chaque agent, alors le réseau ne se sentira pas très bien.
1. J'ose dire que 99,9% du trafic est désormais constitué de données historiques.
2. il n'est pas du tout nécessaire de s'adresser à chaque agent. Je vais vous montrer comment faire ci-dessous.
...
Nous avons donné des fichiers, des pipes et des variables globales,tous les experts sur un terminal peuvent communiquer entre eux normalement et sans problèmes. Mais la tâche consistant à "communiquer avec quelqu'un à l'extérieur en mode libre" n'est pas devant nous. Au contraire, notre tâche est de ne jamais laisser l'information s'échapper.
ps : Il n'est pas nécessaire de chercher des solutions de contournement de la méthode de communication entre les terminaux - nous ne le ferons pas.
Je ne sais pas ce qu'il en est pour tout le monde, mais j'ai dit très clairement tout à l'heure que nous avons besoin d'un échange d'informations dans les deux sens entre les programmes du tableau et les agents. L'extérieur n'est pas nécessaire. C'est-à-dire au sein d'un seul terminal (et des agents qu'il gère). Aucune autre copie courante des terminaux (avec des objectifs différents) n'est impliquée dans l'échange d'informations.
stringo:
Nous pensons qu'il est méthodologiquement incorrect de transmettre à un conseiller expert en cours de test des informations supplémentaires à celles fournies par le testeur(un ensemble de paramètres et de fichiers de données, et des indicateurs personnalisés).
D'ailleurs, les agents locaux ont accès au dossier partagé de tous les terminaux clients sur cet ordinateur.Elle est exactement sur demande. Il ne s'agit pas d'une adresse adressée à l'agent avec transfert d'informations à celui-ci, mais l'agent lui-même prendra un paquet qui lui est adressé uniquement (et par conséquent, le testeur enverra simplement ce paquet au nuage).
Donc, vous avez besoin de quelque chose comme ça :
où expert_opt_param est une propriété standard des programmes comme EA.
Si CustomData s'avère être non initialisée, la passe est ignorée.
Par conséquent, le paquet de données adressé à l'agent doit être pré-créé par le conseiller expert sur le graphique afin que l'agent puisse le recevoir :
où bool OptDataSend() - fonction du langage standard
double CustomData - données de l'utilisateur
int AgentId - identifiant de l'agent, en d'autres termes - numéro de passage en mode "force brute" de l'optimiseur.
Et - comment la sécurité sera-t-elle brisée dans ce cas ? Le tout de manière stricte et sérielle, au sein d'un seul et même bac à sable terminal.
dans un EA est résolu par CFastFile (dans le dossier MQH\Ctrl, recherchez-le).
mais comme le test l'a montré la sortie bitmap vers le graphique par rapport aux objets est une perte de temps. Les règles de CView :)
Je suppose que le test n'est pas très correct.
Tout d'abord, OpenCL n'a pas participé à la création des bitmaps (discutable, bien sûr, pour les gros volumes, cela peut être un avantage pour les petits, mais c'est douteux),
Deuxièmement, l'écriture dans un fichier et la lecture d'un fichier sont beaucoup plus lentes que l'accès à la mémoire (et ici, avec des recalculs fréquents, par exemple 24 fois par seconde, les plus grosses pertes, l'écriture et la lecture d'un fichier 24 fois par seconde et le temps de mesure), c'est juste la perte du 1e bitmap contre 26 étiquettes.
C'est pourquoi je suis en faveur des fichiers virtuels. C'est une solution polyvalente. Vous pouvez l'utiliser dans de nombreux algorithmes.
Urain:
Je suppose que le test n'est pas très correct.
L'écriture et la lecture d'un fichier sont plus lentes d'un ordre de grandeur.
Il n'y a pas eu d'écriture dans le fichier. C'était ResourceCreate.