通信高速化に関する考察
自メモ＞
ここらへんの話、異機種間のソケット通信プログラム等を
メンテしてたりするわけなんですけど
「Androidが通信遅い＝＞IOS版は安定してるのに＝＞IOS版に悪い評判が立つ」
って論調でなんとかならんかなーと調べてたりしてる状態*1
- 通信抜けしたり
- ディレイしたり
な感じは確かに感じるんだよなorz
下手にスレッド使ってるからかもしれない。
自分がメンテしているコードだと
- Androidは遅い
- ボタン操作もとりあえず別スレッドに先送りするイメージ
- ExecutorService
- Handler
な方針だったりする。体感速くしたいという気持ちはわかるんだけどな。。（汗
まずソケット通信プログラムで
Android側のクライアント側で頑張る話のメモは
この時点では
BufferReader/BufferWriter =>SocketChanel (NIO)
に置き換えて頑張る という話
これでもまだ微妙に遅延するって話で
UDPの話がTLに出てきたのでちょっと考察してみた次第
クライアント側の参考資料）
鯖側の参考資料
鯖側の参考資料
- libeventでechoサーバをつくってみた - in the mythosil
- libeventでHTTPサーバを試す - in the mythosil
- libevent はこんなに便利 - mtaneda’s diary
- Hello World: UDP Listener/Receiver with libevent
- libevent + 使い方 - utahta.log
@kimukou2628 やらないとダメですよ？
2013-01-29 23:30:20 via ついっぷる Pro for iPhone to @kimukou2628
@GOTT_eclair ですよね。でも人にお願いすると、そこら辺(通信確認＆リトライ処理)は面倒な処理＝＞あんまやりたくない ってなる訳なんですよね。TCPで送ろうが欠損や遅延すること有るわけだし。ここらへん考えるの面倒なのは分かるんですが。。。
@kimukou2628 必ずしも必要って事は無いですが、大抵の場合は…もし不達でも動くようにするのであれば、そういうアプリデザインにせざるを得ないんですけど、その辺りの事を理解して貰えるかはどうも怪しい感じですね。
2013-01-30 07:57:35 via ついっぷる Pro for iPhone to @kimukou2628
@GOTT_eclair 難しいですね（汗。特にIOSは出し直しに１〜２週間かかるので ＝＞できれば鯖側でうまく送れなかったら送り直してよ っていう要望が出てたりとか（汗。でもどっちにしろクライアントから「ちゃんと届いたよ」というエコーバックは必要になる気がしますorz
android だとNIOで送受信書くと受信データとかがボロっとまとめて来る(delayしてたのが まとめて3個とか来る)から、送信データに区切り文字等が入ってないとsplitできないんだよね。まあSocketChanelでかくモノ好きもいないでしょうし（苦笑 誰となく・・
@GOTT_eclair ですです。で今回の話でそういう話があったのですが、IOS側は最送要求には応じるけど、再送要求情報をもとに状態リフレッシュはいらないはず というお話になり、なんかすごく違和感があるんですよね。。（Androidは質が悪いから何起きてもおかしくない的な論調ｗ
@GOTT_eclair それだけApple様を信頼してる（信じてる）んでしょうね。。で外れたことが起きたら ソフバンかAUのせい？あたりになるのかな＜もしくは通信相手のAndroidのせい（という主張で色々対策悩ませております＜汗）
http://twitter.com/GOTT_eclair/status/299890254461145088:twitter:detail:right
@GOTT_eclair ほかと比べてなのかなと(汗。結局そこら辺の理解の深くない開発者層もつかえるようなSDK(FW)が望まれるってことなんでしょうね。。WebSocketもデモとか見てる限り結構ブチブチ切れてたんだけどな・・とか思ったりもするわけです
@GOTT_eclair 多分言及されているFWを作るとすると1)データ欠損があった場合にライブラリ内で自動再リクエスト＝＞再受信 2)回線的につながっているけどデータがなぜか送受信ができない状態無くす ですね。で 2)に関してはIOSはそういう状況がない(?)という伝聞
@GOTT_eclair 要はAndroidでも4系で入っている(?)といわれている、「回線の切断状態がIOSでは確実にとれている」＝＞その状態なら 完全に切断＝＞であれば通信対戦を終了させてしまえば良い という論調ですね＜状態リフレッシュ処理ロジック書くと複雑化な面も有り
@GOTT_eclair ただ3Gでアンテナたってても通信できない事をAndroidでは頻繁に経験したことあるのですがIOSでは起こらないのかな。。とは疑問に思いつつ。結局のところ対戦タイムアウト値を超えたら切断としているので完全にUIロックにはならないのですが
http://twitter.com/GOTT_eclair/status/299919797473402880:twitter:detail:right
http://twitter.com/GOTT_eclair/status/299920653262389249:twitter:detail:right
@GOTT_eclair やっぱり起こるんですね・・。基本社内だとWifiでしか 3Gのテストも回線が混んでない昼間 とかいう状態で夜中のEモバが遅延する時間帯とかのテストが漏れちゃってるんです（自分がやってた Andoridの処理もそう＜夜試してみたら3秒タイムアウトだとNG
@GOTT_eclair だから正直な処、ソケットで繋ぎっぱ っていう形でなくて RESTでやり取りするような形式が理想形なのかな とか思う点もよくありつつ。速度面で非採用なのかもしれませんが・・
@jagd5168 さんにコメントを頂いた。
有能な人ほど鍵になりがちなので直接引用できないのは残念*2
富士通のUDPベース高速ファイル転送、
これ2009年です。RTT回避あたりの着目点はシルバーバレットと同じ。
RT FTPの約20倍の転送速度を実現する技術「BI.DAN-GUN（ビーアイドットダンガン）」http://jp.fujitsu.com/journal/strength/technologies/200906-02.html
http://twitter.com/kimukou2628/status/296276504843804672:twitter:detail:right
シルバーバレットはデータ転送用のUDPとは別に制御用のTCP接続を浸かっているのに対して、
富士通のBI.DAN-GANはUDPのみでエラー訂正情報付きでやり取りしている。
http://twitter.com/kimukou2628/status/296280375892779009:twitter:detail:right
@kimukou2628 UDP のポートと TCP のポートとは別物なので同時に同じポートで Listen していても問題ないです。
http://twitter.com/kimukou2628/status/296284206517067777:twitter:detail:right
@kimukou2628 IPパケットに付いているTCPかUDPかの識別子で判断して、
TCP/UDPレベルのデータ部でそれぞれ宛先ポート番号を持ってます。
ここらへんは OS のカーネルレベルでやってると思います (よく知らんが)。
@kimukou2628 コード上には TCP と UDP で Listen 状態の書き方が違うので
(Java で TCP なら ServerSocket#accept()、UDP なら DatagramSocket#receive())
受信後にTCPかUDPか分岐する…
@kimukou2628 必要はないですね。
よく考えたらデータ転送に UDP、再送制御に TCP を使うシルバーバレット方式って
転送接続を UDP にして制御接続上で再送要求付けた FTP 仕様に包括できそうな希ガス。
いい加減 FTP は滅びて頂きたいが。
転送接続に UDP を使う FTP 拡張仕様とか RFC になってんじゃないかと思ったが引っかからなかった。
TFTP が UDP だがあれはまた目的も仕様も違うし。
通信自体の仕様的な考察）
「説明書読まなくていいぐらい機能はシンプルで」という人と 「機能的に物足りない」っていう人のどちらも満たす場合って1)extentionタイプだと追加apk 2)apkにリソースだけあって(課金／レベルUP等で)解禁 3)鯖で管理 って流れになると思うけど管理側コスト感次第？
それぞれには問題があって 1)はインストールの同意が不便(億劫に感じさせる)、管理側も面倒 2)はデータ移行が難しい＜特に異機種間（IOS/And/WP）3)Webアプリっぽくなるのでオフラインでは遊べない なところだけど・・・
2)でアプリ内課金とかした場合、購入情報にバイナリ関連付け添付できるイメージだといいのになとは思ったけど データ膨大？＜GoogleDriveと連携出来ればOK? 別鯖から購入情報を元にして再リフレッシュって手もあるけど、それ何時のタイミングにやるかだよな（毎回起動時だと重
現実的に、起動時に毎回念のため最新のスコアを送信してる ＝＞ NWがつながらないと起動できない（論理矛盾が発生するので？起動させない）なの見てるんだけど 1)NW繋がってるかチェック 2)送信失敗した時にキャッシュしておいて、キャッシュ残ってたら送信 が現実的でないのかな？
ココらへんの話は A)使用者の視点で考えてるのか B)仕様決定者がシンプルな物(設計書)を求めているのか C)実装者(メンテ者？）が楽な(工数がかからない？ バグが起きにくい？ 状態が単純化でクリア？)シンプルな物を求めてるのか 次第でスコープが違うのかなと(B>C>A？
日本だと電車に乗っている時にスマホゲー ・駅間(トンネルだけでなく)で通信が瞬断 とか有るわけだけど、そういう場合ソケット通信なら再接続とか考えないとダメなわけだよなとか感じたりも。connection Lostを退室条件にしているチャットとかあるけど動き的に微妙
https通信(SSL通信)に関してのメモ）
@kimukou2628 アプリから接続しようとした場合は接続エラーになります。ブラウザから直接Blobのファイルにアクセスすると「この証明書は無効ですが表示ますか」的なダイアログが出ますね。どちらも挙動としてはオレオレ証明書と同じです。
@jagd5168 ありがとうございます。 1)SSLSocket でつないだ場合は接続エラー 2)WebViewで表示していた場合は オレオレ証明書扱い になる感じですね。ふむふむ。
2013-02-24 21:07:26 via YoruFukurou to @jagd5168
@kimukou2628 なんすかそのphpやmysqlのような設計方針は、、、orz
2013-02-24 21:12:26 via web to @kimukou2628
@naka_aki_spl 「セキュリティ担保したから優良顧客がつくわけではない」という奴ですね。逆に遅くなった、元に戻せ みたいなの書かれる感じかなと＜体感的な話。とくにマスコミさん(<= セキュリティクラスタの方々の警告)とかに煽られる or 大事件が起こる とかでないと
@kimukou2628 優良顧客ってゆーか、長い目でみればそれって残念顧客なのだろうなあ。成果を急ぎすぎてるっていうか。
2013-02-24 21:20:06 via web to @kimukou2628
@naka_aki_spl まあ世の中に溢れてるコピペ元コードもSSL絡みのお話はあんまり書いてないので、JSやPHPやPerlとかでコピペ切貼リリースとかだとですね。まあ其のためにnginxやapache辺りでの対応だろうけど、そこら辺設定できる人が結構少ないかなと
@kimukou2628 鯖の問題だとプログラマがアレでも影響無いという面はあるけど、鯖管屋がアレだと同じことになるんで、、、w
2013-02-24 21:27:09 via web to @kimukou2628
@naka_aki_spl 今は鯖管いなくて、クラウド運用＋PGが鯖設定する って感じですね。単に日々の鯖管監視等の業務が開放されてるだけ（でもそういいながらVPSの方が勝手に再起動してたりとかメンテナンス情報の話が上レベルで止まってたりする＜だから自動再起動設定は必要
そもそも暗号化通信とかって、べき論では遣るべきだけど(そこまで対応して集客効果等があるのかという)コスト論 には対抗できないんだよな。。チープな辺にスペックケチってる国内スマホで軽量に動く暗号化通信用FW(鯖側実装例有)があってライセンスも厳しくなければ使ってるだろうし
余計なデータ削って1/2-1/4サイズだから速いって話だけですし。。
