高信頼性トランザクション/シグナルコピー機 (アイデア検討・開発) - ページ 6 123456789 新しいコメント Avals 2012.02.16 05:38 #51 シンプルな交換スキーム：シグナルジェネレーターは、ターミナルと同様に、そのすべてのオープンオーダーとポジションを含むファイルをサーバーに配置します。少なくとも1つのオーダーまたはポジションが変更されている場合、新しいファイルを配置します。この場合、サーバは新しいバージョンのファイル（またはファイルの全内容を含むメッセージ）を送信し、クライアントはそれを受信したことを返信する（サーバには接続されているクライアントのリストが含まれているはずである）。また、サーバーはいつでもクライアントにファイルを送信することができます。 クライアントが巻き込まれたり、注文を取り逃がしたりしても、サーバーの端末ファイルを読めば簡単に復旧することができる。コマンド単位でのやりとりがある場合、クラッシュや曖昧な部分が多くなる可能性があります。クライアントは診断のために再同期することができます（例：変化がない場合、Xminに1回）。 この方式ではトラフィックは高くありません。だから、SSLやhttpsでもいいんです。 メッセージには、「与える」「受け取る」「ファイルそのもの」の3種類があります。 Yury Reshetov 2012.02.16 05:45 #52 Avals:シンプルな交換スキーム：シグナルジェネレーターは、ターミナルと同様に、そのすべてのオープンオーダーとポジションを含むファイルをサーバーに配置します。少なくとも1つのオーダーまたはポジションが変更されている場合、新しいファイルを配置します。この場合、サーバーは新しいバージョンのファイル（またはこのファイルの全内容を含むメッセージ）を送信します。また、クライアントからの要求があれば、このファイルを随時送信する。 クライアントが巻き込まれたり、注文を取り逃がしたりしても、サーバーの端末ファイルを読めば簡単に復旧することができる。コマンド単位でのやりとりがある場合、クラッシュや曖昧な部分が多くなる可能性があります。クライアントは診断のために再同期することができます（例：変化がない場合、Xminに1回）。この方式ではトラフィックは高くありません。そのため、SSLやhttpsでも大丈夫です。取引は時間内に実行されなければならないので、取引シグナルを含むファイルはすぐに関連性を失ってしまい、この方式は無駄です。最も速いオプションは、クライアントがサーバーソケットに常に接続し、取引シグナルが表示されるのを待つことです。恒久的な接続は、システマティックなリクエストと違ってトラフィックを無駄にせず、その信頼性はかなり高い。 先ほども言いましたが、コマンドも必要ありません。取引シグナルが表示されると、サーバーはそれを終端記号「 \n 」で1行にまとめてクライアントに送信し、次のシグナルを待ちます。クライアントはサーバーに何も送る必要がなく、信号を受信するだけである。 SSLやhttpsは全く必要ありません。まず、サーバーの所有者は、ドメインを登録し、証明書を購入し、これらのプロトコルで動作するために、これらすべてのものを無料ではなく、延長する必要があります。そして第二に、これらのプロトコルは、データの暗号 化のために、TCPストリーム内の情報を傍受するために、復号化することができませんでした。暗号はハラムバラムではなく、大きな整数のべき乗をモジュロで上げる操作なので、クライアントが多いとサーバーの負荷は膨大になるのです。 Avals 2012.02.16 05:52 #53 Reshetov: 取引は時間内に実行される必要があるため、取引シグナルファイルはすぐに関連性を失ってしまい、この方式は無駄です。最も速いオプションは、クライアントがサーバーソケットに常に接続し、取引シグナルが表示されるのを待つことです。恒久的な接続は、システム的な要求とは異なり、トラフィックを無駄にせず、その信頼性はかなり高いです。 先ほども言ったように、クライアントもコマンドを必要としません。取引シグナルが表示されると、サーバーはそれを1行でクライアントに送信し、次のシグナルを待ちます。クライアントはサーバーに何も送る必要がなく、信号を受信するだけでよい。 シグナルが表示された直後にすべてのクライアントに送信されるため、遅延はない。 コマンド単位での接続は、確かにトラフィックは節約できますが、信頼性は低くなります。クライアントは、何らかの理由で見逃したオーダー（例えば、保留中のオーダーやオーダーの変更）であっても、すべて取得することができるはずです。 Yury Reshetov 2012.02.16 05:54 #54 Avals: シグナルが表示された後、すぐにすべてのクライアントにメッセージが送信されるため、遅延はない。 チーム単位では、もちろんトラフィックの節約になりますが、信頼性は悪くなります。クライアントは、何らかの理由で見落とされた注文も含め、すべての注文（例えば保留中の注文や注文の変更）を取得できる必要があります。 よし、こぶとりを作ろう。そんなくだらないことをするのは誰だけか--それは私の問題ではない。 私の仕事は、最小限の負荷とトラフィックで最良の選択肢を提供することであり、お客様には拒否する権利があります。 Avals 2012.02.16 05:57 #55 Reshetov: SSLやhttpsは全く必要ありません。そもそも、このようなプロトコルで動作させるには、サーバーの所有者がドメインを登録し、証明書を購入し、それを永久に更新する必要があるのですが、それも無料ではありません。そして第二に、データの暗号化のためのこれらのプロトコルは、TCPストリーム内の情報を傍受するために、それを解読することができませんでした。暗号はハラムバラムではなく、大きな整数のべき乗をモジュロで上げる操作なので、クライアントが多いとサーバーの負荷は膨大になる。 しかし、既存の認証されていないサーバー・シグナルはすべて数時間でクラックされてしまうのです。暗号化は不要かもしれませんが)) Yury Reshetov 2012.02.16 06:02 #56 Avals: しかし、認証のない既存のサーバー・シグナルはすべて数時間でクラックされてしまう。暗号化は不要かもしれませんが））。1.時間ではなく、ミリ秒 2）自分の信号を他人に開けさせる必要があるのは一体誰なのか？エルーシブ・ジョーにまつわる逸話 Avals 2012.02.16 06:02 #57 Reshetov: よし、ハンパないくらいに作ってくれ。しかし、誰がそんなくだらないことをするかは、もはや私の問題ではない。 私の仕事は、最小限の負荷とトラフィックで最良の選択肢を提供することであり、お客様には拒否する権利があります。 クライアントが接続を失った、または再起動した場合、同時に保留または修正された命令を通過した場合、telnetコマンド交換でどのように修正するのですか？わからないが、もしかしたらできるかもしれない--だから聞いているのだ。 Avals 2012.02.16 06:02 #58 Reshetov:1.数時間ではなく、数ミリ秒。2）信号が隠れる必要があるのは誰だ？エルーシブ・ジョーにまつわる逸話 私はどうでもいいのですが、お金で信号を売っている人は怒りますね))しかし、このプロジェクトにおいて 重要でない場合は、問題なく、保護する必要はありません。 Yury Reshetov 2012.02.16 06:04 #59 Avals: クライアントの接続が切れたり、再起動したり、その間に保留中の注文や注文の変更があった場合、telnetコマンド交換で修正する方法は？わからないが、もしかしたらできるかもしれない--だから聞いているのだ。 コマンドのtelnetは必要ないって言ったのに、またくだらないこと言ってるなぁ。 ファイルを複製し、SendFTP() を使用していくつかの安価なホスティングにアップロードする必要があります。そして、クライアントが連絡を取れなかった時に、作成時刻を指定してFTPでファイルを読ませる。 Avals 2012.02.16 06:18 #60 Reshetov:コマンドのtelnetは必要ないって言ったのに、またくだらないこと言ってるなぁ。ファイルを複製して、SendFTP()を使って安いホスティングにアップロードする必要があります。そして、クライアントには、接続が切れた作成時刻のファイルをFTPで読み込ませる。 つまり、あなたのものではないのです)) レシェトフ： Socket over TCP/IP プロトコル。Telnet経由のように、「EURUSD Buy 1.0」等の1シグナルにつき1行のテキスト形式でシグナルを送信することができますが、これはhttpやftpプロトコルのように複雑な交換手順を必要とせず、最小限のパースで済む最も原始的なバージョンであるためです。 またくだらないことを言っている。1つでできるのに、もう1つと重複している))。1つのファイルで十分なのに、なぜわざわざファイルを保存 する必要があるのでしょうか？ - すべての注文とポジションの現在の状態を示す最後のファイルです。サーバーの要求（マスターアカウントに何か変更があったとき）とクライアントの要求（問題や矛盾があったとき）で交換を組み合わせ、追加の松葉杖を思いつかないようにすることです。サーバーからの要求に応じて、オーダーファイル全体を送信するのではなく、変更された部分のみを送信すれば、あなたのバージョンの「コマンドエクスチェンジ」となります。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
シンプルな交換スキーム：シグナルジェネレーターは、ターミナルと同様に、そのすべてのオープンオーダーとポジションを含むファイルをサーバーに配置します。少なくとも1つのオーダーまたはポジションが変更されている場合、新しいファイルを配置します。この場合、サーバは新しいバージョンのファイル（またはファイルの全内容を含むメッセージ）を送信し、クライアントはそれを受信したことを返信する（サーバには接続されているクライアントのリストが含まれているはずである）。また、サーバーはいつでもクライアントにファイルを送信することができます。
クライアントが巻き込まれたり、注文を取り逃がしたりしても、サーバーの端末ファイルを読めば簡単に復旧することができる。コマンド単位でのやりとりがある場合、クラッシュや曖昧な部分が多くなる可能性があります。クライアントは診断のために再同期することができます（例：変化がない場合、Xminに1回）。
この方式ではトラフィックは高くありません。だから、SSLやhttpsでもいいんです。
メッセージには、「与える」「受け取る」「ファイルそのもの」の3種類があります。
シンプルな交換スキーム：シグナルジェネレーターは、ターミナルと同様に、そのすべてのオープンオーダーとポジションを含むファイルをサーバーに配置します。少なくとも1つのオーダーまたはポジションが変更されている場合、新しいファイルを配置します。この場合、サーバーは新しいバージョンのファイル（またはこのファイルの全内容を含むメッセージ）を送信します。また、クライアントからの要求があれば、このファイルを随時送信する。
クライアントが巻き込まれたり、注文を取り逃がしたりしても、サーバーの端末ファイルを読めば簡単に復旧することができる。コマンド単位でのやりとりがある場合、クラッシュや曖昧な部分が多くなる可能性があります。クライアントは診断のために再同期することができます（例：変化がない場合、Xminに1回）。
この方式ではトラフィックは高くありません。そのため、SSLやhttpsでも大丈夫です。
取引は時間内に実行されなければならないので、取引シグナルを含むファイルはすぐに関連性を失ってしまい、この方式は無駄です。最も速いオプションは、クライアントがサーバーソケットに常に接続し、取引シグナルが表示されるのを待つことです。恒久的な接続は、システマティックなリクエストと違ってトラフィックを無駄にせず、その信頼性はかなり高い。
先ほども言いましたが、コマンドも必要ありません。取引シグナルが表示されると、サーバーはそれを終端記号「 \n 」で1行にまとめてクライアントに送信し、次のシグナルを待ちます。クライアントはサーバーに何も送る必要がなく、信号を受信するだけである。
SSLやhttpsは全く必要ありません。まず、サーバーの所有者は、ドメインを登録し、証明書を購入し、これらのプロトコルで動作するために、これらすべてのものを無料ではなく、延長する必要があります。そして第二に、これらのプロトコルは、データの暗号 化のために、TCPストリーム内の情報を傍受するために、復号化することができませんでした。暗号はハラムバラムではなく、大きな整数のべき乗をモジュロで上げる操作なので、クライアントが多いとサーバーの負荷は膨大になるのです。
取引は時間内に実行される必要があるため、取引シグナルファイルはすぐに関連性を失ってしまい、この方式は無駄です。最も速いオプションは、クライアントがサーバーソケットに常に接続し、取引シグナルが表示されるのを待つことです。恒久的な接続は、システム的な要求とは異なり、トラフィックを無駄にせず、その信頼性はかなり高いです。
先ほども言ったように、クライアントもコマンドを必要としません。取引シグナルが表示されると、サーバーはそれを1行でクライアントに送信し、次のシグナルを待ちます。クライアントはサーバーに何も送る必要がなく、信号を受信するだけでよい。
シグナルが表示された直後にすべてのクライアントに送信されるため、遅延はない。
コマンド単位での接続は、確かにトラフィックは節約できますが、信頼性は低くなります。クライアントは、何らかの理由で見逃したオーダー（例えば、保留中のオーダーやオーダーの変更）であっても、すべて取得することができるはずです。
シグナルが表示された後、すぐにすべてのクライアントにメッセージが送信されるため、遅延はない。
チーム単位では、もちろんトラフィックの節約になりますが、信頼性は悪くなります。クライアントは、何らかの理由で見落とされた注文も含め、すべての注文（例えば保留中の注文や注文の変更）を取得できる必要があります。
よし、こぶとりを作ろう。そんなくだらないことをするのは誰だけか--それは私の問題ではない。
私の仕事は、最小限の負荷とトラフィックで最良の選択肢を提供することであり、お客様には拒否する権利があります。
SSLやhttpsは全く必要ありません。そもそも、このようなプロトコルで動作させるには、サーバーの所有者がドメインを登録し、証明書を購入し、それを永久に更新する必要があるのですが、それも無料ではありません。そして第二に、データの暗号化のためのこれらのプロトコルは、TCPストリーム内の情報を傍受するために、それを解読することができませんでした。暗号はハラムバラムではなく、大きな整数のべき乗をモジュロで上げる操作なので、クライアントが多いとサーバーの負荷は膨大になる。
しかし、既存の認証されていないサーバー・シグナルはすべて数時間でクラックされてしまうのです。暗号化は不要かもしれませんが))
しかし、認証のない既存のサーバー・シグナルはすべて数時間でクラックされてしまう。暗号化は不要かもしれませんが））。
1.時間ではなく、ミリ秒
2）自分の信号を他人に開けさせる必要があるのは一体誰なのか？エルーシブ・ジョーにまつわる逸話
よし、ハンパないくらいに作ってくれ。しかし、誰がそんなくだらないことをするかは、もはや私の問題ではない。
私の仕事は、最小限の負荷とトラフィックで最良の選択肢を提供することであり、お客様には拒否する権利があります。
1.数時間ではなく、数ミリ秒。
2）信号が隠れる必要があるのは誰だ？エルーシブ・ジョーにまつわる逸話
私はどうでもいいのですが、お金で信号を売っている人は怒りますね))しかし、このプロジェクトにおいて 重要でない場合は、問題なく、保護する必要はありません。
クライアントの接続が切れたり、再起動したり、その間に保留中の注文や注文の変更があった場合、telnetコマンド交換で修正する方法は？わからないが、もしかしたらできるかもしれない--だから聞いているのだ。
コマンドのtelnetは必要ないって言ったのに、またくだらないこと言ってるなぁ。
ファイルを複製し、SendFTP() を使用していくつかの安価なホスティングにアップロードする必要があります。そして、クライアントが連絡を取れなかった時に、作成時刻を指定してFTPでファイルを読ませる。
コマンドのtelnetは必要ないって言ったのに、またくだらないこと言ってるなぁ。
ファイルを複製して、SendFTP()を使って安いホスティングにアップロードする必要があります。そして、クライアントには、接続が切れた作成時刻のファイルをFTPで読み込ませる。
つまり、あなたのものではないのです))
レシェトフ：
Socket over TCP/IP プロトコル。Telnet経由のように、「EURUSD Buy 1.0」等の1シグナルにつき1行のテキスト形式でシグナルを送信することができますが、これはhttpやftpプロトコルのように複雑な交換手順を必要とせず、最小限のパースで済む最も原始的なバージョンであるためです。
またくだらないことを言っている。1つでできるのに、もう1つと重複している))。1つのファイルで十分なのに、なぜわざわざファイルを保存 する必要があるのでしょうか？ - すべての注文とポジションの現在の状態を示す最後のファイルです。サーバーの要求（マスターアカウントに何か変更があったとき）とクライアントの要求（問題や矛盾があったとき）で交換を組み合わせ、追加の松葉杖を思いつかないようにすることです。サーバーからの要求に応じて、オーダーファイル全体を送信するのではなく、変更された部分のみを送信すれば、あなたのバージョンの「コマンドエクスチェンジ」となります。