Who has already tried the Signals subscription to get on the tail of ATC 2012 participants? - page 5

[Andrey Khatimlianskii]

St.Vitaliy:

Think of the milkmaids too.

You can't avoid complaints from the milkmaids, I wrote about it straight away.

[Mikhail Antropov]

Rent a Signal is deflated...
any idea why?

[Vasiliy Sokolov]

Renat:

In addition, there are several other issues to be resolved:

1. what to do with imminent crossing by symbols?
2. what to do with an inevitable deposit overload and guaranteed stops?
3. How do you restore the layout when you lose communication for some time? It's a real copier's nightmare, and then there's the mess of multiple signals
   
4. how to explain the trader the final mess with positions when no one has a chance to prove the correctness of all the rolls?

We purposely simplified the system down to a single signal, getting rid of the worst consequences. Especially taking into account the fact that most of transactions will most likely go through Trusted Execution Token mechanism of cloud servers, which will reduce signal copying delay to a few milliseconds.

Wait a minute, didn't you develop the architecture? Now you're the one who writes about messing with positions and intersection by symbols.

Renat:

There's a non-trading mechanism for replicating trades, it has no loss of connectivity, no synchronisation problem after a reconnect (imagine 15 minutes or 2 hours of no connectivity) and it can be tightly controlled 100% of the time. Also, there's MetaTrader 4 without netting.

And netting as such has nothing to do with it. At one time some people needed to develop an appropriate architecture to make multicurrency work transparently in netting mode. In fact, everything was limited by crude ideas of some enthusiasts, described in articles, devoted to creation of multicurrency, which, because of its complexity and unreliability, is available only to a narrow circle of "initiates". As a result, "thousands of housewives" still choose MT4 just because it has a simple control over each deal and there is no need to worry about which deal should be closed and which stop-loss should be rearranged.

[Vasiliy Sokolov]

Renat:

We purposely simplified the system down to a single signal, getting rid of the worst consequences. Especially since most transactions are likely to go through the Trusted Execution Token mechanism of the cloud servers, which will reduce the signal copy latency to a few milliseconds.

Man, the whole point of signal trading is to create an investment portfolio. Look at the products , A**ri - the very demand for a pool of managers/robots created these services.

[Vasiliy Sokolov]

Renat:

So far you have not presented any solutions to the problems, but only stated that "you have little to do, and in general the task is a cakewalk".

Consider that we have been racking our brains over the problem for much longer. And we did not stop at the first step "well, yes, in theory it can be done".

Actually, the essence of all your comments was reduced to "give and basta, it is theoretically possible, so do not deny, and I am too lazy to go beyond the first step of elaboration".

And what do you think independent developers can do? MT5 is rigidly monolithic. The best they can do is to create another crutch and describe it in the corresponding article. You cannot write a quality system without integrating it into a product. Knowing the problem firsthand, I can say that you cannot do without saving records of states on the server side. And how do you think third-party developers should solve this problem? In the end, they do it the best they can. They create crutches and combinations like MQL5 <-> DLL <--> SQL, which are difficult to maintain and inapplicable to the mass market that you're promoting.

[Renat Fatkhullin]

komposter:

Characteristically, all the constructive stuff from my previous post was ignored )

Unfortunately, there was no constructive input on your part at all. There was only "give-and-take" + one-way statements.

That is, you did not describe how to resolve the conflict of multiple signals and did not give an answer to the question how to recover from a loss of connection.

Also, you don't address the responsibility for imminent conflicts tending towards 100% probability at all. I did not point out for nothing the impossibility of the "I can do it for me, I'll fix it, it's OK" solution for a mass service.

[Vasiliy Sokolov]

As far as the topic is concerned, I can say from my own experience that the problem is very complex and cannot be solved by simple replication. Conventionally it can be divided into three components:

• Signal replication system. It is reduced to receiving signals from the pool of trading robots, with mandatory control of the aggregate position.
• The system of portfolio management. A set of rules, according to which the funds of the joint account are redistributed to the sub-accounts of trading robots.
• The system of money management/risk management. A set of rules and mathematical formulas that control the risk and determine how the portfolio is capitalized.

All this is very difficult to arrange in practice, and besides it would require a serious modification of the existing architecture.

[Renat Fatkhullin]

C-4:

Wait a minute, didn't you design the architecture? Now you yourself are writing about position and character overlap.

I see that few people have really thought about the implementation of processing.

Although, you can understand the train of thought from the statement "Give me a solution, the trader needs it, store the states on the server". It is understandable: to transfer the maximum of problems to others, not to bother, and if something goes wrong - to criticize them for bad implementation.

But if you evaluate the problem from the side of the broker, the system provider, the network infrastructure, and only then the trader, you will see that the proposed solution of signal mixing does not have a reasonable and secure solution.

[Andrey Khatimlianskii]

Renat:

Unfortunately, there has been no constructive attitude at all. There was only "give and take" + one-way statements.

In other words, you did not describe how to resolve conflicts of multiple signals or answer the question of how to recover from loss of communication.

Also, you don't address the responsibility for imminent conflicts tending towards 100% probability at all. I did not point out for nothing the impossibility of the "I can do it for me, I'll fix it, it's OK" solution for mass service.

Ban me for making unsubstantiated statements. Just promise me that you will go for a rest.

[Renat Fatkhullin]

C-4:
And what do you think independent developers can do? MT5 is rigidly monolithic. The best they can do is to create another crutch and describe it in the corresponding article. You cannot write a quality system without integrating it into a product. Knowing the problem firsthand, I can say that you cannot do without saving records of states on the server side. And how do you think third-party developers should solve this problem? In the end, they do it the best they can. They create crutch-type crutches and combinations of MQL5 <-> DLL <--> SQL, that are difficult to maintain and inapplicable to the mass market, that you are praising so much.

You are wrong.

MQL5 is so open and functional that you can do almost anything. There is no need to make crutches with DLL and SQL, it is enough to use file operations and store everything you need on disk. The database of global variables is very stable and is not lost during restarts or crashes.

And there is state storage on the server - it's megs and comments. Learn to use them sparingly.