Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie) - page 2

Nouveau commentaire
 
Integer:
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.

 
sergeev:

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.

 
Pourquoi se donner tout ce mal, la clé variable peut être placée dans le message lui-même.
 
FAQ:

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.

Et quel est l'intérêt de faire ça ? Le serveur ne peut toujours pas affecter le client de quelque manière que ce soit.
 
FAQ:
Pour éviter de telles complications, la clé variable peut être placée dans le message lui-même.
Le serveur doit donc envoyer les clés tout le temps... Cela augmentera le trafic, mais qu'en est-il du trafic, où est la garantie que le message sera reçu ? et cela signifie que le côté serveur aura besoin du journal des clés variables pour chaque message, le programmeur peut s'embrouiller avec tout cela.
 
Urain:

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

Mais dites-nous quelle technologie est utilisée pour envoyer et recevoir. Où le serveur stocke-t-il les données ?

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.
 
sergeev:

OK. Schéma classique.

Pourquoi faire ça ? Le serveur ne peut pas affecter le client de toute façon.

Pourquoi pas ? Il peut. Redémarre l'exp, le terminal. Pas de problème.
 
sergeev:
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.
Le serveur envoie les données au serveur ftp et les clients les récupèrent à partir de là.
 
Urain:
où est la garantie que le message sera reçu ?
Une question importante qui découle de la réponse est de savoir quelle méthode est utilisée pour échanger des données.
123456789
Nouveau commentaire