Copieur de transactions/signaux hautement fiable (discussion et développement de l'idéologie) - page 7
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
OK. Je propose ensuite de prendre la connexion socket comme modèle de travail.
Схема работы синхронизатора:
- Le serveur créera des connexions permanentes par socket avec les clients (la question de l'attribution à chaque client de son propre thread est encore à l'étude).
- le maître-client envoie l'état actuel de ses commandes pendant un événement commercial.
- le serveur sauvegarde ce fichier et l'envoie immédiatement à tous les autres clients (une connexion socket est déjà établie)
- le client reçoit le fichier et change l'état de la commande en fonction des données reçues
- Le dernier fichier enregistré de l'assistant est également envoyé au client lorsqu'un nouveau client se connecte. (pour la synchronisation initiale)
Le principal avantage de ce système est l'économie de trafic:
- Il ne nécessite pas de demandes constantes de la part du client. Il les recevra du serveur selon leur disponibilité.
- De même, le client maître n'enverra des données que lorsque des changements seront détectés.
Protection en cas de perte de connexion
- le client envoie un paquet "Heartbeat" (par exemple, 2 octets) toutes les 5 secondes pour vérifier la communication avec le serveur.
- Le client réinitialise la connexion si le paquet est envoyé sans succès (pas de réponse).
- fait la même chose. Si aucune réponse n'est reçue du client dans les 10 secondes, la connexion par socket est fermée.
Cette connexion présente-t-elle un inconvénient ?
- Par exemple, quel est le nombre maximum possible de connexions de socket disponibles ?
Protection en cas de perte de connexion
- Le client envoie un paquet "Heartbeat" (par exemple, 2 octets) toutes les 5 secondes pour vérifier la communication avec le serveur.
Cela n'est jamais fait lorsqu'on communique via le protocole de transport TCP/IP, car la communication est maintenue automatiquement au niveau de la couche socket, c'est-à-dire par le système d'exploitation. En cas de rupture de connexion, une exception est levée sur le client et son gestionnaire doit spécifier ce qui doit être fait dans un tel cas. En ce qui concerne le serveur, il n'en a rien à faire, car si le client est déconnecté, c'est le problème du client.
- Par exemple, quel est le nombre maximum possible de connexions de socket disponibles ?
Si les connexions sont interrompues et qu'une exception est levée sur le client, une exception doit être levée dans son gestionnaire.
De quelle exception parlez-vous ?
Je parle de la WS2_32.dll. Les sockets habituels de Berkeley (mais en version asynchrone). Je n'y ai vu aucune exception. Vous ne pouvez détecter une panne qu'en essayant d'envoyer/recevoir.
combien de connexions de socket peuvent être faites sur ce port ?
De quelle exception parlez-vous ?
Eh bien, vous n'avez besoin que d'un seul port.Je parle de la WS2_32.dll. Sockets Berkeley ordinaires (mais en version asynchrone). Je n'y ai vu aucune exception. Vous ne pouvez détecter une panne qu'en essayant d'envoyer/recevoir.
Je suis intéressé par le nombre de connexions de socket qui peuvent être attachées à ce port ?
Il n'y a qu'une seule connexion par port. Pour que le client puisse se connecter, il doit connaître l'adresse IP et le numéro de port qui lui sont attribués sur le serveur. Vous pouvez également spécifier un nom de domaine au lieu de l'adresse IP et le socket le résoudra en une adresse IP via le DNS.
Le socket du serveur écoute ce numéro de port pour les connexions des clients. Lorsque le client se connecte, la socket lui donne un autre port du pool de ports libres pour qu'il reste connecté. Le port persistant est ensuite libéré à nouveau et écoute les connexions d'autres clients.
C'est ainsi que sont établies les connexions du protocole de transport TCP/IP. Tout ceci se fait au niveau de la couche socket, c'est-à-dire que le protocole n'a pas besoin d'être programmé - il est standard et est déjà câblé dans la bibliothèque partagée du système d'exploitation.
Lorsqu'un client se connecte, la socket alloue un autre port du pool de ports libres au client pour qu'il reste connecté en permanence.
Yuri, merci pour l'essentiel, mais c'est déplacé. Vous donnez les mauvaises connaissances.
Et celui qui est alloué n'a pas de sens du tout, désolé. Vous appliquez peut-être des concepts de port dans deux hypostases différentes, mais dans ce cas, il vaut mieux travailler dans des concepts acceptés.
quelque chose qui pourrait s'avérer utile pour le développement
improbable. non professionnel.
Et celle qui est surlignée n'a pas de sens, désolé. Vous appliquez peut-être les concepts du port sous deux formes différentes, mais dans ce cas, il vaut mieux travailler avec des concepts acceptés.
Comme on dit, c'est votre propre problème de savoir comment vous appliquez le concept de port. J'ai seulement expliqué comment les ports sont utilisés dans le protocole TCP/IP. Encore une fois, le protocole est standard, c'est-à-dire que je ne l'ai pas inventé.
Ce n'est pas moi qui l'ai inventé.
Bonne chance !
Quel est l'ordre de taille du réseau, combien de clients sont censés être 1000, 100, 10, 1 ?
Parce que votre serveur va vraiment faire faillite avec des milliers de clients.
Quel est l'ordre de taille du réseau, combien de clients sont censés être 1000, 100, 10, 1 ?
Parce que votre serveur va vraiment faire faillite avec des milliers de clients.
C'est le but. J'essaie de penser de manière globale. Bien sûr, il faut prévoir beaucoup d'évolutivité au départ. C'est-à-dire que l'objectif est d'en faire autant que pour 1 000h. Et peu importe que seules quelques personnes l'utilisent par la suite.
C'est pourquoi j'essaie maintenant de choisir et de me décider - soit la vitesse et le micro-trafic avec des prises. Ou http et beaucoup de trafic sur la poursuite constante des clients pour une nouvelle portion d'information.