Comment puis-je accéder à la dinde à distance ? - page 5
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
и не должно наблюдаться.
дело в том, что эксперт вообще не сможет ходить чаще чем в 1 секунду за информацией. Так уж работают связки МT4 <-> wininet.dll<-> сервер.
Ну будет клиент долбить сервак запросами через каждую секунду. Ну и что? на то он и сервак, чтоб любой груз выдерживать. Представте как гуглы долбятся или вконтакте.
Я тестировал для проверки на 20 машинах + на каждой запущено по 3 терминала в этих связках запрос-ответ причем запросы при прогоне из тестера!
И вполне здорово себя чувствовали все участники эксперимента (и провайдер тоже :). Единственное, что медленно тест происходит. Тик обрабатывается раз в секунду. Но и это не такая большая проблема.
Поэтому такие системы (в которых некий блок кода вынесен в интернет) вполне рабочие.
Pour que le test fonctionne correctement dans une telle combinaison, je déverse simplement les données dans un fichier séparé avec un horodatage dans le nom du fichier. Par conséquent, après la première exécution, le testeur empile toutes les données dans le répertoire. La deuxième exécution est encore plus rapide que si les données étaient dans la base de données sur la machine locale. Cependant, il peut y avoir un grand nombre de fichiers.
А чтобы тест нормально отрабатывался в такой связке, я данные просто сбрасываю в отдельный файл с timestamp в названии файла. В итоге после первого прогона тестер складывает все данные в директории. Второй прогон уже летит даже быстрее чем если бы эти данные были в базе данных на локальной машине. Правда файлов может оказаться довольно много.
en principe comme une option... est juste quelque chose entre prendre toutes les données en une fois ou un peu à la fois mais souvent.
L'essentiel est que plus l'ensemble des tâches est précis, plus on a de chances de l'optimiser en termes de vitesse.
Par exemple, pour une ligne d'indicateur, 250000 barres*8 octets (heure de la barre) + 8 octets (valeur de la ligne) ~ 4 mb d'informations.
1. Le temps n'est pas nécessaire pour tous les indicateurs.
2. Les citations peuvent être compressées. Le temps peut aussi être compressé))))
3. il n'est pas nécessaire de transmettre toutes les cotations à chaque fois. Il existe une variante plus économique. Pendant l'initialisation, l'indicateur se connecte au serveur et transmet un grand nombre de données. Le serveur renvoie un identifiant associé à l'ensemble des données reçues et au client qui a reçu ces données. Pendant que l'indicateur fonctionne, il envoie périodiquement des informations sur la barre de zéro afin de corriger la lecture actuelle sur celle-ci. Lorsque la barre se ferme, l'indicateur doit envoyer les dernières informations sur la barre au serveur qui renverra la valeur de la barre fermée. Lorsque la connexion est désinitialisée/rompue, le serveur libère l'identifiant alloué et détruit l'ensemble de données (ou non, comme on le souhaite).
4. En outre, l'indicateur peut mettre en cache, côté client, les valeurs reçues de l'indicateur (elles peuvent être stockées avec le bloc de données compressées, selon lequel elles sont calculées).
UPD : Vous ne pouvez pas recalculer l'indicateur sur tous les ticks, car très souvent les ticks sont dans le flux de +1 -1 -1 +1 -1 -1 - vous avez vraiment besoin de calculer l'indicateur seulement 2 fois.
1. Время нужно не для всех индикаторов.
Oui, mais nous parlons maintenant d'un cas général.
2. Les citations peuvent être compressées. Le temps peut aussi être compressé))))
Lance-moi une idée.
3. il n'est pas nécessaire de transmettre toutes les cotations à chaque fois. Il existe une variante plus économique. Pendant l'initialisation, l'indicateur se connecte au serveur et transmet un grand nombre de données. Le serveur renvoie un identifiant associé à l'ensemble des données reçues et au client qui a reçu ces données. Pendant que l'indicateur fonctionne, il envoie périodiquement des informations sur la barre de zéro afin de corriger la lecture actuelle sur celle-ci. Lorsque la barre se ferme, l'indicateur doit envoyer les dernières informations sur la barre au serveur qui renverra la valeur de la barre fermée. Lorsque la connexion est désinitialisée/rompue, le serveur libère l'identifiant alloué et détruit l'ensemble de données (ou non, comme on le souhaite).
La façon dont il peut accélérer le transfert de données sur la ligne induite n'est pas très claire.
4. En outre, l'indicateur peut mettre en cache, côté client, les valeurs d'indicateur reçues (elles peuvent être stockées avec le bloc de données compressées, selon lequel elles sont calculées).
similaire à la façon dont elle est déjà implémentée dans MT - IndicatorCounted(). Je prescrirais ma propre fonction similaire à de telles fins.
UPD : Il se peut que vous ne recalculiez pas du tout l'indicateur sur tous les ticks, car très souvent les ticks sont dans le flux de +1 -1 -1 -1 -1 -1 - en fait vous ne devez calculer l'indicateur que 2 fois.
En d'autres termes, nous avons commencé à résoudre un problème pour les inducteurs. Synchronisation et transmission des barres d'histoire :)
Nous devrions peut-être leur proposer de créer un tel service pour nous !
C'est une idée intéressante. Laissez le serveur stocker un instrument avec un prix ouvert/fermé/haut/bas égal. Et les volumes aussi. Il sera téléchargé et synchronisé selon les règles générales, comme toutes les devises. Et il peut alors être utilisé comme une ligne d'inducteurs.
Il peut être intéressant de creuser dans cette direction dans la documentation technique de la synchronisation des barres.
1) faire une capture d'écran du graphique avec l'indicateur
2) Téléchargez le fichier de capture d'écran sur votre serveur HTTP.
3) Les utilisateurs se connectent en utilisant leurs identifiants/mots de passe et regardent l'image.
Mais cela n'est bon que si vous n'avez besoin que de regarder l'indicateur. :(
3. il n'est pas nécessaire de transmettre tous les devis à chaque fois. Il existe une variante plus économique. Pendant l'initialisation, l'indicateur se connecte au serveur et transmet un gros morceau de données. Le serveur renvoie un identifiant associé à l'ensemble des données reçues et au client qui a envoyé ces données. Pendant que l'indicateur fonctionne, il envoie périodiquement des informations sur la barre de zéro afin de corriger la lecture actuelle sur celle-ci. Lorsque la barre se ferme, l'indicateur doit envoyer les dernières informations sur la barre au serveur qui renverra la valeur de la barre fermée. Lors de la désinitialisation/rupture de la connexion, le serveur libère l'identifiant alloué et détruit l'ensemble de données (ou pas, selon votre préférence).
Variante dégoûtante - au démarrage, tout le système ralentit avec le terminal ou vous devez attendre très longtemps pour charger (certains systèmes utilisent encore des canaux lents, par exemple les boules à mites). Il est préférable de télécharger les informations par petits morceaux et de sauvegarder l'historique sur la machine de l'utilisateur afin que seules les informations récentes soient envoyées au trafic, comme c'est le cas dans les dernières versions : http://xrust.land.ru/download/.
Подкиньте идейку
Le premier élément de la série est stocké explicitement. Ensuite, nous différencions les séries et utilisons le codage entropique.
Variante dégoûtante
Même dans le cas de DLL, il est souhaitable de donner l'information par morceaux pour que le consommateur n'ait pas à attendre ("POURQUOI ?"), et c'est agréable au final :).
Même dans le cas de DLL il est souhaitable de donner l'information par morceaux pour que le consommateur ne souffre pas d'une longue attente ("Pourquoi ?"), et c'est beau au final :).
Le chargement en arrière-plan/asynchrone tel que je le comprends implique.C'est ce que je dis...