高信頼性トランザクション/シグナルコピー機 (アイデア検討・開発) - ページ 8 123456789 新しいコメント Dmitry Fedoseev 2012.02.16 10:59 #71 なぜそこまでするのか。TCP/IPで動作させるための標準的なコントローラがありますので、この場合は別途プログラムを書いてください。ターミナルでは、EAがプログラムと通信する（1台のコンピュータ内で、好きな方法で）...。を、車輪を再発明する必要はありません - ポートを聞くために、誰もが長い間あなたのために聞いている。 Лекарь Центозависимых 2012.02.16 11:10 #72 sergeev: そこがポイントです。 総合的に考えようと思っています。もちろん、当初はスケーラビリティに多くの投資をする必要があります。つまり、1000h分として行うことが目標です。しかも、後で使うのは一部の人たちだけというのは問題外です。 だから今、スピードとマイクロトラフィックのどちらかをソケットで選ぼうとしているんです。または httpと情報の新しい部分のためのクライアントの一定の追跡上の多くのトラフィック。 2番目の選択肢の方が良いと思います。拡張性が必要な人はごくわずかですが、とにかく追加 コストがかかります。対応するトラフィックも支払わせる。 また、9割のケースで、少ないクライアント数で使用するため、トラフィックよりも接続の信頼性、つまり機能性が重要視されます。 そして、最初のケースでは、信頼できる接続がなければ、良い解決策は得られません。 Mykola Demko 2012.02.16 11:33 #73 sergeev: そこがポイントです。 総合的に考えようと思っています。もちろん、当初はより大きなスケーラビリティへの投資が必要です。つまり、1000h分と同じくらいの量をこなすことが目標です。しかも、後で使うのは一部の人たちだけというのは問題外です。 だから今、スピードとマイクロトラフィックのどちらかをソケットで選ぼうとしているんです。またはhttpと情報の新しい部分のためのクライアントの一定の追跡上の多くのトラフィック。 また、情報を受け取ったクライアントが自らサーバーとなり、あるクライアントの集合に情報を配信するとしたらどうでしょう。スカイプとか。 ZSでは、ネットワークが小さいうちはサーバーから直接注文が来ますが、ネットワークが大きくなると、第2エシュロン、第3エシュロンと、拡張性のあるネットワークを構築しています。この場合、サーバーの負荷は増加しない。マシン間のpingにより、ネットワークを構成することができます。 Лекарь Центозависимых 2012.02.16 11:37 #74 Urain: 情報を手に入れたクライアント自身がサーバーとなり、あるクライアントの集合に情報を配信するとしたらどうだろう。Skypeのように。 ちょうどニュースを見たところです）https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA ピアツーピアを使えば、他に類を見ない「革命的」なソリューションになるはずだ) しかし、それが現実的なのか、また、それに見合うだけの価値があるのか、疑問に思うことがあります。 Mykola Demko 2012.02.16 11:41 #75 OnGoing: ちょうどニュースを見たところです）https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA ピアツーピアを使えば、他に類を見ない「革命的」なソリューションになるはずだ) ただ、それが現実的なものなのか、価値が あるものなのかは疑問が残ります。 だから、ネットワークの規模を聞いたんです。巨大さを把握することは、筆舌に尽くしがたいものを把握することに似ている :) --- 2012.02.16 12:00 #76 Urain: 情報を受け取ったクライアントが自らサーバーとなり、ある特定のクライアントに情報を配信するとしたらどうでしょう。スカイプのように。 オプションは良いのですが、大きすぎます :) クライアントとマスターの同期のために、クライアント自身の間で追加のやりとりをするのは冗長だと思います。 もちろん、各クライアントがミニサーバーとなって受信した情報を送信することになるわけで、原理的には考える価値があるのですが。 --- 2012.02.16 12:07 #77 Integer: なぜそこまでするのか。TCP/IPで動作させるための標準的なコントローラがありますので、この場合は別途プログラムを書いてください。ターミナルでは、EAがプログラムと通信する（1台のコンピュータ内で、好きな方法で）...。を、車輪を再発明する必要はありません - ポートを聞くために、誰もが長い間あなたのために聞いている。 ドミトリー、繰り返す。レプリケーターは、4～5年前くらいから長い間利用されていました。そして、ローカルとリモート、中間サーバーを使ったものです。私のために聞いてくれるコントローラーは必要ない。 ここでは、フォーラム全体で、いろいろなことを学んだ人たちが議論する場を作りたいと考えています。 そして、その技術の長所と 短所を踏まえて 、クライアントの数、接続の質、チャンネルの負荷のどちらにも安定した耐性を持つ、信頼性の高いコピー機のバリエーションを作ることです。 Mykola Demko 2012.02.16 13:16 #78 sergeev: .. そして、クライアントの数、接続の質、チャンネルへの負荷の両面から、安定した堅牢性を持つ信頼性の高いコピー機を作るための技術のメリットと デメリットを 踏まえた上で、そのようなコピー機を作っています。 議題になっているのは、2つのリスクです。 1 通信障害で信号が届かない 2 伝送時のビットロスのため、正しいメッセージを受け取れないこと。 そうすると、隣り合うクライアント同士の通信がなくても、異なるソースから3つの信号を得ることで、ビット単位のすり合わせができ、「3のうち2は真」の原理で真のメッセージを得ることができます。このような方式は、通信障害と伝送損失の両方に対してより安全である。そして、メッセージをビットマスクに暗号化し、最小限に圧縮することができる（文字列の文章を送信するのではなく）。これにより、サーバーのトラフィックを減らすことができます。 そして、故障した隣人による障害を避けるために、冗長なメーリングを形成し、例えば、クライアントはサーバーと4つの隣人からの信号を受信するが、サーバーの信号と先に来た隣人からの2つの信号が考慮されるようにする。 --- 2012.02.16 13:22 #79 Urain: 議題になっているのは、2つのリスクです。 1 通信障害で信号が届かない クライアント側の通信不足は解決できない。 あるかないかのどちらかである。 サーバー側は常に通信があることが前提である。 2 伝送中のロストビットのために正しいメッセージを受け取れないこと。 無効なメッセージはハッシュなどで署名することができる。 ハッシュが誤っている場合、メッセージはサーバーから再試行される。 しかし通常、ファイルの最後と真ん中に特別な@label@タグがあれば、メッセージが完全であることを明確にすることができる。 Лекарь Центозависимых 2012.02.16 13:23 #80 Urain: ...その場合、隣接するクライアント間の通信が不可欠であり、異なるソースから3つの信号を受信した場合、ビット単位の照合を行い、「3つのうち2つが正しい」という基準で真のメッセージを出力することが可能である。このような方式は、通信障害と伝送損失の両方に対してより安全である。そして、メッセージをビットマスクに暗号化し、最小限に圧縮することができる（文字列の文章を送信するのではなく）。これにより、サーバーのトラフィックを減らすことができます。 送信データの真偽の検証は、TCP/IPではすでにプロトコルレベルで実装されている。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
なぜそこまでするのか。TCP/IPで動作させるための標準的なコントローラがありますので、この場合は別途プログラムを書いてください。ターミナルでは、EAがプログラムと通信する（1台のコンピュータ内で、好きな方法で）...。を、車輪を再発明する必要はありません - ポートを聞くために、誰もが長い間あなたのために聞いている。
そこがポイントです。 総合的に考えようと思っています。もちろん、当初はスケーラビリティに多くの投資をする必要があります。つまり、1000h分として行うことが目標です。しかも、後で使うのは一部の人たちだけというのは問題外です。
だから今、スピードとマイクロトラフィックのどちらかをソケットで選ぼうとしているんです。または httpと情報の新しい部分のためのクライアントの一定の追跡上の多くのトラフィック。
2番目の選択肢の方が良いと思います。拡張性が必要な人はごくわずかですが、とにかく追加 コストがかかります。対応するトラフィックも支払わせる。
また、9割のケースで、少ないクライアント数で使用するため、トラフィックよりも接続の信頼性、つまり機能性が重要視されます。
そして、最初のケースでは、信頼できる接続がなければ、良い解決策は得られません。
そこがポイントです。 総合的に考えようと思っています。もちろん、当初はより大きなスケーラビリティへの投資が必要です。つまり、1000h分と同じくらいの量をこなすことが目標です。しかも、後で使うのは一部の人たちだけというのは問題外です。
だから今、スピードとマイクロトラフィックのどちらかをソケットで選ぼうとしているんです。またはhttpと情報の新しい部分のためのクライアントの一定の追跡上の多くのトラフィック。
また、情報を受け取ったクライアントが自らサーバーとなり、あるクライアントの集合に情報を配信するとしたらどうでしょう。スカイプとか。
ZSでは、ネットワークが小さいうちはサーバーから直接注文が来ますが、ネットワークが大きくなると、第2エシュロン、第3エシュロンと、拡張性のあるネットワークを構築しています。この場合、サーバーの負荷は増加しない。マシン間のpingにより、ネットワークを構成することができます。
情報を手に入れたクライアント自身がサーバーとなり、あるクライアントの集合に情報を配信するとしたらどうだろう。Skypeのように。
ちょうどニュースを見たところです）https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
ピアツーピアを使えば、他に類を見ない「革命的」なソリューションになるはずだ)
しかし、それが現実的なのか、また、それに見合うだけの価値があるのか、疑問に思うことがあります。
ちょうどニュースを見たところです）https://www.youtube.com/watch?feature=player_embedded&v=7VKf0W44qGA
ピアツーピアを使えば、他に類を見ない「革命的」なソリューションになるはずだ)
ただ、それが現実的なものなのか、価値が あるものなのかは疑問が残ります。
情報を受け取ったクライアントが自らサーバーとなり、ある特定のクライアントに情報を配信するとしたらどうでしょう。スカイプのように。
オプションは良いのですが、大きすぎます :) クライアントとマスターの同期のために、クライアント自身の間で追加のやりとりをするのは冗長だと思います。
もちろん、各クライアントがミニサーバーとなって受信した情報を送信することになるわけで、原理的には考える価値があるのですが。
なぜそこまでするのか。TCP/IPで動作させるための標準的なコントローラがありますので、この場合は別途プログラムを書いてください。ターミナルでは、EAがプログラムと通信する（1台のコンピュータ内で、好きな方法で）...。を、車輪を再発明する必要はありません - ポートを聞くために、誰もが長い間あなたのために聞いている。
ここでは、フォーラム全体で、いろいろなことを学んだ人たちが議論する場を作りたいと考えています。 そして、その技術の長所と 短所を踏まえて 、クライアントの数、接続の質、チャンネルの負荷のどちらにも安定した耐性を持つ、信頼性の高いコピー機のバリエーションを作ることです。
..
そして、クライアントの数、接続の質、チャンネルへの負荷の両面から、安定した堅牢性を持つ信頼性の高いコピー機を作るための技術のメリットと デメリットを 踏まえた上で、そのようなコピー機を作っています。
議題になっているのは、2つのリスクです。
1 通信障害で信号が届かない
2 伝送時のビットロスのため、正しいメッセージを受け取れないこと。
そうすると、隣り合うクライアント同士の通信がなくても、異なるソースから3つの信号を得ることで、ビット単位のすり合わせができ、「3のうち2は真」の原理で真のメッセージを得ることができます。このような方式は、通信障害と伝送損失の両方に対してより安全である。そして、メッセージをビットマスクに暗号化し、最小限に圧縮することができる（文字列の文章を送信するのではなく）。これにより、サーバーのトラフィックを減らすことができます。
そして、故障した隣人による障害を避けるために、冗長なメーリングを形成し、例えば、クライアントはサーバーと4つの隣人からの信号を受信するが、サーバーの信号と先に来た隣人からの2つの信号が考慮されるようにする。
議題になっているのは、2つのリスクです。
1 通信障害で信号が届かない
クライアント側の通信不足は解決できない。 あるかないかのどちらかである。 サーバー側は常に通信があることが前提である。
2 伝送中のロストビットのために正しいメッセージを受け取れないこと。
無効なメッセージはハッシュなどで署名することができる。 ハッシュが誤っている場合、メッセージはサーバーから再試行される。 しかし通常、ファイルの最後と真ん中に特別な@label@タグがあれば、メッセージが完全であることを明確にすることができる。
...その場合、隣接するクライアント間の通信が不可欠であり、異なるソースから3つの信号を受信した場合、ビット単位の照合を行い、「3つのうち2つが正しい」という基準で真のメッセージを出力することが可能である。このような方式は、通信障害と伝送損失の両方に対してより安全である。そして、メッセージをビットマスクに暗号化し、最小限に圧縮することができる（文字列の文章を送信するのではなく）。これにより、サーバーのトラフィックを減らすことができます。