sango****@lists*****
sango****@lists*****
2011年 2月 23日 (水) 20:17:58 JST
To：土肥さん、ひろゆきさん、皆様 narunaruです。 いつもご意見ありがとうございます。 ご質問頂いた点に関して自分の考えを記載致します。 > 100対100の場合に問題になるという部分をもう少し説明して頂けますか？ > ユニキャストのコネクションを200個確保すると、回線的に問題となることを危 > 惧しているのでしょうか？ > 仮に、これだけが問題なのであれば、回避方法はあるかと思いますし、サーバの > 方で対処したほうがスケーラブルになるのではないかと思っています。 はい、ずばりそのとおりです。 ブロードキャストを使用し1回で全員に通知するのとユニキャストを使用し個別 に200回通知するのでは、ブロードキャストを使用するほうがサーバやネット ワークにやさしいのではないかと考えました。 サーバの負荷に関しては確かにスケールアウト等、対処することも可能かと思い ます。 ですがそもそもクライアント側にサーバソケットを持てば、上記の問題でのサー バのスケールアウト等はする必要が無く、また各クライアントにもサーバソケッ トが一つ増えるのみのため、あまり大きな問題は無いのかと感じております。 この辺りは各個人で色々な見解があると思います。ですので自分の考えはあくま でこんな考えもある程度に考えて頂ければ幸いです。 後、マルチキャストに関しては、同じUDPなのでブロードキャストが出来ればい けるんじゃないかと思ってましたが、調べてみるとそうではないみたいです。。 MBoneは土肥さんからの情報で知りました。 なので特に何も意見を出すことが出来ません。。。役立たずで申し訳ないです。。 ネットワークに詳しい方ご教授お願い致します。 (2011/02/23 1:49), sango****@lists***** wrote: > 土肥です。 > > 100対100の場合に問題になるという部分をもう少し説明して頂けますか？ > ユニキャストのコネクションを200個確保すると、回線的に問題となることを危 > 惧しているのでしょうか？ > 仮に、これだけが問題なのであれば、回避方法はあるかと思いますし、サーバの > 方で対処したほうがスケーラブルになるのではないかと思っています。 > > ちなみに、僕自身はサーバ側が待ち受けの方がよいと思っていますが、絶対にと > いう訳ではなく、HTTP通信か、クライアント側にサーバソケットを用意しての２ > 択で考えているようでしたので、その理由を知りたかっただけです。 > 場合によってはその方がよいケースもあるかと思ったので。 > > ところで、付け焼刃でマルチキャストについて調べてみたのですが、インター > ネット上でマルチキャストって実現できるのでしょうか？ > 調べた限りだと、ルーターの設定なども多少必要な気がしていますし、イントラ > ネットの説明ばっかりなんですよね。 > > MBoneとかいう仕組みがあるようなのですが、ちょっと調べただけだと、情報も > 少なく、よく分かりません。 > > この辺、情報をお持ちの方がいたら、教えて頂きたいです。 > > > (2011/02/23 0:09), sango****@lists***** wrote: >> 裕之です。 >> >> 確かに100対100に拘ってる訳ではないので、もしかしたら10対10が限界かもしれ >> ませんし、それ以下かもしれません。 >> >> ただ、参加できる許容人数が多ければ多いほどゲームとして盛り上がると思って >> いますので、 >> サバクラとも受信する方式の方が適しているのであれば、それを選択すべきと思 >> いますがいかがでしょうか。 >> >> 裕之 >> >> >> (2011/02/22 23:54), sango****@lists***** wrote: >>> To：土肥さん、ひろゆきさん、各位 >>> >>> narunaruです。 >>> >>> すいません。 >>> 土肥さんの意見を誤認しておりました。 >>> そして、確かにHTTP vs Socketのような感じで >>> skypeで発言しておりました。。。 >>> 申し訳ないです。。。 >>> >>> また以下の土肥さんの見解に関してですが、 >>> 現状の仕様では確かにサーバ側に待ちうけ用のソケットを用意するだけで良いか >>> と思います。 >>> ただ自分が当初、クライアント側にUDP受信用のソケットが必要で、サーバ側に >>> もクライアントからのコネクションを待ち受けるソケットが必要(両方に待ちう >>> け用のソケットが必要)と考えた背景には他にも理由がありまして、それは少し >>> 前にひろゆきさんが実現したいと言っていた100対100の件を考慮していたためと >>> なります。 >>> その場合、TCPだけでは対処しきれないのではと考えたためです。 >>> 先ほどは説明不足で申し訳ないです。 >>> >>> しかし、現状100対100は無視してよいと確かチャットでおっしゃっていたと思い >>> ますので、土肥さんから提案頂いたとおりサーバ側にのみ待ち受け用のソケット >>> を用意するで良いと思います。 >>> >>> (2011/02/22 22:48), sango****@lists***** wrote: >>>> 土肥です。 >>>> >>>> 紛らわしい言い方をしてしまってすみません。 >>>> Skypeでの話しで気になったのですが、 >>>> >>>> HTTP経由 vs Socket >>>> >>>> みたいな表現を僕も含めてしてしまっていたと思うのですが、Socketという言葉 >>>> をどのような意味で使うかを明確にしたいなというだけでした。 >>>> 多分、 >>>> >>>> １．永続化するかどうか？ >>>> ２．サーバソケットをどちらが持つか？ >>>> >>>> という２つの独立した選択肢があり、永続化せずにサーバソケットをサーバサイ >>>> ドに用意した際のソリューションの１つがHTTPであると思います。 >>>> また、サーバソケットを持つ側は受動的に成らざるおえなく、HTTPでやり取りす >>>> るためには、narunaruさんがおっしゃるようにサーバからのPUSH通知はできず、 >>>> ポーリングする必要があるでしょう。 >>>> >>>> 個人的な意見として、通信が頻繁に発生するなら、 >>>> 「永続化したコネクションで、サーバサイドにサーバソケットを用意する」 >>>> というのがよいかなという考えです。 >>>> また、頻繁に発生しないのであれば、 >>>> 「で永続化しないコネクション、サーバサイドにソケットを用意する」 >>>> でよいと思っています。この場合の選択肢としてはHTTPに乗っけるというのも一 >>>> つではあるでしょう。 >>>> >>>> ただ、いずれにしろ、どういう通信が必要かは、どういうアプリなのか？が決ま >>>> らないと判断できないので、そこを詰めて行きたいということが言いたかった本 >>>> 質です。 >>>> >>>> TCPとUDPの件も、どのようなアプリで、どのような情報を一時的に欠落しても問 >>>> 題がないかを見極めないと判断ができないでしょう。 >>>> >>>> >>>> (2011/02/22 22:20), sango****@lists***** wrote: >>>>> To：ひろゆきさん、どいさん、皆様 >>>>> >>>>> narunaruです。 >>>>> >>>>> どいさんからのメール読ませて頂きました。 >>>>> 以下に私の見解を記載致します。 >>>>> また一点知識不足で分からない箇所がございます。 >>>>> もしよろしければご教授お願い致します。 >>>>> >>>>>> この辺り語弊があるような気がするのですが、HTTP経由であっても、ソケット通 >>>>>> 信です。単にHTTPというプロトコルがステートレスで基本的には永続化しないと >>>>>> いうだけです。 >>>>> 上記に関して、自分の知識不足な為分からない箇所がございます。 >>>>> よろしければご教授お願い致します。 >>>>> >>>>> HTTPもSocketを使用しているというのは分かるのですが、 >>>>> ただHTTP関係のクラスを使用してサーバーからのPUSH(ブロードキャストメッ >>>>> セージと認識しました)を受信する方法が分からないです。。。 >>>>> そもそも自分のHTTPプロトコルの知識が浅く、ブラウザ等のクライアントからの >>>>> 要求に対してサーバ側がコンテンツを返却する機能としか認識しておらず、必ず >>>>> 双方向の認識でおります。。。 >>>>> >>>>> >>>>>> 頻度にもよりますが、サーバ-クライアント間の通信が頻繁に発生するのであれ >>>>>> ば、サーバソケット（サーバ側にしろ、クライアント側にしろ）に接続するため >>>>>> のオーバーヘッドの方が大きくなる気がします。そのため、つなぎっぱなしのソ >>>>>> ケットを用意することになるでしょう。 >>>>>> その場合、クライアントにサーバソケットを用意する必要はないのではないかと >>>>>> いうのが、今朝の主張です。 >>>>>> >>>>>> また、頻繁に通信が発生せず、接続しっぱなしのソケットを用意しないのであれ >>>>>> ば、クライアント側にサーバソケットを用意する必要はあるのかもしれません >>>>>> が、その頻度であれば、ポーリングで十分だと僕自身は考えています。 >>>>>> >>>>>> みなさんはどう思いますでしょうか？ >>>>> >>>>> どこまでリアルタイムにするのかによるのかなと私は考えております。 >>>>> リアルタイム性が必要ないのであれば、そもそもサーバからブロードキャストさ >>>>> せる必要も無いため、ブロードキャスト受信用のソケットを用意する必要もな >>>>> く、一定間隔でポーリングで良いのでは無いかと思います。 >>>>> >>>>> リアルタイム性を出すのであればUDP用のソケットとTCP用のソケットを両方用意 >>>>> し、サーバからの一方的な通知(例：その他のプレイヤーの情報など)は >>>>> UDP用のソケットで受信し、クライアントからのコマンド(例：移動や戦闘など実 >>>>> 行したコマンドの情報)はTCPを使用するのがスマートなのかと考えておりまし >>>>> た。ただ実装は大変そうですが。。。。 >>>>> >>>>> 他の皆様はどのようにお考えでしょうか？ >>>>> >>>>> >>>>> (2011/02/22 2:05), sango****@lists***** wrote: >>>>>> 裕之さん、みなさん >>>>>> >>>>>> 土肥です。 >>>>>> リアルタイム性ということを非常に気にしているようでしたので、アクション >>>>>> ＲＰＧのような操作性を想定しているのかなと思っていました。シミュレーショ >>>>>> ンゲームに近いイメージでよいのでしょうか？ >>>>>> >>>>>>> また通信の仕組みですが、あくまでソケットを採用するならばという事で回答し >>>>>>> ます。 >>>>>>> クライアントが操作した内容を他のクライアントに通知する流れは以下の通り >>>>>> です。 >>>>>>> >>>>>>> １クライアント ⇒ ２サーバ ⇒ ３他のクライアント >>>>>>> >>>>>>> ２から３へデータをPushするには、クライアント側でソケットを待ち構える必要 >>>>>>> があるのかと考えており、その場合にMobile IPのような形でIPアドレスが変わ >>>>>>> る事に対する何かしらの手当ては必要ではないかと思ってます。 >>>>>> >>>>>> この辺り語弊があるような気がするのですが、HTTP経由であっても、ソケット通 >>>>>> 信です。単にHTTPというプロトコルがステートレスで基本的には永続化しないと >>>>>> いうだけです。 >>>>>> >>>>>> 頻度にもよりますが、サーバ-クライアント間の通信が頻繁に発生するのであれ >>>>>> ば、サーバソケット（サーバ側にしろ、クライアント側にしろ）に接続するため >>>>>> のオーバーヘッドの方が大きくなる気がします。そのため、つなぎっぱなしのソ >>>>>> ケットを用意することになるでしょう。 >>>>>> その場合、クライアントにサーバソケットを用意する必要はないのではないかと >>>>>> いうのが、今朝の主張です。 >>>>>> >>>>>> また、頻繁に通信が発生せず、接続しっぱなしのソケットを用意しないのであれ >>>>>> ば、クライアント側にサーバソケットを用意する必要はあるのかもしれません >>>>>> が、その頻度であれば、ポーリングで十分だと僕自身は考えています。 >>>>>> >>>>>> みなさんはどう思いますでしょうか？ >>>>>> >>>>>> (2011/02/22 1:30), sango****@lists***** wrote: >>>>>>> doiさん >>>>>>> >>>>>>> 裕之です。 >>>>>>> >>>>>>> 今朝Skypeに頂いておりました以下のdoiさんのコメントについて回答いたします。 >>>>>>> >>>>>>> == doiさんからのメッセージ ============================================= >>>>>>> >>>>>>> 動作すべてをデータ通信するかどうか考えないといけないかもですね。 >>>>>>> 1/60秒で通信とか、そういうものをイメージしてるのでしょうか？ >>>>>>> ついでに、クライアント側にサーバソケットではなく、サーバ側にサーバソケッ >>>>>>> トをという仕組みでコネクションを保つのであれば、Mobile IPとか気にする必 >>>>>>> 要はないのかなと思います。 >>>>>>> では。 >>>>>>> =====ここまで=========================================================== >>>>>>> >>>>>>> 1/60ほどのアクションバトル的なイメージでは考えてないです。 >>>>>>> なのでもっと間隔は開いても問題ないと思います。 >>>>>>> >>>>>>> アクション性よりもむしろ、大人数で壮大にバトルを繰り広げるゲームがあまり >>>>>>> なかったと思いますので、操作や俊敏さでは劣っても、とにかく大人数が参加す >>>>>>> る"戦争"というものを表現できればと考えてます。 >>>>>>> >>>>>>> また通信の仕組みですが、あくまでソケットを採用するならばという事で回答し >>>>>>> ます。 >>>>>>> クライアントが操作した内容を他のクライアントに通知する流れは以下の通りです。 >>>>>>> >>>>>>> １クライアント ⇒ ２サーバ ⇒ ３他のクライアント >>>>>>> >>>>>>> ２から３へデータをPushするには、クライアント側でソケットを待ち構える必要 >>>>>>> があるのかと考えており、その場合にMobile IPのような形でIPアドレスが変わ >>>>>>> る事に対する何かしらの手当ては必要ではないかと思ってます。 >>>>>>> >>>>>>> 以上、宜しくお願いします。 >>>>>>> >>>>>>> 裕之 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Sangokushi-dev mailing list >>>>>>> Sango****@lists***** >>>>>>> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Sangokushi-dev mailing list >>>>>> Sango****@lists***** >>>>>> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >>>>> >>>>> _______________________________________________ >>>>> Sangokushi-dev mailing list >>>>> Sango****@lists***** >>>>> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Sangokushi-dev mailing list >>>> Sango****@lists***** >>>> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >>> >>> _______________________________________________ >>> Sangokushi-dev mailing list >>> Sango****@lists***** >>> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >> >> _______________________________________________ >> Sangokushi-dev mailing list >> Sango****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev >> >> > > _______________________________________________ > Sangokushi-dev mailing list > Sango****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/sangokushi-dev
Google Mobile/Open Romance of the Three Kingdoms"GoogleAndroid"
Fork