Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie)
Ok. Pour commencer, nous devons diviser les tâches(type d'expert) en variantes commerciales (via le réseau) et non commerciales sous conditions (au sein du même système OP).
Variante réseau - sans ambiguïté via un serveur supplémentaire, pour la sécurité et la gestion des clients.
Communication intra-système : cartographie, en raison de sa rapidité et de sa fiabilité.
Puisque le terminal conservera la libc jusqu'à ce qu'elle tombe ou se ferme, elle sera une indication de l'état du MT (esclave) lui-même.
Et le protocole ressemblera à quelque chose comme ceci :
Le maître crée un mappu nommé (dont le nom est connu de tous les esclaves), et attend qu'ils lui signalent de commencer le chemin ; ce sera le handle de la fenêtre du conseiller (esclave).
Après l'échange des signaux, un autre est créé où les signaux de négociation sont transmis et, en même temps, la commande de mise à jour de la fenêtre est donnée à chaque esclave.
Après l'exécution du signal, l'esclave doit signaler son exécution, sinon il sera considéré comme gelé et des mesures seront prises pour le faire remonter.
Si l'esclave a déchargé (correctement), il devrait rapporter.
À leur tour, tous les esclaves peuvent surveiller l'état du maître et prendre les mesures nécessaires pour l'améliorer ou déclencher une alarme.
En général, c'est à peu près la même chose.
Pour la communication réseau, voir plus loin.
Faites une version commerciale et mettez-la en avant.
C'est à moi que vous parlez ?
C'est à moi que tu parles ?
Une fois que le signal a été exécuté, l'esclave doit signaler l'exécution, sinon il est considéré comme gelé et des mesures sont prises pour le lever.
S'il est déchargé (correctement), l'esclave doit le signaler.
Ces lignes me rappellent la nécessité de discuter de deux modes de fonctionnement
synchronisation des commandes au niveau des commandes maître->client. Et la synchronisation des signaux au niveau maître->client (avons-nous besoin d'une base de données de signaux, d'un accusé de réception du client, etc.)
Je pense que nous devrions également décider ce qui serait le plus fiable et le moins compliqué en termes de synchronisation et de perte de signaux ou vous devriez mettre en œuvre les deux projets simultanément.
Faites une version commerciale et mettez-la en avant.
Je ne veux pas forcer les choses et je ne le ferai pas. Je fais un moyen, pas une fin. Je le fais pour tout le monde.
ces lignes m'ont rappelé la nécessité de discuter de deux modes de fonctionnement
synchronisation des commandes au niveau des commandes maître->client. Et la synchronisation des signaux au niveau du signal du maître->signal du client (y a-t-il besoin d'une base de données des signaux, d'une confirmation de la réception par le client, etc.)
Je pense que nous devrions également décider ce qui serait plus fiable et moins compliqué en termes de synchronisation et de perte de signaux.
Vous n'avez pas besoin de compliquer les choses, il suffit d'envoyer un signal de contrôle au client à un certain intervalle (disons, une fois par seconde), et s'il n'a pas répondu, alors agir.
Je ne veux pas forcer les choses et je ne le ferai pas. Je fais les moyens, pas la fin. Je le fais pour tout le monde.
Je respecte les gens comme ça, continuez comme ça ! !!
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
- au niveau local
- à distance
Nous envisageons de tout faire en une seule fois, en mode " un serveur - plusieurs clients".
Nous devrons prêter attention à des aspects tels que
- l'option de liaison (fichiers, mémoire pour un local ; sockets, http, serveur intermédiaire, etc. pour un distant)
- aucune charge sur le canal de communication (particulièrement vrai pour la synchronisation à distance)
- fail-safety (restauration du canal en cas de perte)
- Réinitialisation de l'Expert Advisor lui-même en cas de panne du terminal/OS
- Pas de duplication ni de suppression des transactions en cas de perte ou de rétablissement de la connexion.
etc.
Vous devez également tenir compte de deux idéologies
- synchronisation au niveau de la disponibilité des commandes
- synchronisation au niveau de l'envoi de signaux pour ouvrir/fermer des ordres
décrire les avantages et les inconvénients de cette variante pour chacune de nos propositions.
Je souhaite que la discussion nous aide à trouver la meilleure solution pour la fiabilité/simplicité du système.
Je m'occuperai du codage et des tests.
Les résultats peuvent être postés dans la base de code par accord.