Problèmes de communication difficiles - page 4
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
Échange de paquets depuis www.alpari-idc.ru [217.74.44.42] par 32 octets :
Réponse de 217.74.44.42 : nombre d'octets=32 temps=152ms TTL=55
Réponse de 217.74.44.42 : nombre d'octets=32 time=138ms TTL=55
Réponse de 217.74.44.42 : nombre d'octets=32 time=163ms TTL=55
Réponse de 217.74.44.42 : nombre d'octets=32 time=163ms TTL=55
Statistiques Ping pour 217.74.44.42 :
Paquets : envoyés = 4, reçus = 4, perdus = 0 (0% de perte),
Temps approximatif de réception-transmission en ms :
Minimum = 138msec, Maximum = 163msec, Moyenne = 154msec
Intéressant comment il s'avère, le ping au serveur (où en plus du serveur du commerçant et le site est situé) alors combien est-il, et à la commande du commerçant est plus grand.
Est-ce normal et de quoi cela dépend-il ?
Je ne suis certainement pas un grand réseauteur, mais la différence est alarmante.....
Posez une question plus précise afin que je puisse la transmettre à mon fournisseur
Montrez à votre ISP les résultats de la commande tracert vers le serveur du broker. Vérifiez s'il est possible de se connecter au serveur du courtier en utilisant uniquement des canaux régionaux. Demandez à votre FAI de vérifier la qualité de votre ligne louée. Il pourrait y avoir quelques problèmes avec le passage d'informations par le port 443.
Il suffit d'envoyer un courriel à support@metaquotes.ru
J'ai également essayé d'envoyer une requête au site d'Alpari.
...il s'avère intéressant d'envoyer un ping au serveur lui-même (où, en plus du serveur commercial, le site web est également hébergé)...
Cela peut s'expliquer par le fait que le serveur de trading et le serveur web sont hébergés sur des serveurs différents.
Les résultats d'aujourd'hui : 16 conseillers experts sur un terminal ont négocié normalement et sans erreur pendant plus de 6 heures. Les experts ont travaillé sur différentes paires de devises. Les ordres des experts ont été exécutés sans délai dans les 1 à 2 secondes suivant l'apparition du tic-tac.
Il me semble que nous mélangeons l'océan avec de l'eau.
Je pense que votre logiciel (MT4) devrait fonctionner avec quelques exigences minimales pour le canal de communication (par exemple la vitesse de mon canal est de 10 kbit/sec, etc.), il serait bon de les publier. Pour un test précis, il serait préférable d'écrire un simple conseiller expert qui ouvrirait et fermerait les ordres toutes les 5 à 10 secondes, c'est-à-dire qu'il ouvrirait un ordre et le fermerait dans 5 à 10 secondes, puis dans 5 à 10 secondes l'ouvrirait à nouveau, etc. Le donner à différents utilisateurs pour qu'ils le testent à titre d'essai (je pense qu'il y aura quelques volontaires) dans différentes régions. Vous obtiendrez alors les informations les plus précises sur le fonctionnement du logiciel sous la forme de journaux de performances. Je l'écrirais bien, mais je ne suis pas doué pour la programmation en MQL pour MT4.
Qu'en pensez-vous ?
J'ai encore une chose. Je n'ai jamais connu de tels mots dans MT3 auparavant. Je ne connaissais pas ces mots dans MT3.
Mais MT3 fonctionne correctement.
Je ne sais pas comment l'utiliser mais je l'utilise depuis un certain temps et je ne sais pas comment le corriger.
Dites quelque chose ! !!! Quand cet outrage prendra-t-il fin !!!!!
cela signifie que le flux de transactions est occupé. vous essayez d'effectuer des transactions à partir d'au moins 2 EAs en même temps.
Mais non, j'échange exclusivement avec des stylos ! Et il n'est même pas possible d'essayer deux commandes en même temps avec les stylos.
Et une autre question, est-ce possible avec MT :
Connexions actives
Nom Adresse locale Adresse externe État
TCP 62.***.**.**:3513 85.192.48.3:6667 ÉTABLI
TCP 62.***.**.**:3621 212.65.93.10:1950 ÉTABLI
TCP 62.***.**:3692 212.65.93.12:443 ÉTABLI
TCP 62.***.**:3693 217.74.44.32:443 ÉTABLI
Veuillez noter que deux serveurs sont actifs en même temps (deux dernières lignes) et qu'un seul terminal MT4 est actif. Et un MT3.
Votre situation est reproduite comme suit :
1. Envoyez une demande d'ouverture d'une commande.
2. Attendez un moment pour une réponse.
3. ne pas attendre et appuyer sur le bouton "annuler la commande" et fermer la fenêtre.
4. rouvrir la fenêtre de négociation et essayer de négocier.
Comme votre ordre précédent n'a pas encore été traité (et qu'il a été accepté par le serveur), vous recevrez le message "Trade context is busy". La raison pour laquelle le traitement de l'ordre prend autant de temps dépend de votre courtier, pas de nous.
1. Envoyez une demande d'ouverture d'une commande.
2. Attendez un moment pour une réponse.
3. n'attendez pas et cliquez sur "annuler la commande" et fermez la fenêtre.
4. rouvrir la fenêtre de négociation et essayer de négocier.
Comme votre ordre précédent n'a pas encore été traité (et qu'il a été accepté par le serveur), vous recevrez le message "Trade context is busy". La raison pour laquelle le traitement de l'ordre prend autant de temps dépend de votre courtier, pas de nous.
Si nous acceptons le point 4, alors le premier ordre devrait être exécuté. Et la seconde, parce que le serveur traite la première demande, ne l'est pas. C'est vrai ?
Je suis assis chez moi - un modem56k (autre fournisseur) - les devis se déroulent normalement, mais je ne peux pas passer de commande - Pas de connexion. Il s'avère que c'est seulement 3-4 fois.
Je n'ai jamais eu une telle chose dans MT3.