ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

Xe57コミュのTCPの使い方について

  • mixiチェック
  • このエントリーをはてなブックマークに追加
教えてください。

 複数台のPCをTCPで通信させたいときに、
何時も同じ立場で通信させるために、
連番の小さい方が何時もアンサー、
連番の大きい方がオリジネート。

 まあ連番はどう決めても
良いわけですがIP
アドレスとか。

 これの維持に、
番号が小さい方から、
大きい方に通信したい時には、
接続してくるようにとの要求をUDPで送る。
尚かつ、HTTPの様に通信終了後サヨナラせずに、
TELNETの様に、何時も繋ぎっぱなしにしておく。

 こんな事が書いてあるシステム設計を見たのですが、
私にとってはとってもクレージーに思えるのです。

 単純にコネクションが切れていなければ、
その接続を使い、切れていたら、
単純に接続要求をする。
通信を終了したら、
接続を切る。

 これはリソースを使いすぎ?
セションの確立のために、
多量のリソースを
消費します?

 接続要求の要求のUDPを待つクライアントなんて、
馬鹿げていてと思うのですが、ご意見を頂戴できれば幸いです。

 ところで、TCPのサーバー、クライアントって、
アンサーかオリジネートかっていう程度の違いなのでしょう?

 いや、勉強不足をさらけ出しちゃってますね。

コメント(7)

複雑な問題ですね。
先ず理解が...
アンサーはサーバにオリジネートはクライアントに読み替えていいんでしょうね。
オリジネートというのは通信の契機を持つという意味でしょうか。
1,2,3の連番PCがあったときは
1=サーバ に対しては 2=クライアント
2=サーバ、に対しては 3=クライアント
1=サーバ、に対しては 3=クライアント
となって片方向なので逆も実現するためにしかたないから別ルートでUDPを使っちゃえ、ということでしょうか。

ということはN台のPCのネットワークにおける2つのPCの組み合わせで両方向に通信の契機を持てるようにする、というP2Pの命題の解決策に類似しています。

TCPのListenとConnectを使う限り両方向で契機を持つことは不可能なのでこのような解決策もありかな、と思います。

私の場合は次のようにしています。
・1台のPCにListenプロセスとConnectプロセスの2本をセットで立てる。(Listenは複数からの接続を受け入れる、Connectは1つだけ接続できる)この2プロセスはプロセス間通信を蜜に行いあたかも1つのプロセスのように振舞う。
・このことでこのPCはサーバでもあるしクライアントでもある。(またはサーバでもなければクライアントでもない)
・すなわちネットワーク接続のPCの組み合わせにおいてどのPCも通信の契機を持つ。
(実は幾何学的(=リスト構造)に制限はあるのでこれが万能というわけではありません)


的を外してなければいいですが...

(注)サーバは関数Listenで常に待ち状態、クライアントはConnectで接続にかかる、ということではアンサー・オリジネートという言葉はなんとなく納得です。

さらに、勉強不足なんてとんでもない。このようなことを書いた本を見たことがないです。
 早速に有難う御座います。
まさに、おっしゃる通りの点が問題です。

 10台以上で通信です。
これで、全てのPC間の接続を
維持したままにしたいと言うのですから、
ちょっと不思議な気持ちになってしまいます。
こんなデザインではたして巧く行く物なのでしょうか?

 必要な時だけTCPして、
あとはアロハしちゃえば良いと ・・。

 それから嫌なのは、
各PCが相互に通信するのに、
シンメトリじゃないのが何となく不安です。

 番号が小さい方はListenerが頑張り、
番号の大きい方はConnectorが頑張る訳でしょう。

 何か、この手の通信技術に付いての
ちょっとした入門書、欲しいです。
無ければ是非書いてください。

 TCP/IP通信アルゴリズム集
    通信効率とPGの分かりやすさについて

世の中をもっと明るくする為に、
是非例の500円シリーズで、お願いいたします。
そうですね500円シリーズで誰も読まないやつを出すのもいいですね。


ほんとに、全く対象形のP2P幾何学をつくりあげることには魅力があります。

ちゃんと調べていないですがWinnyなどほとんどのものがTree構造の中でP2Pを工夫しているようですね。

インターネットとLANがそもそも階層を持っていて対象形にはできないという問題もあります。IPv6が広まるとそこは解消されていくでしょうが。

今の私の構想はring構造とTree構造の組み合わせでほとんど満足できそう、というところです。

>必要な時だけTCPして、
>あとはアロハしちゃえば良いと ・・。

技術的には可能ですがパフォーマンスがどうなんでしょうか?Connectというのは非常に時間がかかるものでアプリにとってはできれば1度で済ませたい、一度繋いだらずっと繋ぎっぱなしにしておきたいという願望があります。
通常のConnectも時間がかかりますがリトライが発生したときはアプリは大変です。


10台以上の対象形接続というテーマで基本設計コンテストなど面白いかも。乗ってくる人はいるのかなあ...
あの500円シリーズは、「誰も読まない」のでは困りますね。

普通のところでは、絶対に出さないという本を出したいと思います。

tanさんの担当本が決まりましたね。よろしくお願いします。
 そうです。
少なくとも1冊は ・・ って私です。
勉強させてください。
「普通のところでは、絶対に出さないという本」となるのには自信があります。
そっかぁ〜
私の担当本が決まったんだ。がんばろう。

追記  対象形接続→対称形接続の誤りでした。
売れる本も欲しいから、題名を上手く考えてくださいね。
表紙は予算の関係で1色です。
先輩のKさんの本も書いてもらって、なかなk登場してこないSさんにも書いてもらって、LLPでの出版活動の開始ですね。
 なお、発売日は来年の5月17日にします。ビジネスショウ当日です。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

Xe57 更新情報

Xe57のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。

人気コミュニティランキング