Hi All
I'm in the process of coding a trade copier/duplicator and I'd like to extend it so that it allows a single master on computer A to copy trades to any number of slaves on any number of other computers (computer B, C, D, etc). I know there are plenty of folks here who are familiar with how to do this properly, so I'd like to pick your brains.
The single computer version is much easier since it does not involve networking. One way to do this is as follows: The master MT4 runs and has a master EA running. Every time the master opens a new trade, the master sends this information to some sort of persistent storage (a file, a SQL database, etc) or sends the information directly to the slave via a communication channel (pipes or even local sockets). The master EA start() command can run every tick. On the slave side, we need the slave to respond very quickly to changes, so we probably do not want to wait for the next tick for start to run. So the slave EA start() method is probably in an infinite loop (testing for IsStopped() of course) with a sleep() command inside this loop to control how frequently the loop iterates. Inside the loop, the slave reads the file/DB/comm channel, extracts the information, and replicates any trade changes made by the master.
Before moving on, let me ask some questions:
1) Is it always necessary for speed to have the client EA run in a loop like this? Doesn't this mean that the client EA does not show up as running in the top right hand corner of the chart (since the first call to start() never terminates)?
2) Regardless of whether we are talking about a local EA trade copier or a networked trade copier, there are two ways of sending information from master to slave. One way is to just send updates (eg open a trade, close a trade, modify a trade, etc). Another way is to send an entire "state" rather than just changes to the state. In other words, if the master has 3 trades open and closes one trade, the "state" method sends information on all trades on the master. The slave jut changes its own number of trades to exactly match the master. The state approach is more robust, since the slave will keep working until it matches the master. In the update approach, it is possible for the slave to encounter some problem with executing the change so its state will be out of sync with the master. On the other hand, the update approach requires far less CPU usage/traffic etc since only changes of state are ever sent out. My question is this: what do folks recommend for which approach to use? Is there a way to get the robustness of the state approach without burning up the CPU?
Now on to the networked version: Obviously the network comm must be accomplished inside a DLL written in C/C++/C# etc. (I tend to prefer C or simple C++ or even Java through JNI). I am guessing that the master will create server sockets and the slaves will all have client sockets. If this were reversed and the master had client sockets that connected to slave server sockets, there would be several problems such as: 1) the master would have to explicitly know which slaves it is communicating with, 2) slaves on a PC behind a firewall might have problems receiving signals, etc. Am I on the right track so far?
Assuming the slave is the client, the problem is that the master will send out trade changes at random times, and the slave must respond as fast as possible. So does this mean the slave's client socket must be open at all times, waiting for information to be sent asynchronously from the master? Wouldn't the client have to periodically check/ping the socket to make sure it is still alive? Or would the client be constantly opening checking and closing a server socket connection inside the clients infinite loop discussed above? It seems to me that this latter approach would probably be slow and inefficient (it takes some time to open a socket).
Also, aren't there some blocking issues so any calls to socket functions should be done inside their own threads?
I'd love to hear more about strategies to handling these issues from anyone who has gone down this road before.
I'm in the process of coding a trade copier/duplicator and I'd like to extend it so that it allows a single master on computer A to copy trades to any number of slaves on any number of other computers (computer B, C, D, etc). I know there are plenty of folks here who are familiar with how to do this properly, so I'd like to pick your brains.
The single computer version is much easier since it does not involve networking. One way to do this is as follows: The master MT4 runs and has a master EA running. Every time the master opens a new trade, the master sends this information to some sort of persistent storage (a file, a SQL database, etc) or sends the information directly to the slave via a communication channel (pipes or even local sockets). The master EA start() command can run every tick. On the slave side, we need the slave to respond very quickly to changes, so we probably do not want to wait for the next tick for start to run. So the slave EA start() method is probably in an infinite loop (testing for IsStopped() of course) with a sleep() command inside this loop to control how frequently the loop iterates. Inside the loop, the slave reads the file/DB/comm channel, extracts the information, and replicates any trade changes made by the master.
Before moving on, let me ask some questions:
1) Is it always necessary for speed to have the client EA run in a loop like this? Doesn't this mean that the client EA does not show up as running in the top right hand corner of the chart (since the first call to start() never terminates)?
2) Regardless of whether we are talking about a local EA trade copier or a networked trade copier, there are two ways of sending information from master to slave. One way is to just send updates (eg open a trade, close a trade, modify a trade, etc). Another way is to send an entire "state" rather than just changes to the state. In other words, if the master has 3 trades open and closes one trade, the "state" method sends information on all trades on the master. The slave jut changes its own number of trades to exactly match the master. The state approach is more robust, since the slave will keep working until it matches the master. In the update approach, it is possible for the slave to encounter some problem with executing the change so its state will be out of sync with the master. On the other hand, the update approach requires far less CPU usage/traffic etc since only changes of state are ever sent out. My question is this: what do folks recommend for which approach to use? Is there a way to get the robustness of the state approach without burning up the CPU?
Now on to the networked version: Obviously the network comm must be accomplished inside a DLL written in C/C++/C# etc. (I tend to prefer C or simple C++ or even Java through JNI). I am guessing that the master will create server sockets and the slaves will all have client sockets. If this were reversed and the master had client sockets that connected to slave server sockets, there would be several problems such as: 1) the master would have to explicitly know which slaves it is communicating with, 2) slaves on a PC behind a firewall might have problems receiving signals, etc. Am I on the right track so far?
Assuming the slave is the client, the problem is that the master will send out trade changes at random times, and the slave must respond as fast as possible. So does this mean the slave's client socket must be open at all times, waiting for information to be sent asynchronously from the master? Wouldn't the client have to periodically check/ping the socket to make sure it is still alive? Or would the client be constantly opening checking and closing a server socket connection inside the clients infinite loop discussed above? It seems to me that this latter approach would probably be slow and inefficient (it takes some time to open a socket).
Also, aren't there some blocking issues so any calls to socket functions should be done inside their own threads?
I'd love to hear more about strategies to handling these issues from anyone who has gone down this road before.
i will do beta test too
