Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie) - page 2
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
Tout a déjà été pensé, mais je suis désolé, ce n'est pas désagréable.
Dima, je sais, bien sûr, j'ai aussi tout inventé et fait, à la fois localement et à distance sous différentes formes.
Mais je veux juste discuter de ce sujet un peu rebattu, qui, à mon avis, n'a pas du tout été abordé ici dans ce contexte.
Si vous avez quelque chose à dire sur le sujet, parlez-en.
Le client copie ses paramètres et crée un ordre avec un magik égal au ticket original. De cette façon, nous contournons le double réglage.
Après cela, le client doit vérifier l'état de la commande et signaler l'exécution (s'il y a quelque chose à exécuter), ou sa vivacité si la demande est un contrôle.
Au départ, tout se résume au système d'envoi lui-même. Un serveur, plusieurs clients. Si le système fonctionne, vous pouvez charger le reste sur ce squelette.
Lorsque le client se connecte, il envoie une demande de connexion, le serveur renvoie une signature dans un message spécial, par lequel il contrôlera les réponses. La signature n'est pas valide tant que le client ne la renvoie pas avec un message spécial. Lorsque tout est en ordre, il est possible de commencer à communiquer.
Il a donc les signatures de chaque client émises par le serveur (donc non répétées). Le serveur envoie des messages avec des numéros de compteur (il doit stocker les journaux de messages à une certaine profondeur au cas où il doit être répété), les clients reçoivent les messages numérotés et envoient des copies signées au serveur. De cette façon, le serveur sait quel client a perdu le message et peut le renvoyer. Après x répétitions, le serveur cesse d'envoyer ce message, ferme la session avec ce client et commence à attendre que le client demande une nouvelle session.
Le client copie ses paramètres et crée un ordre avec un magik égal au ticket original. De cette façon, nous contournons le double réglage.
Ok. Schéma classique.
Après cela, le client doit vérifier l'état de la commande et signaler l'exécution (s'il y a quelque chose à exécuter), ou sa vivacité si la demande est un contrôle.
Pour éviter de telles complications, la clé variable peut être placée dans le message lui-même.
Au départ, tout se résume au système d'envoi lui-même.
C'est là que le cryptage est essentiel ; lorsque le client se connecte, il envoie une demande de connexion
Je pense qu'il est un peu difficile d'utiliser les signatures. Il suffit d'avoir un login/mot de passe du client, émis une fois et vérifié lors des requêtes.
OK. Schéma classique.
Pourquoi faire ça ? Le serveur ne peut pas affecter le client de toute façon.Veuillez me dire quelle technologie est utilisée pour envoyer et recevoir les données et où le serveur les stocke.
Je ne pense pas que ce soit facile avec les signatures. Il suffit d'avoir un login/mot de passe.
où est la garantie que le message sera reçu ?