MQL: security vs opportunities
Good post.
Renat usually comes to these and says you can't see shit and don't understand from your sandbox.
Good post.
At these usually come Renat and say that you do not see shit and do not understand from your sandbox.
Let's wait and see.
ZS. It would be a good idea to hold a vote, it's not an idle question.
ZS.ZS. This also applies to the Quartet.
The need is there. And such a need arises in the most interesting tasks.
Off-topic, but taking the opportunity, I remind you thatResourceRead() was once promised.It would at least allow the experts inside the terminal to exchange large amounts of information.
Any developer can make any solutions for themselves and transmit to/from their terminals whatever they want. But we are not going to make a standard hole, and we will not make a standard global hole for 100% of all terminals. Moreover, we won't make network http connections.
In the next builds, there will be a new method of custom network interaction with trade servers, which will allow brokers and developers on MQL4/5 to extend the terminal's functionality with support on servers where handlers are written in plugins.
In the next builds, there will be a new method of custom network interaction with trade servers that will allow brokers and developers on MQL4/5 to extend the terminal functionality with support on servers where handlers are written in plugins.
I dare say that the organization of the two-way paim will essentially make MT5 only a transferring link between third-party applications and the exchange. In this case, the appearance of so-called new independent programs-adaptations to the terminal - in fact, direct competitors of MQ parasitizing on their technologies and promising to make work in the financial markets "even more convenient and productive" for only $ 29.95 per month is inevitable.
Exactly.
More importantly, every first program will be essentially spyware and collect a lot of critical information about accounts, history and account settings. Third party developers have no brakes on this issue - they don't care about security and privacy destruction. They genuinely "don't understand" what the problem is. When you catch them, they rebuff to the last minute, and then it comes down to "you're taking away our hard work, while we've been helping you for so many years!". This is not to mention violations of our rights, licences and outright hacking.
We have seen enough of this kind of "help" and are therefore tightening the rules.
Can you elaborate on this point?
A broker (or a third-party developer) can write a program in pure MQL4/MQL5 and legally include it in their distribution package (we will include it in their distribution package) and set up default charts with preset indicators and EAs. We are not against inclusion of customized programs (based on pure MQL4/MQL5 code only, without DLL and without fanaticism) in their own distribution of brokers.
This program can implement its own functionality, supported by the trading server. For this purpose, a plugin for MetaTrader 4/5 Server API is written for the server, which can receive and respond to custom command packets sent from MQL4/MQL5 programs in the terminal.
Thus a broker can expand the capabilities of the terminal without sacrificing the security of their clients and without violating licenses of the system. Third-party developers have a new opportunity to sell their solutions legally and in-house.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Analyzing my years of experience with MQL and trying to match it with my needs, I realized
The most frequent stumbling block, which appeared from task to task, was a two-way exchange of information.
It's simple: the ancient axe of MQL - there is only one way to get information from the Expert Advisor, that is files on the hardware. Which, by present standards, are the primitive tools of hard work of the programmer.
A realization of this fact is not too little to understand the direction of necessary development.
And how much code was shoveled over in search of other variants of information transmission!
But all of them boil down to the use of non-MQL tools... Unfortunately.
Exchange of information between terminals and between terminals and other applications, sending data to a site, sending information to agents or from agents to EA - all of us, dear users and developers, can continue this list.
Over the years of our active practice in MQL, almost every possible system tool has been adapted and re-tested:
- legal sending of mail, FTP, Push messages
- files outside the terminal folder
- mapping
- pipes
- sockets
Pipes are given by the developers as an information exchange technology but for some reason they are used in a truncated form. Pipes in MQL can be client-side only.
I'm surprised and have a question: why is it only client-side? It's a "black one-legged" thing here...
Trying to analyze this limitation in terms of security, I've reached the conclusion that no, the MQL server-pipe has no effect on security. Since in my current version the self-written server exe file is a must, it's not safe all the same.
Maybe the developers are too lazy? Not really, they actively support and develop them...
-----
Over a year ago Renat recommended me to port system winsock2 to MQL without any self-written dll (I partially described how it was done in the article).
The MQL code was used to upend the server + convert it to non-blocking mode + poll it with millisecond timer (still so at the time) of accepting clients + serving them with the same timer...
Renat said at the time that for "some" technical reasons this was impossible. But it turned out even the opposite - everything is possible and even to the maximum possible!
Made the expert server directly on the chart, and connected to it from any computer on the internet - it was a breakthrough in operating technique. Direct targeting to p2p connection, copiers, synchronisers, optimisers, distributed tasks, etc.
-----
So getting back to my question about the further development of MQL, I'd like to summarize it this way:
Dear developers, when will you and I make the step from the ancient file, to a much cozier and faster and better tool - as a client/server technology?
After all, the fact that you've given client pips - that automatically means an irrevocable exit from the sandbox. For client piping in MQL implies self-written server piping, and it's just out of it.
PS.
Recently, as an example, an important topic was raised about transferring information to local agents. This is another wake up call for you. There are a lot of such topics and each MQL user tries to solve them according to his knowledge.
Until now I haven't understood the importance of MQL's built-in tools for exchanging information. I haven't considered the level of requirements.
But the analysis of such topics leads me to a clear conclusion - the two-way information exchange must be done!
The time has come to gather the stones.