MQL : sécurité ou opportunité
Bon poste.
Renat vient souvent dire que vous ne voyez rien et ne comprenez rien depuis votre bac à sable.
Bon poste.
À ces habituellement venir Renat et dire que vous ne voyez pas la merde et ne comprennent pas de votre bac à sable.
Attendons de voir.
ZS. Ce serait une bonne idée d'organiser un vote, ce n'est pas une question futile.
ZS.ZS. Cela s'applique également au quatuor.
Le besoin est là. Et un tel besoin se manifeste dans les tâches les plus intéressantes.
Hors sujet, mais profitant de l'occasion, je vous rappelle queResourceRead() était autrefois promis.Cela permettrait au moins aux experts à l'intérieur du terminal d'échanger de grandes quantités d'informations.
Tout développeur peut créer n'importe quelle solution pour lui-même et transmettre vers/depuis ses terminaux ce qu'il veut. Mais nous n'allons pas faire un trou standard, et nous ne ferons pas un trou standard mondial pour 100% de tous les terminaux. De plus, nous ne ferons pas de connexions http sur le réseau.
Dans les prochaines versions, il y aura une nouvelle méthode d'interaction réseau personnalisée avec les serveurs commerciaux, qui permettra aux courtiers et aux développeurs sur MQL4/5 d'étendre la fonctionnalité du terminal avec un support sur les serveurs où les handlers sont écrits dans des plugins.
Dans les prochaines versions, il y aura une nouvelle méthode d'interaction réseau personnalisée avec les serveurs commerciaux qui permettra aux courtiers et aux développeurs sur MQL4/5 d'étendre la fonctionnalité du terminal avec un support sur les serveurs où les handlers sont écrits dans des plugins.
J'ose dire que l'organisation du peiime bidirectionnel fera essentiellement de MT5 un simple lien de transmission entre les applications tierces et la bourse. Dans ce cas, l'apparition de soi-disant nouveaux programmes indépendants - des adaptations au terminal - en fait, des concurrents directs de MQ qui parasitent leurs technologies et promettent de rendre le travail sur les marchés financiers "encore plus pratique et productif" pour seulement 29,95 $ par mois est inévitable.
Exactement.
Plus important encore, chaque premier programme sera essentiellement un logiciel espion et collectera de nombreuses informations essentielles sur les comptes, l'historique et les paramètres des comptes. Les développeurs tiers n'ont aucun frein sur cette question - ils ne se soucient pas de la sécurité et de la destruction de la vie privée. Ils ne "comprennent pas" vraiment quel est le problème. Lorsque vous les attrapez, ils se rebiffent jusqu'à la dernière minute, puis cela se résume à "vous nous prenez notre argent durement gagné, alors que nous vous aidons depuis tant d'années !". Sans parler des violations de nos droits, des licences et du piratage pur et simple.
Nous en avons vu assez de ce genre d'"aide" et nous renforçons donc les règles.
Pouvez-vous développer ce point ?
Un courtier (ou un développeur tiers) peut écrire un programme en MQL4/MQL5 pur et l'inclure légalement dans son paquet de distribution (nous l'inclurons dans son paquet de distribution) et configurer des graphiques par défaut avec des indicateurs et des EA prédéfinis. Nous ne sommes pas contre l'inclusion de programmes personnalisés (basés sur du code pur MQL4/MQL5 uniquement, sans DLL et sans fanatisme) dans leur propre distribution de courtiers.
Ce programme peut mettre en œuvre sa propre fonctionnalité, prise en charge par le serveur de négociation. À cette fin, un plugin pour MetaTrader 4/5 Server API est écrit pour le serveur, qui peut recevoir et répondre aux paquets de commande personnalisés envoyés par les programmes MQL4/MQL5 dans le terminal.
Ainsi, un courtier peut étendre les capacités du terminal sans sacrifier la sécurité de ses clients et sans violer les licences du système. Les développeurs tiers ont une nouvelle possibilité de vendre leurs solutions en toute légalité et en interne.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
En analysant mes années d'expérience avec MQL et en essayant de les faire correspondre à mes besoins, j'ai réalisé que
La pierre d'achoppement la plus fréquente, qui apparaît d'une tâche à l'autre, est l'échange d 'informations dans les deux sens.
C'est simple : l'ancienne hache du MQL - il n'y a qu'un seul moyen d'obtenir des informations du conseiller expert, c'est-à-dire des fichiers sur le matériel. Qui, selon les normes actuelles, sont les outils primitifs du travail acharné du programmeur.
Une prise de conscience de ce fait n'est pas de trop pour comprendre l'orientation du développement nécessaire.
Et combien de codes ont été pelletés à la recherche d'autres variantes de transmission de l'information !
Mais toutes se résument à l'utilisation d'outils non-MQL... Malheureusement.
Échange d'informations entre les terminaux et entre les terminaux et d'autres applications, envoi de données à un site, envoi d'informations à des agents ou d'agents à l'EA - nous tous, chers utilisateurs et développeurs, pouvons poursuivre cette liste.
Au cours des années de notre pratique active du MQL, presque tous les outils système possibles ont été adaptés et testés à nouveau :
- envoi légal de courrier, FTP, messages Push
- fichiers en dehors du dossier du terminal
- cartographie
- pips
- les prises
Les tuyaux sont présentés par les développeurs comme une technologie d'échange d'informations mais, pour une raison quelconque, ils sont utilisés sous une forme tronquée. Les pipes dans MQL ne peuvent être que du côté client.
Je suis surpris et j'ai une question : pourquoi est-ce seulement côté client ? C'est un truc de "noir unijambiste" ici...
En essayant d'analyser cette limitation en termes de sécurité, je suis arrivé à la conclusion que non, le server-pipe MQL n'a aucun effet sur la sécurité. Puisque dans ma version actuelle le fichier exe du serveur auto-écrit est indispensable, ce n'est pas sûr pour autant.
Peut-être que les développeurs sont trop paresseux ? Pas vraiment, ils les soutiennent et les développent activement...
-----
Il y a plus d'un an, Renat m'a recommandé de porter le système winsock2 vers MQL sans aucune dll auto-écrite (j'ai partiellement décrit comment cela a été fait dans l' article).
Le code MQL a été utilisé pour upend le serveur + le convertir en mode non bloquant + le polluer avec un timer de millisecondes (encore tel à l'époque) pour accepter les clients + les servir avec le même timer...
Renat a déclaré à l'époque que, pour "certaines" raisons techniques, cela était impossible. Mais il s'est avéré que c'est même le contraire - tout est possible et même au maximum !
Il a créé le serveur expert directement sur le graphique, et s'y est connecté à partir de n'importe quel ordinateur sur Internet - c'était une percée dans la technique d'exploitation. Ciblage direct de la connexion p2p, des copieurs, des synchroniseurs, des optimiseurs, des tâches distribuées, etc.
-----
Pour en revenir à ma question sur la poursuite du développement du MQL, j'aimerais la résumer de la manière suivante :
Chers développeurs, quand passerons-nous, vous et moi, de l'ancien fichier à un outil beaucoup plus confortable, plus rapide et meilleur - la technologie client/serveur ?
Après tout, le fait d'avoir donné des pips au client - cela signifie automatiquement une sortie irrévocable du bac à sable. Car le piping client dans MQL implique un piping serveur auto-écrit, et c'est tout simplement hors de question.
PS.
Récemment, à titre d'exemple, un sujet important a été soulevé concernant le transfert d'informations aux agents locaux. C'est un autre appel au réveil pour vous. Il y a beaucoup de sujets de ce type et chaque utilisateur de MQL essaie de les résoudre en fonction de ses connaissances.
Jusqu'à présent, je n'avais pas compris l'importance des outils intégrés de MQL pour l'échange d'informations. Je n'ai pas pris en compte le niveau d'exigence.
Mais l'analyse de ces sujets me conduit à une conclusion claire : l'échange d'informations dans les deux sens doit se faire !
Le temps est venu de rassembler les pierres.