sango****@lists*****
sango****@lists*****
2011年 2月 22日 (火) 23:54:13 JST
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
Google携帯★Open三国志（GoogleAndroid）
Fork