Hikaru様 ご指摘の通り、TCPでやるからには遅延や切断を前提とした設計思想にしなくてはいけないですね。 でもあまりに頻繁に大きめの遅延が生じたため、これが普通なのかと困惑していたところなのです。
KOBA789様 Nagleアルゴリズムについてはsocket.ioではデフォルトで無効になっているそうです。 https://groups.google.com/forum/?fromgroups=#!msg/socket_io/65jbtL9_gC0/SP3XqfhFqsIJ またnetモジュール利用時は無効に設定してみましたが、大きな変化は見られませんでした。 また複数セッションのラウンドロビンによるアイデアは面白そうです。 ちょっとテストしてみたいと思います。ありがとうございます。 それから、こちらで調べた中で無線アクセスポイントの周波数帯によって遅延が大きく異なり、 2.4GHz帯より5GHz帯を用いると良いという情報を見つけました。 http://telec.org/column/column2.html FPSなどの低レイテンシ必須のゲームをやる方や、AV機器に利用する方は5GHz帯を用いて 遅延を回避しているそうです（そんなの常識だろ、という話でしたらすいません）。 当方の環境では5GHz帯対応のAPが無く、ずっと2.4GHz帯だけでテストを行ってきました。 5GHz帯のアクセスポイントを購入してみますので、そちらも試してまた報告させていただきたいと思います。 2013年5月20日月曜日 19時25分08秒 UTC+9 KOBA789: > > KOBA789 です。 > > まず Nagle > アルゴリズムが無効になっているかどうか、確認するといいかもしれません。デバイス、環境によっては無効にできないこともあるかもしれませんが。 > > また、Hikaru 様のおっしゃるとおり、理想は UDP の利用だと思いますが、ブラウザからは今のところ使えませんので、別の手法を考えてみました。 > 少しトリッキーな方法ですが、レイテンシ問題に対して、対策がないこともないです。思いついただけで実証してはいないので効果の程は不明ですが、少しでもお役に立てればと思い、書いておきます。 > > > TCP > の特性上、パケットは直列化されます。つまり、1つでもパケットが遅延すれば、そのあとのパケットはそのパケットが到達するまでアプリケーションに渡されません。 > > そこで、クライアント側では WebSocket(= TCP) > のセッションをたくさん張り、それらの接続に対してメッセージの送信をラウンドロビンします。また、メッセージにはそれぞれタイムスタンプやシーケンス番号など、ソート可能な情報を付与するようにします。 > > > サーバー側では受け取ったメッセージをそのソート可能な情報に基いてアプリケーションで直列化します。この時、番号が飛んでしまったりしても無視し、常に最新のメッセージのみを処理し、番号の若いものが遅れて飛んできても無視するようにします。こうすることで > > > TCP の特性による遅延は少しだけ減らせるかと思います。ただし、セッションの多重化はネットワークや OS > のネットワークスタックに多めの負荷をかけることになりますので、そのあたりは天秤にかけて判断する必要があるかと思います。もっとも、最近の機器ではほぼ無視できそうですが。 > > > > > 2013年5月20日 19:12 Hikaru <[email protected] <javascript:>>: > > 無線通信で突発的な遅延や切断等がしばしば起こるのは極自然なことだと思います > > どうしようもできないと分かって設計をするので、問題とはならないのではないでしょうか？ > > > > 純粋になるべく遅延がないようにしたいのであればUDPを使うくらいしかないと思いますが > > 株取引のリモートとかでないのなら設計思想を変えるのが正解のような気もします > > > > > > 2013年5月20日月曜日 12時49分57秒 UTC+9 mrksy: > >> > >> Hikaru様、KOBA789様 > >> > >> レスありがとうございます。 > >> また返答が遅くなり申し訳ありませんでした。 > >> > >> デバイスや環境を変えながら試してみたところ、お二方のアドバイス通りネットワーク側の問題だったようです。 > >> ブラウザのJavaScriptから50msec間隔でダミーデータを送信し、Node.js側で受信間隔を調べるだけの > >> テストプログラムを作成して試したところ、有線接続の環境下では問題の症状が発生しませんでした。 > >> > >> 確認した環境は、以下のようなものです。 > >> (1)iPad(Safari) --無線--> AP --無線--> MacBook(Node.js) > >> ⇒最初の状況と同じく、受信間隔が100〜500msecになることがある > >> > >> (2)WinPC1(Chrome) --有線--> AP --無線--> MacBook(Node.js) > >> ⇒上記(1)よりは改善されるが、受信間隔が100〜300msecになることがある。 > >> > >> (3)WinPC1(Chrome) --有線--> AP --有線--> WinPC2(Node.js) > >> ⇒受信間隔はすべて100msec以下に収まる > >> > >> > >> 以上からネットワークの問題であると判断しましたが、やはり実際には無線環境下でも動作させたいと > >> 考えています。これ以上はこちらのユーザーグループで質問すべきではないかもしれませんが、 > >> 私以外のNode.jsでリアルタイムアプリケーションを作成している方はこのような問題は起きていない > >> のでしょうか？ちなみに、APは2機種を試してみましたが同じ傾向でした。 > >> > >> 何かご存知の方おられましたらお教えください。 > >> > >> > >> > >> 2013年5月18日土曜日 22時04分54秒 UTC+9 KOBA789: > >>> > >>> KOBA789 です。 > >>> > >>> サーバー側の計算資源の不足で数百msもの遅延が発生しているとは考えづらいですね。 > >>> 一度サーバー側でパケットをキャプチャしてネットワークとアプリケーションソフトウェアのどちらに問題があるのか > を切り分けるとよいかもしれません。 > >>> またその時、iOS デバイスからではなく、優先のイーサネットで接続された別のデバイスからや、iOS > >>> > >>> > デバイスが接続しているものと同じ無線アクセスポイントに無線接続してる別のデバイスなどからもダミーデータを送信し、パケットの流れを確認することでより深い検証ができるかと思います。 > > > >>> > >>> > >>> 2013年5月18日 22:00 Hikaru <[email protected]>: > >>> > 単純なコードで数百msも遅延が発生することなんてありえないのでは？ > >>> > > >>> > 回線など外部の問題ではないのでしょうか？ > >>> > > >>> > -- > >>> > > >>> > --- > >>> > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > >>> > このグループから退会し、メールの受信を停止するには、[email protected]<javascript:> > >>> > > >>> > にメールを送信します。 > >>> > その他のオプションについては、https://groups.google.com/groups/opt_outにアクセスしてください。 > >>> > > >>> > > > > > -- > > > > --- > > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > > このグループから退会し、メールの受信を停止するには、[email protected]<javascript:>にメールを送信します。 > > > > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 > > > > > -- --- このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 このグループから退会し、メールの受信を停止するには、[email protected] にメールを送信します。 その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
