高信頼性トランザクション/シグナルコピー機 (アイデア検討・開発)
オッケーです。まず、タスク（専門家の種類）を、商業的（ネットワーク経由）なものと、条件付きで非商業的（同じOPシステム内）なバリエーションに分ける必要があります。
ネットワークバリアント - セキュリティとクライアント管理のために、追加のサーバーを介して一義的に定義されます。
システム内通信：スピードと信頼性から、マッピング。
端末が落ちるか閉じるまでlibcを保持するため、MT（スレーブ）自体の状態を示すことになる。
そして、プロトコルは次のようなものになります。
マスターは、名前付きmappu（その名前はすべてのスレーブに知られている）を作成し、これがアドバイザー（スレーブ）ウィンドウハンドルになるパスを開始するためにそれらを合図するのを待ちます。
シグナルを交換した後、売買シグナルを受け渡す別のものを作成し、同時にウィンドウの更新コマンドを各スレーブに与える。
信号が実行された後、スレーブはその実行を報告する必要があり、さもなければフリーズしたとみなされ、それを起こすための措置が取られる。
スレーブが（正しく）アンロードしていれば、報告されるはずです。
スレーブはマスターの状態を監視し、マスターの状態を上げる、あるいはアラームを発するために必要なアクションをとることができる。
概ね同じです。
ネットワーク通信については、後述します。
製品版を作ってプッシュしてください。
私に言っているのですか？
私に言ってるの？
信号が実行されると、スレーブはその実行を報告しなければならず、さもなければフリーズしたとみなし、その信号を上げるための措置をとる。
アンロードされていれば（正しく）、スレーブはそれを報告するはずです。
このセリフから、2つのモードについて議論する必要性を感じます。
マスター->クライアントオーダーレベルでオーダー同期を行います。また、マスター->クライアントレベルの信号同期（信号データベースが必要か、クライアントからの受信確認が必要か、など）
同期や信号消失の面で、より確実で手間がかからないのは何か、ということも決めておく必要があると思います。
製品版を作ってプッシュしてください。
何も押し付けないし、押し付けない。 目的ではなく、手段を作っているのです。 みんなのためにやっているんです。
というセリフがあり、2つのモードについて議論する必要性を感じました。
マスター->クライアントオーダーレベルでオーダー同期を行う。また、マスターの信号→クライアントの信号というレベルでの信号の同期（信号データベースやクライアントからの受信確認などに必要性があるかどうか）。
また、同期や信号の消失など、より信頼性が高く、手間がかからないものは何かということも決めておくべきだと思います。
複雑にする必要はなく、一定間隔（例えば1秒に1回）でクライアントに制御信号を送り、応答がなければ動作させればよい。
何も押し付けないし、押し付けない。 私は手段であって、目的ではありません。 みんなのためにやって いるんです。
そういう人を尊敬します！！！これからもよろしくお願いします。
- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
- 現地で
- 余すところなく
1サーバ-多クライアントモードで 一気にやる予定です。
などに注目する必要がありそうです。
- リンクオプション（ローカルならファイル、メモリ、リモートならソケット、http、中間サーバなど）。
- 通信路に負荷がかからない（特にリモートシンクロに有効）
- フェールセーフ
- 端末/OS障害時のExpert Advisor本体の再初期化について
- 接続が切れたり回復したりしても、案件を重複させない/削除しない
など
また、2つのイデオロギーを 考慮する必要があります。
- オーダーアベイラビリティレベルのシンクロナイズ
- 注文の開始と終了のシグナルを送信するレベルでの同期化
は、それぞれの提案について、このバリアントのメリットとデメリットを説明します。
システムの信頼性／簡便性の観点から、最適な解決策を見出すための議論をお願いしたい。
コーディングとテストは私が行います。
結果は、合意によりcodebaseに掲載することがあります。