Qui a déjà essayé l'abonnement Signals pour se mettre à la remorque des participants à l'ATC 2012 ? - page 5
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
Pensez aussi aux laitières.
Rent a Signal se dégonfle...
Vous savez pourquoi ?
En outre, il y a plusieurs autres questions à résoudre :
Nous avons délibérément simplifié le système en le réduisant à un seul signal, en nous débarrassant des pires conséquences. Surtout si l'on tient compte du fait que la plupart des transactions passeront très probablement par le mécanisme de jeton d'exécution de confiance des serveurs en nuage, ce qui réduira le délai de copie du signal à quelques millisecondes.
Attendez une minute, n'avez-vous pas développé l'architecture ? Maintenant, c'est vous qui écrivez qu'il faut jouer avec les positions et les intersections par symboles.
Il existe un mécanisme de réplication des transactions, il n'y a pas de perte de connectivité, pas de problème de synchronisation après une reconnexion (imaginez 15 minutes ou 2 heures d'absence de connectivité) et il peut être étroitement contrôlé 100 % du temps. Il y a aussi MetaTrader 4 sans filet.
Nous avons délibérément simplifié le système en le réduisant à un seul signal, en nous débarrassant des pires conséquences. D'autant que la plupart des transactions sont susceptibles de passer par le mécanisme de jeton d'exécution de confiance des serveurs en nuage, ce qui réduira la latence de la copie du signal à quelques millisecondes.
Jusqu'à présent, vous n'avez présenté aucune solution aux problèmes, mais vous avez seulement déclaré que "vous n'avez pas grand-chose à faire et que, en général, la tâche est un jeu d'enfant".
Considérez que nous nous creusons les méninges sur ce problème depuis bien plus longtemps. Et nous ne nous sommes pas arrêtés à la première étape "bien, oui, en théorie, c'est faisable".
En fait, l'essence de tous vos commentaires se réduisait à "donnez et basta, c'est théoriquement possible, donc ne niez pas, et je suis trop paresseux pour aller au-delà de la première étape d'élaboration".
Comme d'habitude, tous les éléments constructifs de mon message précédent ont été ignorés.)
Malheureusement, il n'y a eu aucune contribution constructive de votre part. Il n'y avait que des "concessions" et des déclarations à sens unique.
En d'autres termes, vous n'avez pas décrit comment résoudre le conflit de signaux multiples et n'avez pas répondu à la question de savoir comment récupérer après une perte de connexion.
De plus, vous n'abordez pas du tout la responsabilité des conflits imminents qui tendent vers une probabilité de 100%. Je n'ai pas souligné pour rien l'impossibilité de la solution "je peux le faire pour moi, je vais le réparer, c'est bon" pour le service de masse.
En ce qui concerne le sujet, je peux dire d'après ma propre expérience que le problème est très complexe et ne peut être résolu par une simple réplication. Conventionnellement, elle peut être divisée en trois composantes :
Tout cela est très difficile à mettre en œuvre dans la pratique et nécessiterait en outre une modification importante de l'architecture existante.
Attendez une minute, ce n'est pas vous qui avez conçu l'architecture ? Maintenant, vous écrivez vous-même sur le chevauchement de la position et du caractère.
Je constate que peu de personnes ont réellement réfléchi à la mise en œuvre du traitement.
Bien que l'on puisse comprendre le cheminement de la pensée à partir de la déclaration "Donnez-moi une solution, le commerçant en a besoin, stockez les états sur le serveur". C'est compréhensible : transférer le maximum de problèmes aux autres, ne pas s'en préoccuper, et si quelque chose ne va pas - les critiquer pour une mauvaise mise en œuvre.
Mais si vous évaluez le problème du côté du courtier, du fournisseur du système, de l'infrastructure du réseau, et seulement ensuite du côté du trader, vous verrez que la solution proposée du mélange de signaux n'a pas de solution raisonnable et sûre.
Malheureusement, il n'y a pas eu d'attitude constructive du tout. Il n'y avait que des "concessions" et des déclarations à sens unique.
En d'autres termes, vous n'avez pas décrit comment résoudre les conflits de signaux multiples ni répondu à la question de savoir comment récupérer après une perte de communication.
De plus, vous n'abordez pas du tout la responsabilité des conflits imminents qui tendent vers une probabilité de 100%. Je n'ai pas souligné pour rien l'impossibilité de la solution "je peux le faire pour moi, je vais le réparer, c'est bon" pour le service de masse.
Et que pensez-vous que les développeurs indépendants puissent faire ? MT5 est rigidement monolithique. Le mieux qu'ils puissent faire est de créer une autre béquille et de la décrire dans l'article correspondant. Vous ne pouvez pas écrire un système de qualité sans l'intégrer dans un produit. Connaissant le problème de première main, je peux dire que vous ne pouvez pas vous passer de la sauvegarde des enregistrements d'états du côté du serveur. Et comment pensez-vous que les développeurs tiers devraient résoudre ce problème ? Au final, ils font du mieux qu'ils peuvent. Ils créent des béquilles et des combinaisons de MQL5 <-> DLL <--> SQL, difficiles à maintenir et inapplicables au marché de masse, que vous encensez tant.
Vous avez tort.
MQL5 est tellement ouvert et fonctionnel que vous pouvez faire presque tout. Il n'est pas nécessaire de faire des béquilles avec DLL et SQL, il suffit d'utiliser les opérations sur les fichiers et de stocker tout ce dont on a besoin sur le disque. La base de données des variables globales est très stable et n'est pas perdue lors des redémarrages ou des plantages.
Et le stockage d'état sur le serveur est constitué de medgies et de commentaires. Apprenez à les utiliser avec parcimonie.