教えてください。
複数台のＰＣをＴＣＰで通信させたいときに、
何時も同じ立場で通信させるために、
連番の小さい方が何時もアンサー、
連番の大きい方がオリジネート。
まあ連番はどう決めても
良いわけですがＩＰ
アドレスとか。
これの維持に、
番号が小さい方から、
大きい方に通信したい時には、
接続してくるようにとの要求をＵＤＰで送る。
尚かつ、ＨＴＴＰの様に通信終了後サヨナラせずに、
ＴＥＬＮＥＴの様に、何時も繋ぎっぱなしにしておく。
こんな事が書いてあるシステム設計を見たのですが、
私にとってはとってもクレージーに思えるのです。
単純にコネクションが切れていなければ、
その接続を使い、切れていたら、
単純に接続要求をする。
通信を終了したら、
接続を切る。
これはリソースを使いすぎ？
セションの確立のために、
多量のリソースを
消費します？
接続要求の要求のＵＤＰを待つクライアントなんて、
馬鹿げていてと思うのですが、ご意見を頂戴できれば幸いです。
ところで、ＴＣＰのサーバー、クライアントって、
アンサーかオリジネートかっていう程度の違いなのでしょう？
いや、勉強不足をさらけ出しちゃってますね。
複数台のＰＣをＴＣＰで通信させたいときに、
何時も同じ立場で通信させるために、
連番の小さい方が何時もアンサー、
連番の大きい方がオリジネート。
まあ連番はどう決めても
良いわけですがＩＰ
アドレスとか。
これの維持に、
番号が小さい方から、
大きい方に通信したい時には、
接続してくるようにとの要求をＵＤＰで送る。
尚かつ、ＨＴＴＰの様に通信終了後サヨナラせずに、
ＴＥＬＮＥＴの様に、何時も繋ぎっぱなしにしておく。
こんな事が書いてあるシステム設計を見たのですが、
私にとってはとってもクレージーに思えるのです。
単純にコネクションが切れていなければ、
その接続を使い、切れていたら、
単純に接続要求をする。
通信を終了したら、
接続を切る。
これはリソースを使いすぎ？
セションの確立のために、
多量のリソースを
消費します？
接続要求の要求のＵＤＰを待つクライアントなんて、
馬鹿げていてと思うのですが、ご意見を頂戴できれば幸いです。
ところで、ＴＣＰのサーバー、クライアントって、
アンサーかオリジネートかっていう程度の違いなのでしょう？
いや、勉強不足をさらけ出しちゃってますね。
|
|
|
|
コメント(7)
複雑な問題ですね。
先ず理解が．．．
アンサーはサーバにオリジネートはクライアントに読み替えていいんでしょうね。
オリジネートというのは通信の契機を持つという意味でしょうか。
１，２，３の連番ＰＣがあったときは
１＝サーバ に対しては ２＝クライアント
２＝サーバ、に対しては ３＝クライアント
１＝サーバ、に対しては ３＝クライアント
となって片方向なので逆も実現するためにしかたないから別ルートでＵＤＰを使っちゃえ、ということでしょうか。
ということはＮ台のＰＣのネットワークにおける２つのＰＣの組み合わせで両方向に通信の契機を持てるようにする、というＰ２Ｐの命題の解決策に類似しています。
ＴＣＰのListenとConnectを使う限り両方向で契機を持つことは不可能なのでこのような解決策もありかな、と思います。
私の場合は次のようにしています。
・１台のＰＣにListenプロセスとConnectプロセスの２本をセットで立てる。（Listenは複数からの接続を受け入れる、Connectは１つだけ接続できる）この２プロセスはプロセス間通信を蜜に行いあたかも１つのプロセスのように振舞う。
・このことでこのＰＣはサーバでもあるしクライアントでもある。（またはサーバでもなければクライアントでもない）
・すなわちネットワーク接続のＰＣの組み合わせにおいてどのＰＣも通信の契機を持つ。
（実は幾何学的（＝リスト構造）に制限はあるのでこれが万能というわけではありません）
的を外してなければいいですが．．．
（注）サーバは関数Listenで常に待ち状態、クライアントはConnectで接続にかかる、ということではアンサー・オリジネートという言葉はなんとなく納得です。
さらに、勉強不足なんてとんでもない。このようなことを書いた本を見たことがないです。
先ず理解が．．．
アンサーはサーバにオリジネートはクライアントに読み替えていいんでしょうね。
オリジネートというのは通信の契機を持つという意味でしょうか。
１，２，３の連番ＰＣがあったときは
１＝サーバ に対しては ２＝クライアント
２＝サーバ、に対しては ３＝クライアント
１＝サーバ、に対しては ３＝クライアント
となって片方向なので逆も実現するためにしかたないから別ルートでＵＤＰを使っちゃえ、ということでしょうか。
ということはＮ台のＰＣのネットワークにおける２つのＰＣの組み合わせで両方向に通信の契機を持てるようにする、というＰ２Ｐの命題の解決策に類似しています。
ＴＣＰのListenとConnectを使う限り両方向で契機を持つことは不可能なのでこのような解決策もありかな、と思います。
私の場合は次のようにしています。
・１台のＰＣにListenプロセスとConnectプロセスの２本をセットで立てる。（Listenは複数からの接続を受け入れる、Connectは１つだけ接続できる）この２プロセスはプロセス間通信を蜜に行いあたかも１つのプロセスのように振舞う。
・このことでこのＰＣはサーバでもあるしクライアントでもある。（またはサーバでもなければクライアントでもない）
・すなわちネットワーク接続のＰＣの組み合わせにおいてどのＰＣも通信の契機を持つ。
（実は幾何学的（＝リスト構造）に制限はあるのでこれが万能というわけではありません）
的を外してなければいいですが．．．
（注）サーバは関数Listenで常に待ち状態、クライアントはConnectで接続にかかる、ということではアンサー・オリジネートという言葉はなんとなく納得です。
さらに、勉強不足なんてとんでもない。このようなことを書いた本を見たことがないです。
早速に有難う御座います。
まさに、おっしゃる通りの点が問題です。
１０台以上で通信です。
これで、全てのＰＣ間の接続を
維持したままにしたいと言うのですから、
ちょっと不思議な気持ちになってしまいます。
こんなデザインではたして巧く行く物なのでしょうか？
必要な時だけＴＣＰして、
あとはアロハしちゃえば良いと ・・。
それから嫌なのは、
各ＰＣが相互に通信するのに、
シンメトリじゃないのが何となく不安です。
番号が小さい方はListenerが頑張り、
番号の大きい方はConnectorが頑張る訳でしょう。
何か、この手の通信技術に付いての
ちょっとした入門書、欲しいです。
無ければ是非書いてください。
ＴＣＰ/ＩＰ通信アルゴリズム集
通信効率とＰＧの分かりやすさについて
世の中をもっと明るくする為に、
是非例の５００円シリーズで、お願いいたします。
まさに、おっしゃる通りの点が問題です。
１０台以上で通信です。
これで、全てのＰＣ間の接続を
維持したままにしたいと言うのですから、
ちょっと不思議な気持ちになってしまいます。
こんなデザインではたして巧く行く物なのでしょうか？
必要な時だけＴＣＰして、
あとはアロハしちゃえば良いと ・・。
それから嫌なのは、
各ＰＣが相互に通信するのに、
シンメトリじゃないのが何となく不安です。
番号が小さい方はListenerが頑張り、
番号の大きい方はConnectorが頑張る訳でしょう。
何か、この手の通信技術に付いての
ちょっとした入門書、欲しいです。
無ければ是非書いてください。
ＴＣＰ/ＩＰ通信アルゴリズム集
通信効率とＰＧの分かりやすさについて
世の中をもっと明るくする為に、
是非例の５００円シリーズで、お願いいたします。
そうですね５００円シリーズで誰も読まないやつを出すのもいいですね。
ほんとに、全く対象形のP2P幾何学をつくりあげることには魅力があります。
ちゃんと調べていないですがWinnyなどほとんどのものがTree構造の中でP2Pを工夫しているようですね。
インターネットとLANがそもそも階層を持っていて対象形にはできないという問題もあります。IPv6が広まるとそこは解消されていくでしょうが。
今の私の構想はring構造とTree構造の組み合わせでほとんど満足できそう、というところです。
>必要な時だけＴＣＰして、
>あとはアロハしちゃえば良いと ・・。
技術的には可能ですがパフォーマンスがどうなんでしょうか？Connectというのは非常に時間がかかるものでアプリにとってはできれば１度で済ませたい、一度繋いだらずっと繋ぎっぱなしにしておきたいという願望があります。
通常のConnectも時間がかかりますがリトライが発生したときはアプリは大変です。
１０台以上の対象形接続というテーマで基本設計コンテストなど面白いかも。乗ってくる人はいるのかなあ．．．
ほんとに、全く対象形のP2P幾何学をつくりあげることには魅力があります。
ちゃんと調べていないですがWinnyなどほとんどのものがTree構造の中でP2Pを工夫しているようですね。
インターネットとLANがそもそも階層を持っていて対象形にはできないという問題もあります。IPv6が広まるとそこは解消されていくでしょうが。
今の私の構想はring構造とTree構造の組み合わせでほとんど満足できそう、というところです。
>必要な時だけＴＣＰして、
>あとはアロハしちゃえば良いと ・・。
技術的には可能ですがパフォーマンスがどうなんでしょうか？Connectというのは非常に時間がかかるものでアプリにとってはできれば１度で済ませたい、一度繋いだらずっと繋ぎっぱなしにしておきたいという願望があります。
通常のConnectも時間がかかりますがリトライが発生したときはアプリは大変です。
１０台以上の対象形接続というテーマで基本設計コンテストなど面白いかも。乗ってくる人はいるのかなあ．．．
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
Xe57 更新情報
-
最新のイベント
-
まだ何もありません
-
-
最新のアンケート
-
まだ何もありません
-
