Критический результат при отправке push-уведомления с нашего сервера

У нас есть приложение на appstore и с зарегистрированными push-уведомлениями. Они успешно работали все время, но теперь мы попытались отправить «глобальный» толчок, и случилось что-то странное. Это то, что мы имеем в нашем файле .php на стороне сервера:

//Loop through tokens in tokenArray $i = 0; $t = 0; foreach($tokenArray as $token) { $t++; // Make notification $msg = chr(0) . pack('n', 32) . pack('H*', $token) . pack('n', strlen($payload)) . $payload; // Send $result; if($message != null) { $result = fwrite($fp, $msg, strlen($msg)); } if ($result) $i++; } // Close the connection to the server fclose($fp); if($i == 0) { echo 'The message was not delivered to anyone out of '.$t.'.'; } else { echo 'The message was delivered to '.$i.' out of '.$t.'.'; } 

Код до этого всегда работал, и он все еще делает. TokenArray содержит таблицу с токенами, например, в SELECT Token FROM Tokens; от нашего SQL. Это работает.

Во время разработки, когда регистрировались только наши собственные токены, он всегда говорил: «Сообщение было доставлено до 4 из 4», хотя мы удалили наши приложения с наших телефонов. Теперь мы попытались отправить все ≈1100 зарегистрированных токенов с помощью этого кода. Сообщение было отправлено, и выход был «Сообщение было доставлено на 588 из 1194.» И мы сами не получили уведомления! Что это значит?

Примерно через 5 минут я отключил tokenArray с массивом, содержащим только мои собственные токены, и отправил новый push, и я получил его на своем телефоне. Я также знаю, что «действующий» токен существует в предыдущем «tokenArray», который не прошел (я проверил).

Является ли push-уведомление азартной игрой !? Что это означает, когда if($result) терпит неудачу? И почему он потерпел неудачу более 500 раз?

Сертификаты и .pem и .p12 и т. Д. Все работают, единственное, что я сделал от push1 до push2, – это использовать другую таблицу, которая является клоном из исходной таблицы на моем SQL-сервере. В таблице 2 есть только мои токены, и это сработало. Никаких других изменений не было. Только SELECT Token FROM Tokens2 , а позже я доказал, что все токены в Tokens2 существуют в Tokens2 Я понятия не имею, получил ли кто-нибудь толчок, или если «удачный» 588 из 1200, которые все еще имеют установленное приложение, получил его.

Что вызывает это? Мы не посмеем отправить еще один, если половина из них уже получила его. Есть ли какой-то предел тому, как быстро я могу отправить толки сразу? Или что мы делаем неправильно ?! Пожалуйста, помогите, спасибо.

В вашем основном цикле не учитываются случаи, когда Apple закрывает соединения сокета. Как упоминалось Эраном, если вы отправляете недействительный токен, Apple закрывает соединение в этот момент, любые дальнейшие записи с использованием fwrite не удастся. Поэтому, если ваш 589-й токен недействителен, никакой другой push-адрес не будет отправлен Apple.

Вот простое решение для того, что вписывается в вашу логику; эта часть заменяет оператор if в основном цикле:

 if ($result) { $i++; } else { fclose($fp); // Add code here to re-open socket-connection with Apple. } 

Помимо расширенного формата уведомлений, упомянутого Eran, вы также можете использовать API обратной связи APNS для запроса Apple для недействительных токенов и очистки их от вашей базы данных. Вы можете найти более подробную информацию об этом здесь: http://bit.ly/14RPux4

Нет никаких ограничений на количество push-уведомлений, которые вы можете отправить сразу. Я послал тысячи через несколько секунд. Единственное реальное ограничение – это связь между вами и серверами APNS.

Ну, я не знаю php, поэтому ваш код мне не помогает. Однако, исходя из вашего описания, вероятно, некоторые из токенов устройства в вашей базе данных недействительны. Когда сервер Apple получает уведомление с недопустимым токеном устройства, он закрывает сокет. Если вы уже писали больше сообщений после плохого токена, они не дойдут до Apple. Только после того, как вы обнаружите, что сокет закрыт и откройте новый, ваши сообщения попадут в Apple. Если вы не используете расширенный формат уведомлений, было бы неплохо начать использовать его – таким образом вы можете получить от Apple идентификатор недопустимого сообщения и очистить свою базу данных от недействительных токенов. Однако даже использование расширенного формата не гарантирует, что вы обнаружите все ошибки (если вы не захотите отправлять сообщения очень медленно и проверить ответы об ошибках от Apple после каждого отправляемого сообщения).