Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie) - page 6
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
un schéma d'échange simple : le générateur de signaux place un fichier sur le serveur avec tous ses ordres et positions ouverts, comme dans le terminal. Si au moins un ordre ou une position a changé, il place un nouveau fichier. Dans ce cas, le serveur envoie une nouvelle version du fichier (ou un message avec le contenu complet du fichier), et le client répond qu'il l'a reçu (le serveur doit contenir la liste des clients connectés). Le serveur envoie également le fichier au client à tout moment.
Si le client est rattrapé ou manque un ordre, il peut facilement se rétablir en lisant le fichier terminal du serveur. S'il y a un échange commande par commande, il peut y avoir de nombreuses défaillances et ambiguïtés. Le client peut se resynchroniser pour les diagnostics, par exemple une fois par Xmin s'il n'y a pas eu de changement.
Le trafic n'est pas élevé avec ce système. Vous pouvez donc utiliser SSL ou https même.
Il existe 3 types de messages : donner, recevoir, classer lui-même.
un schéma d'échange simple : le générateur de signaux place un fichier sur le serveur avec tous ses ordres et positions ouverts, comme dans le terminal. Si au moins un ordre ou une position a changé, il place un nouveau fichier. Dans ce cas, le serveur enverra une nouvelle version du fichier (ou un message avec le contenu complet de ce fichier). Il envoie également ce fichier à tout moment à la demande du client.
Si le client est rattrapé ou manque un ordre, il peut facilement se rétablir en lisant le fichier terminal du serveur. S'il y a un échange commande par commande, il peut y avoir de nombreuses défaillances et ambiguïtés. Le client peut se resynchroniser pour les diagnostics, par exemple une fois par Xmin s'il n'y a pas eu de changement.
Le trafic n'est pas élevé avec ce système. Par conséquent, vous pouvez utiliser SSL ou https même.
Ce stratagème est inutile, car le fichier contenant le signal de trading perd très vite de sa pertinence, car les transactions doivent être exécutées à temps. L'option la plus rapide consiste pour le client à maintenir une connexion constante avec le socket du serveur et à attendre l'apparition de signaux de négociation. Une connexion permanente ne gaspille pas de trafic, contrairement aux demandes systématiques, et sa fiabilité est assez élevée.
Comme je l'ai déjà dit, aucune commande n'est nécessaire non plus. Dès qu'un signal de négociation apparaît, le serveur l'envoie aux clients sous la forme d'une seule ligne avec le symbole de terminaison "\n" et attend le suivant. Le client ne doit rien envoyer au serveur, il ne fait que recevoir des signaux.
SSL et https ne sont pas du tout nécessaires. Tout d'abord, le propriétaire du serveur devra enregistrer un domaine et acheter un certificat, puis il devra prolonger tout cela, également de manière payante, afin de pouvoir travailler avec ces protocoles. Et deuxièmement, ces protocoles sont destinés au cryptage des données, pour intercepter des informations dans un flux TCP qui ne pourrait pas être décrypté. La charge du serveur sera énorme s'il compte de nombreux clients, car le cryptage n'est pas halam balam, mais l'opération consistant à élever de grands entiers à des puissances supérieures modulo.
Ce stratagème est inutile, car le fichier de signaux de trading perd rapidement de sa pertinence, les transactions devant être effectuées à temps. L'option la plus rapide consiste pour le client à maintenir une connexion constante avec le socket du serveur et à attendre que les signaux de négociation apparaissent. Une connexion permanente ne gaspille pas de trafic, contrairement aux demandes systématiques, et sa fiabilité est assez élevée.
Comme je l'ai déjà dit, le client n'a pas non plus besoin de commandes. Lorsqu'un signal de transaction apparaît, le serveur l'envoie au client sous la forme d'une seule ligne et attend le suivant. Le client ne doit rien envoyer au serveur, mais seulement recevoir des signaux.
Il n'y a pas de retard, car il est envoyé à tous les clients immédiatement après l'apparition du signal.
La connexion commande par commande permet certainement d'économiser du trafic, mais la fiabilité sera faible. Le client devrait pouvoir obtenir toutes les ordonnances (par exemple, les ordonnances en suspens ou les modifications d'ordonnances) même celles qu'il a manquées pour une raison quelconque.
Il n'y a pas de retard car le message est envoyé immédiatement à tous les clients après l'apparition du signal.
La formule "équipe par équipe" permet bien sûr d'économiser du trafic, mais la fiabilité sera faible. Le client doit pouvoir récupérer tous les ordres (ordres en attente par exemple, ou modifications d'ordres), même ceux qui ont été manqués pour une raison quelconque.
Ok, fais une bosse. Seulement qui fera de telles bêtises - ce n'est pas mon problème.
Mon travail consiste à proposer la meilleure option avec le minimum de charge et de trafic, vous avez le droit de refuser.
SSL et https ne sont pas du tout nécessaires. En premier lieu, le propriétaire du serveur doit enregistrer un domaine et acheter un certificat, puis le renouveler en permanence, ce qui n'est pas non plus gratuit, pour travailler avec de tels protocoles. Et deuxièmement, ces protocoles de cryptage de données, pour intercepter des informations dans un flux TCP ne pouvaient pas les décrypter. La charge du serveur sera énorme s'il compte de nombreux clients, car le cryptage n'est pas halam balam, mais l'opération consistant à élever de grands entiers à des puissances supérieures modulo.
Mais tous les signaux de serveurs non authentifiés existants sont piratés en quelques heures. Bien que le cryptage puisse être inutile))
mais tous les signaux de serveur existants sans authentification peuvent être piratés en quelques heures. Le cryptage peut cependant être inutile)).
1. Pas des heures, mais des millisecondes
2) Qui diable a besoin que ses signaux soient ouverts par quelqu'un d'autre ? Anecdote sur Elusive Joe.
Très bien, faites-en une bosse. Mais qui fera de telles bêtises n'est plus mon problème.
Mon travail consiste à proposer la meilleure option avec une charge et un trafic minimum, vous avez le droit de refuser.
1. Pas des heures, des millisecondes.
2) Qui, putain, a besoin que ses signaux soient couverts ? Anecdote sur Elusive Joe.
Je n'en ai rien à faire, mais les gens qui vendent des signaux pour de l'argent s'énervent ;)) Mais si ce n'est pas important pour ce projet, pas de problème, pas besoin de protection.
Si le client a perdu la connexion, ou a redémarré, et qu'entre-temps des ordres en attente ou des modifications d'ordres sont passés, comment le réparer avec l'échange de commandes telnet ? Je ne sais pas, peut-être que vous pouvez - c'est pourquoi je demande.
Je vous ai déjà dit que vous n'avez pas besoin de la commande telnet, mais vous dites encore des bêtises.
Vous devez dupliquer les fichiers et les télécharger sur un hébergement bon marché en utilisant SendFTP(). Et laisser le client lire les fichiers par FTP avec l'heure de création lorsqu'il était hors de contact.
Je vous ai déjà dit que vous n'avez pas besoin de la commande telnet, mais vous dites encore des bêtises.
Vous devez dupliquer les fichiers et les télécharger sur un hébergement bon marché en utilisant SendFTP(). Et laisser le client lire les fichiers via FTP avec le temps de création qu'il était hors connexion.
C'est-à-dire qu'il n'est pas à vous))
Reshetov:
Protocole Socket sur TCP/IP. Vous pouvez transmettre les signaux sous forme de texte en une ligne par signal, comme "EURUSD Buy 1.0\n", comme via Telnet, car il s'agit de la version la plus primitive qui ne nécessite pas une procédure d'échange complexe, comme dans les protocoles http ou ftp avec un minimum d'analyse syntaxique.
Vous dites à nouveau n'importe quoi - dupliquer l'un avec l'autre quand on peut le faire avec un seul)). Pourquoi s'embêter à stocker des fichiers, quand un seul suffit - le dernier avec l'état actuel de tous les ordres et positions ? Combiner l'échange à la demande du serveur (quand quelque chose a changé sur le compte maître) et à la demande du client (quand il a eu des problèmes ou des incohérences), et ne pas inventer des béquilles supplémentaires. Vous pouvez envoyer non pas l'ensemble du fichier de commande à la demande du serveur, mais seulement ce qui a été modifié et ce sera votre version de "l'échange de commandes".