マルチピア接続の恐怖と嫌悪

iOS開発者DataArtのRoman Ivchenkoによる投稿。

はじめに

サーバー側を使用せずにiOSデバイス間でメッセージ、ファイル、ストリームを交換するための既製のソリューションを少なくとも一度検索したことのある人なら誰でも、iOS 7でリリースされたMultipeer Connectivityフレームワークについて聞いたことがあるでしょう。



全体として、これはシステムの第7バージョンでリリースされた最も革新的なフレームワークの1つです。 少し時代遅れのCoreBluetoothを置き換えることになっていた。



マルチピアコネクティビティの完全なパワーと強さを理解するために、 R＆Dプロジェクトでそれを実行しようとしました 。そのタスクは非常に単純です。プレゼンテーションを共有し、会議や教室などでリスナーとスピーカーデバイス間のスライド切り替えを同期します

短いレビュー

タスクを実装するために、フレームワークは一見、アプリケーションアーキテクチャに非常によく適合しています。 慣例により、スピーカーとリスナーの2種類のユーザーのみがいます。 Multipeer Connectivityは、各タイプのユーザーの機能の実装に必要なクラスを提供するだけです。



この記事では、フレームワークのすべての複雑さを完全に網羅しているわけではありませんが、フレームワークの問題と信頼性について詳しく説明しています。 技術的な詳細はすべて、 アップルのドキュメントに記載されています 。

スピーカー別名広告主

メカニズムは単純です。 セキュリティクラスと暗号化パラメータ、およびMCPeerIDクラスのオブジェクトで初期化されたセッションがあります。このクラスのプロパティはdisplayNameのみであるため、その本質はかなり最小限です。 実際、IDセッションの名前と見なすことができます。 他のユーザーがセッションを見ることができるように、フレームワークはMCAdvertiserAssistantクラスを提供します。MCAdvertiserAssistantクラスは、このセッションについて全員に通知し、それに関する情報を保存するビーコンです。



リスナーがセッションに接続するとすぐに、MCAdvertiserAssistantは「接続の許可/拒否」オプションを使用して、これに関する通知を自動的に表示します。 ユーザー広告主がリスナーの接続を許可するとすぐに、リスナーはセッションに入り、広告主と通信する機会を得ます。

リスナー別名ブラウザ

リスナーの場合、すべてがさらに単純です-開発者は、組み込みのMCBrowserViewControllerフレームワークコントローラーを使用して、最小限の労力でリスナー側のコードを記述します。これにより、広告主へのすべての検索および接続ロジックを完全に処理するか、独自のコントローラーを実装します。 アプリケーションでは、2番目のアプローチが使用されました。これは、最初の方法が、安定性と作業の質の観点から、記事のタイトルと非常によく一致するためでした。 しかし、それについては後で。







ブラウザデバイスの場合、MCNearbyServiceBrowserクラスが提供されます。これは、特定のサービス名内で広告主を検索するレーダーのようなものです。



MCNearbyServiceBrowserとコントローラークラス間の通信は、MCNearbyServiceBrowserDelegateプロトコルを介して実装されます。実装されたデリゲートメソッドのロジックには、広告主の現在アクティブなセッションの表示、状態の変更が含まれます。



MCNearbyServiceBrowserが広告主を招待するブラウザ側でもセッションが作成されていることに注意することが重要です。 広告主がリスナーからの招待を受け入れるとすぐに、デバイスは相互に接続されていると見なすことができます。



メッセージ送信インターフェイスも非常に透過的でシンプルです。広告主とブラウザはお互いにNSData形式でメッセージを送信し、メッセージの受信処理、デバイス間の接続のステータス、ファイル転送の進行状況をMCSessionDelegateプロトコルメソッドを使用して監視できます。

ファーストタッチ

理論的には、一見したところ、実際には、すべてがアーキテクチャ実装の観点から非常に便利に見えます-開発者は最も必要なものにのみアクセスでき、wifi / bluetoothネットワークを扱う複雑なロジックから自分を救います。



いつものように、フレームワークをプロジェクトに統合する前に、誰もがAppleの公式デモプロジェクトでどのように機能するかを確認したいと考えています。 MultipeerGroupChatは基本的に何が起こっているかを示し、スターターパックセット-シミュレーターとiPhone / iPod / iPadで非常に安定して動作します。 3つ以上のデバイスを持っているデモアプリケーションを見る機会がある開発者は、このフレームワークの何かが間違っているとすぐに感じることができます。

ゴーストセッション

すぐに目を引くフレームワークの最初のバグは、すべてをテストするためのシミュレーターとデバイスを備えていても、ゴーストセッションの問題です。



状況を想像してください。 アリスはスピーカー（広告主）、ボブはリスナー（ブラウザー）です。 アリスはプレゼンテーションセッションを開始し、ボブはそれに接続し、一対のメッセージを交換します。すべては問題ありません。 アリスはプレゼンテーションを終了し、セッションを終了します。 1つ目は、ボブが広告主がいないという通知を受け取る可能性です。ボブは、広告主がいないという可能性よりも少し高いです。



ブラウザデバイスの場合、存在しない広告主セッションが無期限に存在する場合があります。 このセッションに接続しようとすると、何も起こらない場合があります。または、しばらくすると、接続試行が失敗状態になります。 広告主が自分のセッションを数回作成した場合、問題は深刻な割合になります。 この場合、1つのデバイスと1つのシミュレーターのみを使用して作業している場合、ネイティブコントローラーMCBrowserViewControllerのブラウザーは、複数の同一のiPhone Simulator adverisersを表示できます。 Appleデモアプリケーションのバグの例：







ちなみに、この問題は、アプリケーションを再起動するか再インストールしても解決できません。 古いセッションはまだあなたを悩ませることができます。 機内モードのオンとオフのみが役立ちます。



回避策：



広告主が1つだけの場合、この広告主の各新しいセッションにはdiscoveryInfoが必要です。 このパラメーターは、ディクショナリ<String、String>という形式で、広告主セッションの開始時に設定され、セッションに関する追加情報が含まれます。 各セッションの一意の識別子としてセッション作成時間を追加することにより、ブラウザー側で、表示するセッションと表示しないセッションを追跡できます。







すべてが正しく実行されると、各デバイス広告主のアクティブなセッションのリストに最新のセッションが含まれます。

セッション内のデバイスの最大数の問題

奇妙ですが、最初はフレームワークの1つのセッションで接続できるデバイスは7つに制限されています。 たとえば、私たちのタスクの目標は、Appleエンジニアのこの制限に明らかに反しています。 このアプリケーションを使用する場合、30〜40台のデバイスが同時に参加できますが、フレームワークに最初からこのような場合の解決策がないのは残念です。



回避策：



セッション内のデバイスの数に対するフレームワークの制限にもかかわらず、セッションの数に制限はありません。 たとえば、1人の広告主が40のブラウザとデータを交換できるようにするには、6つのセッションでの作業をサポートできるソリューションを実装する必要があります。 ただし、ここでも問題があります。ブラウザデバイスには同じ広告主からの複数のセッションが表示されるため、ブラウザに接続できる空き場所がある最新のセッションを表示させる必要があります。 あるいは、同じdiscoveryInfoパラメーターが役立ちます。これには、たとえばセッションインデックスを含めることができます。



広告主の追加セッションの管理メカニズム：









ブラウザ側では、すべてのセッションをインデックスでフィルタリングし、インデックス値が最​​大のセッションを表示する必要があります。 前のセッションで突然空き領域が表示された場合、MCAdvertiserAssistantクラスのdiscoveryInfoプロパティは読み取り専用であるため、広告主への接続を希望するブラウザに通知することはできません。

再接続

私はこのフレームワークの頭痛が松葉杖にとって最も費用がかかると考えています。 Apple側では、既成の再接続メカニズムなしでフレームワークをリリースすることは非常に奇妙だと思います。 通常のケース-ブラウザデバイスはスリップモードになり、15-20秒間広告主からのメッセージを受信できますが、フレームワークは接続が失われたことを通知します...



回避策：



広告主のセッションに再接続するには、常にこのセッションのオブジェクトへのポインタを保存するだけでよく、その場合はこのセッションを使用して広告主に招待状を再送信する必要があります。 実際には、この明白なアプローチは機能しません。 ユーザーが利用可能な広告主のリストを手動で更新し、バックグラウンドを離れた後に切断した広告主に接続したかのように、ブラウザセッションとそれに接続されたすべてのハードリセット、およびプロセスエミュレーションのみが、プロジェクトで役立ちました。







ソリューションは非常に失礼であり、一部のプロジェクトおよびタスクでは絶対に不適切であると確信していますが、明らかに別の方法でそれを行うことは不可能です。 証明 、問題4。

一般的な不安定性、突然の接続喪失

以前のバグと制限が何らかの形で解決できる場合、すべてはすでにAppleエンジニアに依存しています。 私の観察によると、アプリケーションの最も単純なケースをテストしようとする10回の試行のうち、約7から8がほぼ正常に終了しました。 単純なケース-アプリケーションの最大負荷の約10〜15％（広告主と20〜30のブラウザ）。 残りの刑務所事件では、次のことが起こりました。

• ブラウザデバイスは、広告主からのメッセージの受信を突然停止します。フレームワークからの通知、アラート、デリゲートメソッドの呼び出しは無音にすぎません。
• ブラウザデバイスは、接続が失われたメッセージが到着した場合を除き、広告主からのメッセージの受信を突然停止します。理由は明記されていません。
• ブラウザーデバイスまたはそのグループは、重大な遅延を伴ってメッセージを受信します（一方のデバイスではスライドが切り替わり、もう一方のデバイスでは-5秒後にのみ）。
• ブラウザデバイスのいずれかをアドバタイザーに再接続しようとすると、他のブラウザーが落ち始めるか、アドバタイザーからのメッセージの受信速度が急激に低下します。

上記の最初の問題は、ヘルスチェックメカニズムを実装することで解決できます。 一定の間隔で、ブラウザーは軽量のpingメッセージを送信し、応答を待機しています。 回答が数秒以内に届かない場合、広告主への接続が失われていると想定できます。 私たちのプロジェクトでは、このメカニズムは次のように実装されました。

接続デバイスの数を比例して増やすと、システム全体の安定性が低下します

この問題は記事の主要な問題です。 2つまたは3つのデバイスの場合、動作の安定性が多かれ少なかれ正常な状態であり、7または9の場合、より大きな数値は言うまでもなく、安定性はゼロになる傾向があります。 フレームワークは機能しません。 すぐに予約します。「広告主と多くのブラウザ」のような接続について話します。 おそらく他のより安定した構成がいくつかありますが、これは実装が最も簡単であり、フレームワークを使用する場合、すべての構成で等しく安定して動作するようにしたいです。



この問題の解決策はプロジェクトの作業中に見つかりませんでしたが、海の真ん中に埋められた膨脹可能なボートを突き刺すようなものであったため、それ以上は求められませんでした。

恐怖、憎しみ、結論

このプロジェクトに取り組み、このフレームワークを検討している間、私はまだ何か間違ったことをしていて、Appleがそんなにめちゃくちゃになれないことを最後まで望んでいました。 しかし、問題を数時間調査した後、私は開発者からの多くの同様の苦情と同じ問題を扱った良い記事を見つけました。



多くのメッセージは2年前のものであり、これらはすべてフレームワークの子供の病気であると思われるかもしれません。iOS7ではアルファ版で導入されましたが、現在は2016年、iOSの最新バージョンは9.2ですが、問題は同じままでした。



MultipeerConnectivityは、3つ以上のデバイスで使用することを強くお勧めします。 2つまたは3つのデバイスの場合、予測は良好ですが、まだ多くの問題があります。理論上、箱から出すべきものを達成するには、2倍の時間を費やす必要があります。

この記事は、 devforums.apple.com / message / 956192＃956192のトピックに関するコメントとGitHub github.com/DataArt/SmartSlidesのアプリケーションへのリンクで終了します。











問題の確認 ：

www.ymc.ch/en/multipeer-connectivity-a-bag-of-hurt

stackoverflow.com/questions/28418965/multipeer-connectivity-vs-real-time-matches

devforums.apple.com/message/956192#956192

devforums.apple.com/message/982861#982861