Bottom-Up Approach - Architecture-wise
Yes, you can simplify the problem and make MT4 Node, which is immediately connected by a peer to your current C # strategy.
This helped me organize cluster computing , communicating a massive parallel with a crowd of MT4 nodes.
MT4 can become anEventFEED -er Node with a more sophisticated “scalable formal message processing scheme” in a very smart way.
Do you want to have a CLI interface for the MT4 node (s) command - one as anEventFEED -er, the other as anXtoACTOR Node - selectively, with the syntax and grammar of the CLI instructions (not to mention test-automation, etc.)?
Do you want to have a central < syslog daemon to load HFT traffic loaded by MT4 node (s) and automate + administer monitoring and script maintenance tasks?
Do you want the external GPU engine / cluster engine to interact with the client / server using MT4 EA based on per-tickEvent?
The basics of ZeroMQ and / or nanomsg will allow you to design and develop many-to-many (node-based) and any-to-any (language implementation systems).
MT4 / MQL4 has a direct intelligent shell for ZeroMQ →> thanks to Austen Conrad on GitHub MQL4ZMQ
ZeroMQ →> thanks to the large team, there are many language bindings - C / C ++, Python, Java, R, even Erlang, ...
Thus, your project can start in an abrupt manner and is not dependent on any specific network gridlock (DLL moving sands et al)
Engineering built-in features save a lot of time and effort and do not reinvent the wheel