1

私は、ユーザー間のリアルタイム(最小ラグ、最大50ミリ秒)の会話(一種のTeamspeak)を許可したい顧客向けにiOSアプリを設計しています。オーディオはライブ音楽でも楽器で再生できるため、ラグは低くする必要があります。そのため、すべてのユーザーが同期する必要があります。すべてのクライアントにオーディオ録音を要求し、他のクライアントに送信する(そして、同時に同じサウンドを聞くようにする)サーバーが必要です。HTTPは管理/実装が簡単で、拡張も簡単ですが、平均的なHTTPリクエストには50ミリ秒以上かかるため(中間レベルのハードウェアの場合)、パフォーマンスが非常に低いため、クライアント間でTCP/UDP接続を開いたままにすることを考えていました。およびサーバー。しかし、私はいくつかの質問があります:

  • サーバーをPythonで開発した場合(たとえば、TwistedMatrixを使用)、そのパフォーマンスはどうですか?
  • 管理(スケーラブル)と開発が難しいため、C++でサーバーを開発できません。
  • TCP / UDP接続を管理するためにNodejs(スケーリングが簡単)を使用した人はいますか?
  • HTTPを使用する場合、Keep-Aliveで十分に高速になりますか?通常、HTTPリクエストの実行に必要な時間は50msを超えるため(開閉接続が難しいため)、全体の手順をその時間より短くしたいと思います。
  • サーバーはLinuxマシンで実行されます。

そして最後に、どのタイプの圧縮を提案できますか?Ogg Vorbisがいいと思いましたが、もっと良いものがあれば(そして、iOSで使用できれば)、変更を受け入れることができます。

ありがとう、ウマル。

4

2 に答える 2

2

What concerns the server, the request itself is not a bottleneck. I guess you have sufficient time to set up the connection, as it happens only in the beginning of the session. Therefore the protocol is not of much relevance.

But consider that HTTP is a stateless protocol and not suitable for audio streaming. There are a couple of real time streaming protocols you can choose from. All of them will work over TCP or UDP (e.g. use raw sockets), and there are plenty of implementations.

In your case, the bottleneck with latency is not the server but the network itself. The connection between an iOS device and a wireless access point (AP) eats up about 40ms if the AP is not misconfigured and connection is good. (ping your iPhone.) In total, you'd have a minimum of 80ms for the path iOS -> AP -> Server -> AP -> iOS. But it is difficult to keep that latency stable. (Typical latency of AirPlay on my local network is about 300ms.)

I think live music over iOS devices is not practicable today. Try skype between two iOS devices and look how close you can get to 50ms. I'd bet no one can do it significantly better, what concerns latency.

Update: New research result!

I have to revise my claims regarding the latency of wifi connections of the iDevice. Apparently when you first ping your device, latency will be bad. But if I ping again no later than 200ms after that, I see an average latency 2ms-3ms between AP and iDevice.

My interpretation is that if there is no communication between AP and iDevice for more than 200ms, the network adapter of the iDevice will go to a less responsive sleep mode, probably to save battery power.

So it seems, live music is within reach again... :-)

Update 2

The ping-interval required for keep alive of low latency apparently differs from device to device. The reported 200ms is for an 3rd gen. iPad. For my iPhone 4 it's more like 50ms.

While streaming audio you probably don't need to bother with this, as data is exchanged on a more frequent basis. In my own context, I have sparse communication between an iDevice and a server, but low latency is crucial. A keep alive therefore is the way to go.

Best, Peter

于 2012-09-06T10:28:49.337 に答える
2

まず、50 ミリ秒未満のレイテンシは得られません。他の人はこれを試しました。たとえばhttp://ejamming.com/を参照してください。このサービスは、ユーザーが行っていることを実行しようとしますが、回線上で音楽的に顕著な遅延が発生するため、多くの人の耳には完全に使用できません。彼らは特別なルーティング技術を使用してレイテンシーを可能な限り低くしていますが、最近私は彼らのサービスが一部のルーター構成では機能しないと聞きました.

第二に、クライアントからサーバーへの遅延はサービスによる遅延よりも悪いため、サーバーで使用する言語はおそらく大きな違いはありませんが、サービスを正しく理解していれば、多くの言語が必要になるでしょう。サーバー(またはサーバースレッド)は、クライアント間でオーディオデータを中継するか、ある種の最小限のミキシングを行うだけです。これは接続あたりの作業量は少ないですが、接続数が多いため、それを処理できるものが必要です。Java、Scala、または Go などに傾倒します。私は間違っているかもしれませんが、これはノードの良いユースケースだとは思いません。私が理解しているように、現時点ではマルチスレッドがうまく機能していません。また、C++ をうんざりしないでください。スケーラブルなサービスは C++ で構築されています。サービスのリレー部分を C++ で構築し、残りを何でも構築することもできます。

第 3 に、圧縮形式を選択する場合、UDP を使用する予定がある場合は、パケット損失に耐えられるものを選択する必要があります。UDP がこれを行う唯一の方法だと思います。vorbis がこのタスクを実行できるとは思いませんが、間違っている可能性があります。頭のてっぺんから、iPhone で動作し、UDP に対応しているものは何もわかりませんが、たくさんあることは確かです。Speex は一例であり、オープンソースです。遅延と品質がニーズを満たしているかどうかわからない.

最後に、率直に言うと、もう少し調査する必要があることが他にもいくつかあると思います。例えば。通常、DNS はローカルにキャッシュされ、http 呼び出しごとにチェックされるわけではありません (ただし、システム/ライブラリに依存する場合があります。少なくともほとんどのシステムは DNS をローカルにキャッシュします)。また、TCP/UDP などのプロトコルはありません。TCP/IP (単に TCP と呼ばれることもあります) と UDP/IP (単に UDP と呼ばれることもあります) があります。2つを1つとして言及しているようですね。この違いは、あなたがしていることにとって非常に重要です。たとえば、HTTP は UDP ではなく TCP の上で実行され、UDP は「信頼できない」と見なされますが、オーバーヘッドが少ないため、ストリーミングに適しています。

編集:スペックス

于 2012-09-07T00:48:11.887 に答える