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

 
Urain:
J'ai fait un peu de recherche. Exemples de systèmes client-serveur simples dans différentes langues.

et en un mot, quelle est votre proposition ?

- La synchronisation se fait-elle sur un socket ?
- L'état complet du compte principal est transmis ?

 
sergeev:

et en bref, quel type de proposition faites-vous ?

- La synchronisation se fait-elle sur un socket ?
- l'état complet du compte principal est-il transmis ?

Et dans le cadre du contexte serveur-client, où se situe le serveur par rapport aux clients ?

Désolé de partir, je serai de retour dans une heure.

 
Urain:
Qu'en est-il du contexte serveur-client, où se situe le serveur par rapport aux clients ?
.

ok. précisons davantage.

nous avons un serveur distant auquel l'assistant envoie ses données.

Les clients sont également connectés au même serveur.


La question est de savoir quelle méthode est utilisée pour recevoir/transmettre les informations. A partir des suggestions actuelles socket/http/ftp

quels sont les avantages et les inconvénients de ces technologies pour la charge et le trafic des serveurs ?

 
sergeev:

OK. Réduisons encore le problème.

Nous avons un serveur distant auquel l'assistant envoie ses données.

Les clients sont également connectés au même serveur.


La question est de savoir quelle méthode est utilisée pour recevoir/transmettre les informations. A partir des suggestions courantes socket/http/ftp

Quels sont les avantages et les inconvénients de ces technologies pour la charge et le trafic des serveurs ?

Socket sur TCP/IP. Il est possible de transmettre des 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 de procédure d'échange complexe, comme dans les protocoles http ou ftp avec un parsing minimum.

Le problème est que le serveur doit être multithreadé, sinon comment peut-il recevoir simultanément les connexions des clients ? Il doit écouter en permanence son propre socket sur le port alloué et, en cas de connexion, transférer un client sur un autre port libre et lui allouer un thread séparé. Il doit ensuite attendre un autre client sur le port principal.

 
sergeev:

ok. précisons davantage le problème.

nous avons un serveur distant auquel le maître envoie ses données.

Les clients sont également connectés au même serveur.


La question est de savoir quelle méthode est utilisée pour recevoir/transmettre les informations. A partir des suggestions courantes socket/http/ftp

Avantages et inconvénients de ces technologies pour la charge et le trafic des serveurs ?

Socket, http/ftp donne simplement accès à des fichiers distants, alors que socket est un protocole d'échange de données.
 
Urain:
Socket, http/ftp donne simplement accès à des fichiers distants, alors que socket est un protocole d'échange de données.

Une socket n'est pas un protocole. Un socket est un socket, c'est-à-dire le genre de chose sur un port qui reçoit et transmet des données. Une socket peut être une socket serveur et doit avoir un port fixe sur lequel elle écoute. Et il existe un socket client qui se connecte aux serveurs en utilisant l'IP et le numéro de port du serveur.

Et FTP, HTTP, Telnet sont des protocoles. Les fichiers peuvent être transférés à l'aide de ces trois protocoles. Mais telnet est un protocole de flux, pas une chose ponctuelle, c'est pourquoi les clients peuvent l'utiliser autant qu'ils le souhaitent et lorsqu'un signal commercial apparaît, vous pouvez l'obtenir immédiatement. Avec les autres protocoles, il faudrait tout le temps perturber le socket du serveur pour savoir s'il y a un signal ou non, et ensuite tomber.

 
Reshetov:

Une socket n'est pas un protocole. Un socket est un socket, c'est-à-dire le genre de chose sur un port qui reçoit et transmet des données. Un socket peut être un socket serveur et doit avoir un port fixe sur lequel il écoute. Et il existe un socket client qui se connecte aux serveurs par IP et numéro de serveur.

Et FTP, HTTP, Telnet sont des protocoles. Les fichiers peuvent être transférés à l'aide de ces trois protocoles. Mais telnet est un protocole de flux, et non un protocole ponctuel, c'est pourquoi les clients peuvent s'y accrocher aussi longtemps qu'ils le souhaitent et lorsqu'un signal commercial apparaît, ils peuvent l'obtenir immédiatement. Avec les autres protocoles, il faudrait tout le temps perturber le socket du serveur pour savoir s'il y a un signal ou non, et ensuite tomber.

Existe-t-il des exemples pour Telnet ? Très intéressant.
 
Urain:
Existe-t-il des exemples pour Telnet ? Très intéressant.
https://ru.wikipedia.org/wiki/Telnet
 
Je l'ai vu avant de poser la question, c'est difficile d'appeler ça un exemple d'utilisation, mais merci quand même, c'est une idée intéressante, je vais devoir creuser un peu.
 
Urain:
Je l'ai vu avant la question, c'est difficile d'appeler ça un exemple d'utilisation, mais merci quand même, c'est une idée intéressante, il faudra que je creuse.

Il s'agit essentiellement d'un protocole basé sur le texte. Mais il est principalement utilisé pour les connexions Unix distantes sur le port 23. C'est-à-dire que vous pouvez vous connecter à un serveur Unix distant avec votre nom d'utilisateur et votre mot de passe et exécuter des commandes du système d'exploitation.

Sous une forme simplifiée, telnet peut être utilisé pour n'importe quoi, y compris la transmission de signaux de négociation sous forme de messages d'une seule ligne. C'est-à-dire aucune commande ou autre chose. Le client se connecte et attend que le serveur envoie le signal. Il reçoit, analyse, ouvre ou ferme des positions et attend le prochain signal. C'est tout le protocole.