Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie) - page 8
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
Pourquoi se donner tant de mal ? Il existe un contrôleur standard pour travailler avec TCP/IP, écrivez un programme séparé pour ce cas. Dans le terminal, l'EA communique avec le programme (au sein d'un même ordinateur, de la manière que vous souhaitez)... et il n'est pas nécessaire de réinventer la roue - d'écouter les ports, tout le monde l'a fait pour vous depuis longtemps.
C'est le but. J'essaie de penser de manière globale. Bien sûr, au départ, vous devez investir davantage dans l'évolutivité. C'est-à-dire que l'objectif est de faire comme pendant 1000h. Et peu importe que seuls quelques-uns l'utiliseront plus tard.
C'est pourquoi j'essaie de choisir maintenant - soit la vitesse et le micro-trafic avec les prises. Ou http et beaucoup de trafic sur la poursuite constante des clients pour une nouvelle portion d'information.
Je pense que la deuxième option est meilleure. Ceux qui ont besoin d'évolutivité, et ils sont très peu nombreux, doivent en tout cas supporter des coûts supplémentaires. Laissez-les également payer pour le trafic correspondant.
Les autres, dans 90% des cas, l'utiliseront avec un petit nombre de clients et la fiabilité de la connexion et donc la fonctionnalité dans ce cas est plus importante que le trafic.
Et dans le premier cas, vous ne pouvez pas obtenir une bonne solution sans une connexion fiable.
C'est le but. J'essaie de penser de manière globale. Bien sûr, au départ, vous devez investir dans une plus grande évolutivité. C'est-à-dire que l'objectif est d'en faire autant que pour 1000h. Et peu importe que seuls quelques-uns l'utiliseront plus tard.
C'est pourquoi j'essaie de choisir maintenant - soit la vitesse et le micro-trafic avec les prises. Ou http et beaucoup de trafic sur la poursuite constante des clients pour une nouvelle portion d'information.
Et si les clients, qui reçoivent l'information, devenaient eux-mêmes des serveurs et la distribuaient à un ensemble de clients ? Comme Skype.
ZS alors nous avons un réseau évolutif, tant qu'il est petit les commandes viennent directement du serveur, dès que le réseau grandit il y a un second échelon, un troisième. Dans ce cas, la charge du serveur n'augmente pas. Le réseau peut être configuré par le ping entre les machines.
Et si les clients qui obtiennent eux-mêmes l'information devenaient des serveurs et la distribuaient à un certain ensemble de clients. Comme dans Skype.
Je viens de regarder les nouvelles)https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
Avec le peer-to-peer, ce serait une solution "révolutionnaire", sans équivalent).
Mais on peut se demander si c'est réaliste et si cela en vaut la peine.
Je viens de regarder les nouvelles)https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
Avec le peer-to-peer, ce serait une solution "révolutionnaire", sans équivalent).
Il faut juste se demander si c'est réaliste et si cela en vaut la peine.
Et si les clients qui reçoivent les informations devenaient eux-mêmes des serveurs et les distribuaient à un certain nombre de clients. Comme dans Skype.
L'option est bonne, mais trop grande :) Je pense que pour la synchronisation des clients avec le maître, faire un échange supplémentaire entre les clients eux-mêmes est redondant.
Même si, bien sûr, chaque client deviendra un mini-serveur pour envoyer les informations reçues, ce qui, en principe, mérite réflexion.
Pourquoi se donner tant de mal ? Il existe un contrôleur standard pour travailler avec TCP/IP, écrivez un programme séparé pour ce cas. Dans le terminal, l'EA communique avec le programme (au sein d'un même ordinateur, de la manière que vous souhaitez)... et il n'est pas nécessaire de réinventer la roue - d'écouter les ports, tout le monde a écouté pour vous depuis longtemps.
Je souhaite ici lancer une discussion à l'échelle du forum entre des personnes qui ont beaucoup appris sur le sujet. Et sur la base des avantages et des inconvénients des technologies pour faire des variantes de copieurs fiables, qui sont stables et résistants au nombre de clients ainsi qu'à la qualité de la connexion et à la charge sur les canaux.
..
Et sur la base des avantages et des inconvénients des technologies pour faire des copieurs fiables, stables et robustes tant au niveau du nombre de clients que de la qualité de la connexion et de la charge des canaux.
Ceux qui sont à l'ordre du jour sont deux risques.
1 ne pas recevoir le signal en raison de problèmes de communication
2 ne pas recevoir le bon message à cause des pertes de bits dans la transmission.
Ensuite, sans communication entre les clients voisins, en recevant trois signaux de sources différentes, vous pouvez faire une réconciliation en douceur et obtenir le vrai message selon le principe "2 sur 3 sont vrais". Un tel système est plus sûr contre les défaillances de communication et les pertes de transmission. Les messages peuvent alors être chiffrés en masques de bits et compressés au minimum (au lieu de transmettre des phrases de type chaîne). Ce qui réduira le trafic du serveur.
Et pour éviter l'échec dû à un voisin défaillant, formez un envoi redondant, par exemple, le client reçoit un signal du serveur et de 4 voisins, mais le signal du serveur et 2 signaux des voisins arrivés en premier sont pris en compte.
Ceux qui sont à l'ordre du jour sont deux risques.
1 ne reçoit pas le signal en raison de défauts de communication
L'absence de communication au niveau du client ne peut être résolue. Elle est soit présente, soit absente. Le serveur est censé avoir une communication à tout moment.
2 ne pas recevoir le bon message en raison de la perte de bits lors de la transmission.
Un message invalide peut être signé avec, par exemple, un hachage. Si le hachage est erroné, le message est relancé par le serveur. Mais généralement, une balise @label@ spéciale à la fin et au milieu d'un fichier indique clairement que le message est complet.
...alors la communication entre les clients voisins est essentielle, ayant reçu trois signaux de sources différentes, il est possible de faire un collationnement bit à bit et de produire un vrai message sur une base de "2 sur 3 correctes". Un tel système est plus sûr contre les défaillances de communication et les pertes de transmission. Les messages peuvent alors être chiffrés en masques de bits et compressés au minimum (au lieu de transmettre des phrases de type chaîne). Ce qui réduira le trafic du serveur.