Highly reliable transaction/signal copier (ideology discussion and development)
Ok. To start with, we need to divide the tasks(type of expert) into commercial (via network), and conditionally non-commercial variant (within the same OP system).
Network variant - unambiguously through additional server, for security and client management.
Intra-system - communication: mapping, because of speed and reliability.
Since the terminal will hold the libc until it drops or closes, it will be an indication of the state of the MT (slave) itself.
And the protocol will look something like this :
The master creates a named mappu (whose name is known to all slaves), and waits for them to signal to start the path this will be the advisor (slave) window handle.
After the signals are exchanged, another one is created where the trading signals are passed and at the same time the command for update of the window is given to each slave.
After the signal is executed the slave should report about its execution or it will be considered as frozen and measures are taken to bring it up.
If the slave has unloaded (correctly), it should report back.
In turn any of the slaves can monitor the status of the master and take the necessary action to raise it, or to issue an alarm.
Generally about the same.
For network communication, see later.
Make a commercial version and push it.
Are you talking to me?
Are you talking to me?
Once the signal has been executed, the slave must report the execution, or it is deemed to be frozen and steps are taken to raise it.
If it is unloaded (correctly), the slave should report it.
These lines remind me of the need to discuss two modes of operation
order synchronisation at the master->client order level. And signal synchronization on master->client level (do we need a signal database, acknowledgement of receiving from client, etc.)
I think we should also decide what would be more reliable and less complicated in terms of synchronization and loss of signals.
Make a commercial version and push it.
I don't want to push anything and I won't. I'm making a means, not an end. I do it for everyone.
these lines reminded me of the need to discuss two modes of operation
order synchronization at master->client order level. And signal synchronization at the level master's signal->client's signal (is there a need in a signal database, confirmation of receiving from the client, etc.)
I think we should also decide what would be more reliable and less complicated in terms of synchronization and loss of signals.
You do not need to complicate things, it is enough to send a control signal to the client at a certain interval (say, once a second), and if he did not respond, then act.
I don't want to push anything and I won't. I do the means, not the end. I do it for everyone.
I respect people like that, keep it up!!!
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
- locally
- remotely
We are planning to do all at once in a one server - many clients mode.
We will need to pay attention to such aspects as
- the link option (files, memory for a local one; sockets, http, intermediate server, etc. for a remote one)
- no load on the communication channel (especially true for remote synchronisation)
- fail-safety (restoration of the channel in case of its loss)
- Reinitialization of the Expert Advisor itself in case of a terminal/OS failure
- No duplication/no deletion of deals if connection is lost/restored
etc.
You also need to consider two ideologies
- synchronization on the level of order availability
- synchronization on the level of sending signals to open/close orders
describe the advantages and disadvantages of this variant for each of our proposals.
I would like the discussion to help us find the best solution for the system reliability/simplicity.
I will do the coding and testing.
The results may be posted in codebase by agreement.