iOS Push通知配信サーバーのコネクション管理

前回のエラーハンドリングの話に続いてコネクション管理について。今どきPush通知配信サーバーを自前で用意する事は少ないかもしれないけど、そういう人向けの内容。

コネクションの管理

APNsのドキュメントにこうしろと書いてある。

Best Practices for Managing Connections

You may establish multiple connections to the same gateway or to multiple gateway instances. If you need to send a large number of push notifications, spread them out over connections to several different gateways. This improves performance compared to using a single connection: it lets you send the push notifications faster, and it lets APNs deliver them faster.

Keep your connections with APNs open across multiple notifications; don’t repeatedly open and close connections. APNs treats rapid connection and disconnection as a denial-of-service attack. You should leave a connection open unless you know it will be idle for an extended period of time—for example, if you only send notifications to your users once a day it is ok to use a new connection each day.

Local and Push Notification Programming Guide: Provider Communication with Apple Push Notification Service

つまり

• 通知毎に接続をOpen/Closeするな、APNsはそれをDoSと扱う
• Openしたまま維持しろ
• 大量に配信したい場合は複数接続を張るといいよ
• 1日に一回送るぐらいなら、その度に新しく接続を作ってもいいよ

 となるので、この通りに実装する。Webサーバーでユーザーからのリクエストをトリガーにして送るとその度にOpen/Closeになる、よってユーザー間等の通知を頻繁に送るアプリの場合はアプリケーションサーバーから通知配信処理のプロセスを分離する方式になるかと。

Gateway Serverからエラーレスポンスが返ってきた場合、向うから接続を切ってくる。その時は新しい接続を作る。

apns-proxy-serverでもスレッド毎にGateway Serverとの接続を持つようにして、接続の維持と並列化を実現している。

原因不明のBroken Pipeエラー

データフォーマットのエラーや、Invalid Tokenエラーとは関係無く、Broken Pipeに遭遇する事がある。Gateway Serverがなんらかの理由でコネクションを切るからだと思われるが、こちらとしては接続を張りなおして、送ろうとした通知からリトライするぐらいしかやれる事は無い。