スマートフォンでの挙動
1,271 views
Skip to first unread message
水本弘貴
Sep 11, 2011, 2:26:02 AM9/11/11
to nodejs_jp
初めまして、いつも記事を参考にさせていただいています。
水本と申します。
現在、ウェブでの対戦ゲームをnode.js+socket.io+expressで作成しています。
PCからnode.jsサーバに接続するときは問題なく非同期通信が行えるのですが
スマートフォンで接続するとき、数十秒単位で、接続が切れ、つなぎ直す
という挙動が続いてしまいます。
みなさんが作成したnode.jsサーバにスマートフォンで接続したとき
このような問題は起きていないのでしょうか？教えてください。
水本と申します。
現在、ウェブでの対戦ゲームをnode.js+socket.io+expressで作成しています。
PCからnode.jsサーバに接続するときは問題なく非同期通信が行えるのですが
スマートフォンで接続するとき、数十秒単位で、接続が切れ、つなぎ直す
という挙動が続いてしまいます。
みなさんが作成したnode.jsサーバにスマートフォンで接続したとき
このような問題は起きていないのでしょうか？教えてください。
平岩二郎
Sep 11, 2011, 3:12:12 AM9/11/11
to node...@googlegroups.com
どうもjiroです。はじめまして！
お話を見させていただいた感じ、
「スマートフォン」とはAndroid端末のことっぽいので、
その前提をお話させていただきます。
筋違いだったらごめんなさい＞＜
Androidの標準ブラウザはWebSocket非対応なので、
（iOSのsafariは対応しているみたいですが。。。）
ブラウザアプリの場合は、XHR-Pollingで通信することになります。
つまり、数十秒でhttpの繋ぎなおしが発生しますので、
その分オーバーヘッドがあります。
特に3G回線だと、結構ブチブチ切れる感じになると思いますよ。
ネイティブアプリを視野に入れるのであれば、
WebSocketクライアントがあるみたいなので、
動作の幅は広がりますが。。。
http://d.hatena.ne.jp/Nubilum/20110525/1306341271
どちらにしろ、スマホの場合は、
回線の弱さや、コネクションが頻繁に切れること（地下鉄乗ったり）を
ある程度考慮された方がいいかと思います。
水本弘貴
Sep 11, 2011, 12:14:19 PM9/11/11
to nodejs_jp
jiro様
返答ありがとうございます。
はいandoroidでの現象です、どのキャリアかを書かず申し訳ありません。
XHR-pollingの仕様で切れてしまうのですね。
スマートフォンは確かに回線が切れることを前提にした処理を加えないと駄目ですね。
今回でコード自体が原因というわけではなさそうなので、
再接続時の処理を加えて改善していきたいと思います。
ありがとうございました。
On 9月11日, 午後4:12, 平岩二郎 <jiro.hiraiwa....@gmail.com> wrote:
> どうもjiroです。はじめまして！
>
> お話を見させていただいた感じ、
> 「スマートフォン」とはAndroid端末のことっぽいので、
> その前提をお話させていただきます。
> 筋違いだったらごめんなさい＞＜
>
> Androidの標準ブラウザはWebSocket非対応なので、
> （iOSのsafariは対応しているみたいですが。。。）
> ブラウザアプリの場合は、XHR-Pollingで通信することになります。
>
> つまり、数十秒でhttpの繋ぎなおしが発生しますので、
> その分オーバーヘッドがあります。
> 特に3G回線だと、結構ブチブチ切れる感じになると思いますよ。
>
> ネイティブアプリを視野に入れるのであれば、
> WebSocketクライアントがあるみたいなので、
> 動作の幅は広がりますが。。。http://d.hatena.ne.jp/Nubilum/20110525/1306341271
>
> どちらにしろ、スマホの場合は、
> 回線の弱さや、コネクションが頻繁に切れること（地下鉄乗ったり）を
> ある程度考慮された方がいいかと思います。
>
> 平岩 二郎
> jiro.hiraiwa....@gmail.com
返答ありがとうございます。
はいandoroidでの現象です、どのキャリアかを書かず申し訳ありません。
XHR-pollingの仕様で切れてしまうのですね。
スマートフォンは確かに回線が切れることを前提にした処理を加えないと駄目ですね。
今回でコード自体が原因というわけではなさそうなので、
再接続時の処理を加えて改善していきたいと思います。
ありがとうございました。
On 9月11日, 午後4:12, 平岩二郎 <jiro.hiraiwa....@gmail.com> wrote:
> どうもjiroです。はじめまして！
>
> お話を見させていただいた感じ、
> 「スマートフォン」とはAndroid端末のことっぽいので、
> その前提をお話させていただきます。
> 筋違いだったらごめんなさい＞＜
>
> Androidの標準ブラウザはWebSocket非対応なので、
> （iOSのsafariは対応しているみたいですが。。。）
> ブラウザアプリの場合は、XHR-Pollingで通信することになります。
>
> つまり、数十秒でhttpの繋ぎなおしが発生しますので、
> その分オーバーヘッドがあります。
> 特に3G回線だと、結構ブチブチ切れる感じになると思いますよ。
>
> ネイティブアプリを視野に入れるのであれば、
> WebSocketクライアントがあるみたいなので、
> 動作の幅は広がりますが。。。http://d.hatena.ne.jp/Nubilum/20110525/1306341271
>
> どちらにしろ、スマホの場合は、
> 回線の弱さや、コネクションが頻繁に切れること（地下鉄乗ったり）を
> ある程度考慮された方がいいかと思います。
>
> 平岩 二郎
atsuya
Sep 11, 2011, 7:06:03 PM9/11/11
to node...@googlegroups.com
こんにちは、高木です。
https://github.com/Jxck/Socket.IO/wiki/Configuring-Socket.IO
Androidであれば、Androidのデフォルトのブラウザがflashをサポートしていると思うので、transportにflashを使うのは可能かと思います。flashが使えるなら、xhr-pollよりは良いレスポンスが得られると思います。
もしくは、AndroidのFirefoxなんかはもしかしたらwebsocketをサポートしているかも？
- 高木
2011/9/11 水本弘貴 <shuiben...@gmail.com>:
KOMATSU Kensaku
Sep 11, 2011, 7:45:36 PM9/11/11
to node...@googlegroups.com
小松です。
以前、websocket-flash & Android2.2 で系を組んだ時、しばらく動かしていると
・端末が異常に熱くなる
・Webアプリが固まるような挙動を示す
・電池があっという間に無くなっていく
という経験をしました。
かなり頻繁にデータ送信する系だったのと、ほぼ一年前ということで情報古いですが、
注意はしたほうがいいと思います。
＃やっぱ、ネイティブ動作がいいですよね:-)
2011年9月12日8:06 atsuya <asoft...@gmail.com>:
atsuya
Sep 11, 2011, 7:51:26 PM9/11/11
to node...@googlegroups.com
こんにちは、高木です。
お、これはいい情報ですね。実際にAndroidでflashを指定してsocket.ioを使おうかと思っていたので、注意してみます。
- 高木
2011/9/11 KOMATSU Kensaku <kensaku...@gmail.com>:
水本弘貴
Sep 11, 2011, 9:48:46 PM9/11/11
to nodejs_jp
みなさん回答ありがとうございます。
flashで書くことで対応することも可能なのですね。
指摘を受けてもう一度プログラムの挙動を確かめていたのですが。
PCで現在使用しているwebブラウザはfirefoxであり、
androidでのwebブラウザは初期のものと、dolphinブラウザです。
pcでのnode.jsサーバの接続もxhr-pollingを使用しているのですが、
androidでのような、かってにreload(接続と切断)といった現象は起こっておりません。
同様のつなぎ方(規格)でもPCとandroidで挙動が変わるんですね。
flash含めスマートフォンでの開発はやはりむずかしいですね
いろいろと勉強になります!
On 9月12日, 午前8:51, atsuya <asoftoni...@gmail.com> wrote:
> こんにちは、高木です。
>
> お、これはいい情報ですね。実際にAndroidでflashを指定してsocket.ioを使おうかと思っていたので、注意してみます。
>
> - 高木
>
> 2011/9/11 KOMATSU Kensaku <kensaku.koma...@gmail.com>:
flashで書くことで対応することも可能なのですね。
指摘を受けてもう一度プログラムの挙動を確かめていたのですが。
PCで現在使用しているwebブラウザはfirefoxであり、
androidでのwebブラウザは初期のものと、dolphinブラウザです。
pcでのnode.jsサーバの接続もxhr-pollingを使用しているのですが、
androidでのような、かってにreload(接続と切断)といった現象は起こっておりません。
同様のつなぎ方(規格)でもPCとandroidで挙動が変わるんですね。
flash含めスマートフォンでの開発はやはりむずかしいですね
いろいろと勉強になります!
On 9月12日, 午前8:51, atsuya <asoftoni...@gmail.com> wrote:
> こんにちは、高木です。
>
> お、これはいい情報ですね。実際にAndroidでflashを指定してsocket.ioを使おうかと思っていたので、注意してみます。
>
> - 高木
>
>
>
>
>
>
>
>
> > 小松です。
> > 以前、websocket-flash & Android2.2 で系を組んだ時、しばらく動かしていると
> > ・端末が異常に熱くなる
> > ・Webアプリが固まるような挙動を示す
> > ・電池があっという間に無くなっていく
> > という経験をしました。
> > かなり頻繁にデータ送信する系だったのと、ほぼ一年前ということで情報古いですが、
> > 注意はしたほうがいいと思います。
> > ＃やっぱ、ネイティブ動作がいいですよね:-)
> > 2011年9月12日8:06 atsuya <asoftoni...@gmail.com>:
>
>
>
>
>
>
> > 小松です。
> > 以前、websocket-flash & Android2.2 で系を組んだ時、しばらく動かしていると
> > ・端末が異常に熱くなる
> > ・Webアプリが固まるような挙動を示す
> > ・電池があっという間に無くなっていく
> > という経験をしました。
> > かなり頻繁にデータ送信する系だったのと、ほぼ一年前ということで情報古いですが、
> > 注意はしたほうがいいと思います。
> > ＃やっぱ、ネイティブ動作がいいですよね:-)
>
> >> こんにちは、高木です。
>
> >>https://github.com/Jxck/Socket.IO/wiki/Configuring-Socket.IO
>
> >> Androidであれば、Androidのデフォルトのブラウザがflashをサポートしていると思うので、transportにflashを使うのは可能かと思います。flashが使えるなら、xhr-pollよりは良いレスポンスが得られると思います。
>
> >> もしくは、AndroidのFirefoxなんかはもしかしたらwebsocketをサポートしているかも？
>
> >> - 高木
>
> >> 2011/9/11 水本弘貴 <shuibenhong...@gmail.com>:
> >> こんにちは、高木です。
>
> >>https://github.com/Jxck/Socket.IO/wiki/Configuring-Socket.IO
>
> >> Androidであれば、Androidのデフォルトのブラウザがflashをサポートしていると思うので、transportにflashを使うのは可能かと思います。flashが使えるなら、xhr-pollよりは良いレスポンスが得られると思います。
>
> >> もしくは、AndroidのFirefoxなんかはもしかしたらwebsocketをサポートしているかも？
>
> >> - 高木
>
KOMATSU Kensaku
Sep 11, 2011, 10:00:03 PM9/11/11
to node...@googlegroups.com
小松です。
xhr-pollingで、HTTP(TCP)を再接続するのはPCでもモバイルでも同じなのですが、
経験上 Mobile(3G回線)では、HTTP再接続にコストがかかる（要は、時間がかかる）
傾向があり、普通のネット接続に比べて不自然な動きをします。なので、PCでも
３G回線経由で接続しようとすると、多分怪しい動きになると思います。
逆を言えば、Androidでも、Wi-fiでつなげば xhr-pollingでもそこそこスムーズだと
思います。
何故に、３G回線でやたら再接続コストがあがるのかは不明ですが。。。
2011年9月12日10:48 水本弘貴 <shuiben...@gmail.com>:
atsuya
Sep 12, 2011, 1:55:18 PM9/12/11
to node...@googlegroups.com
こんにちは、高木です。
http://mobilehtml5.org/
モバイルデバイスにおけるhtml5の対応表を見つけたので紹介します。どうやらAndroidのFirefoxならwebsocketに対応しているようですね。
- 高木
2011/9/11 KOMATSU Kensaku <kensaku...@gmail.com>:
水本弘貴
Sep 13, 2011, 3:37:09 AM9/13/11
to nodejs_jp
こんにちは水本です。
小松様、高木様返信ありがとうございます。
androidのfirefoxで問題のnode.jsサーバにアクセスしてみたところ
標準ブラウザ時に起こる勝手にreconnectされるという問題も無く、無事動作しました。
不思議なのは,
firefoxでうまくいった時のログを見てみると接続方式がxhr-pollingだったのです。
そして接続方式が同じなのに挙動が違う(出ているログが違う)ことです。
****firefox*****
info - socket.io started
debug - client authorized
info - handshake authorized 6913620102108384518
debug - setting request GET /socket.io/1/xhr-polling/
6913620102108384518?t=1315897926830
debug - setting poll timeout
debug - client authorized for
debug - clearing poll timeout
debug - xhr-polling writing 1::
debug - set close timeout for client 6913620102108384518
{ '0': 'connected' }
debug - パッケト送信
debug - set close timeout for client 939614808494293282
debug - discarding transport
debug - cleared close timeout for client 939614808494293282
debug - setting request GET /socket.io/1/xhr-polling/
939614808494293282?t=1315898404277 //a
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 939614808494293282
debug - clearing poll timeout //****
debug - xhr-polling writing 8::
debug - set close timeout for client 939614808494293282
debug - xhr-polling closed due to exceeded duration
//b
以下//a→//bでループ
****************
****標準ブラウザ****
info - socket.io started
debug - client authorized //a
info - handshake authorized 9772262671806736765
debug - setting request GET /socket.io/1/xhr-polling/
9772262671806736765?t=1315898666625
debug - setting poll timeout
debug - client authorized for
debug - clearing poll timeout
debug - xhr-polling writing 1::
debug - set close timeout for client 9772262671806736765
{ '0': 'connected' }
debug - setting request GET /socket.io/1/xhr-polling/
9772262671806736765?t=1315898667188
debug - setting poll timeout
debug - clearing poll timeout
debug - パッケト送信
debug - set close timeout for client 5002989641581778631
debug - discarding transport
debug - cleared close timeout for client 5002989641581778631
debug - setting request GET /socket.io/1/xhr-polling/
5002989641581778631?t=1315898207453
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 5002989641581778631
debug - clearing poll timeout //
****
info - transport end
debug - set close timeout for client 5002989641581778631
debug - cleared close timeout for client 5002989641581778631
{ '0': '5002989641581778631::disconnected!!' } //
切断ログ
debug - discarding transport
debug - setting request GET /socket.io/1/xhr-polling/
5002989641581778631?t=1315898207453
debug - setting poll timeout
debug - clearing poll timeout
debug - xhr-polling writing 7:::1+0
debug - set close timeout for client 5002989641581778631
warn - client not handshaken client should reconnect
info - transport end
debug - cleared close timeout for client 5002989641581778631
debug - discarding transport
debug - discarding transport
debug - xhr-polling received data packet 0::
debug - got disconnection packet //b
以下//a→//bでループ
**********
debug - clearing poll timeout //****
のあとで transport endが起きてwarnが出ているというのが主な違いですが、
この挙動の違いをブラウザの違い、通信方式の違いと言ってしまってよいのでしょうか?
長文、質問ばかりで申し訳ありません。
小松様、高木様返信ありがとうございます。
androidのfirefoxで問題のnode.jsサーバにアクセスしてみたところ
標準ブラウザ時に起こる勝手にreconnectされるという問題も無く、無事動作しました。
不思議なのは,
firefoxでうまくいった時のログを見てみると接続方式がxhr-pollingだったのです。
そして接続方式が同じなのに挙動が違う(出ているログが違う)ことです。
****firefox*****
info - socket.io started
debug - client authorized
info - handshake authorized 6913620102108384518
debug - setting request GET /socket.io/1/xhr-polling/
6913620102108384518?t=1315897926830
debug - setting poll timeout
debug - client authorized for
debug - clearing poll timeout
debug - xhr-polling writing 1::
debug - set close timeout for client 6913620102108384518
{ '0': 'connected' }
debug - パッケト送信
debug - set close timeout for client 939614808494293282
debug - discarding transport
debug - cleared close timeout for client 939614808494293282
debug - setting request GET /socket.io/1/xhr-polling/
939614808494293282?t=1315898404277 //a
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 939614808494293282
debug - clearing poll timeout //****
debug - xhr-polling writing 8::
debug - set close timeout for client 939614808494293282
debug - xhr-polling closed due to exceeded duration
//b
以下//a→//bでループ
****************
****標準ブラウザ****
info - socket.io started
debug - client authorized //a
info - handshake authorized 9772262671806736765
debug - setting request GET /socket.io/1/xhr-polling/
9772262671806736765?t=1315898666625
debug - setting poll timeout
debug - client authorized for
debug - clearing poll timeout
debug - xhr-polling writing 1::
debug - set close timeout for client 9772262671806736765
{ '0': 'connected' }
debug - setting request GET /socket.io/1/xhr-polling/
9772262671806736765?t=1315898667188
debug - setting poll timeout
debug - clearing poll timeout
debug - パッケト送信
debug - set close timeout for client 5002989641581778631
debug - discarding transport
debug - cleared close timeout for client 5002989641581778631
debug - setting request GET /socket.io/1/xhr-polling/
5002989641581778631?t=1315898207453
debug - setting poll timeout
debug - discarding transport
debug - cleared close timeout for client 5002989641581778631
debug - clearing poll timeout //
****
info - transport end
debug - set close timeout for client 5002989641581778631
debug - cleared close timeout for client 5002989641581778631
{ '0': '5002989641581778631::disconnected!!' } //
切断ログ
debug - discarding transport
debug - setting request GET /socket.io/1/xhr-polling/
5002989641581778631?t=1315898207453
debug - setting poll timeout
debug - clearing poll timeout
debug - xhr-polling writing 7:::1+0
debug - set close timeout for client 5002989641581778631
warn - client not handshaken client should reconnect
info - transport end
debug - cleared close timeout for client 5002989641581778631
debug - discarding transport
debug - discarding transport
debug - xhr-polling received data packet 0::
debug - got disconnection packet //b
以下//a→//bでループ
**********
debug - clearing poll timeout //****
のあとで transport endが起きてwarnが出ているというのが主な違いですが、
この挙動の違いをブラウザの違い、通信方式の違いと言ってしまってよいのでしょうか?
長文、質問ばかりで申し訳ありません。
> http://mobilehtml5.org/
> モバイルデバイスにおけるhtml5の対応表を見つけたので紹介します。どうやらAndroidのFirefoxならwebsocketに対応しているようですね。
>
> - 高木
>
> 2011/9/11 KOMATSU Kensaku <kensaku.koma...@gmail.com>:
> モバイルデバイスにおけるhtml5の対応表を見つけたので紹介します。どうやらAndroidのFirefoxならwebsocketに対応しているようですね。
>
> - 高木
>
>
>
>
>
>
>
>
> > 小松です。
> > xhr-pollingで、HTTP(TCP)を再接続するのはPCでもモバイルでも同じなのですが、
> > 経験上 Mobile(3G回線)では、HTTP再接続にコストがかかる（要は、時間がかかる）
> > 傾向があり、普通のネット接続に比べて不自然な動きをします。なので、PCでも
> > ３G回線経由で接続しようとすると、多分怪しい動きになると思います。
> > 逆を言えば、Androidでも、Wi-fiでつなげば xhr-pollingでもそこそこスムーズだと
> > 思います。
> > 何故に、３G回線でやたら再接続コストがあがるのかは不明ですが。。。
> > 2011年9月12日10:48 水本弘貴 <shuibenhong...@gmail.com>:
>
>
>
>
>
>
> > 小松です。
> > xhr-pollingで、HTTP(TCP)を再接続するのはPCでもモバイルでも同じなのですが、
> > 経験上 Mobile(3G回線)では、HTTP再接続にコストがかかる（要は、時間がかかる）
> > 傾向があり、普通のネット接続に比べて不自然な動きをします。なので、PCでも
> > ３G回線経由で接続しようとすると、多分怪しい動きになると思います。
> > 逆を言えば、Androidでも、Wi-fiでつなげば xhr-pollingでもそこそこスムーズだと
> > 思います。
> > 何故に、３G回線でやたら再接続コストがあがるのかは不明ですが。。。
KOMATSU Kensaku
Sep 13, 2011, 4:04:42 AM9/13/11
to node...@googlegroups.com
小松です。
デスクトップ版ではver5.0以前では、WebSocketのバージョンが00で、socket.ioの
WebSocket実装とマッチしているのですが、about:configで、websocketのenableが必要。
＃なぜ、デフォルトdisableになっているかは、僕のブログが参考になると思います。
ver6.0以降は、（多分）バージョンが10で、socket.ioの現行実装と、アンマッチなのと、
ベンダープレフィックス(moz)が必要というところで、FireFoxでも xhr-pollingになっちゃってる
んだと思います。
ただ、モバイルsafariと、FireFoxモバイルでのreconnect挙動の違いは、確かに説明できないですね。
不思議。
XHRの実装に、細かい違いがあるのかなぁ。。。
2011年9月13日16:37 水本弘貴 <shuiben...@gmail.com>:
Reply all
Reply to author
Forward
0 new messages