为什么只有一些设备来接收推送通知 [英] Why would only some devices be receiving push notifications

问题描述

我成立了一个推送通知服务通知发送到基于RSS源的客户端。我有一个运行的每一分钟，看是否有新的职位被添加到饲料的服务。如果是这样，则服务将发出一个通知到所有的客户端。然而，有些人一直在抱怨说，他们没有收到任何推送通知。下面是我用它来发送消息的功能：

I set up a push notification service to send out notifications to clients based on an RSS feed. I have a service that runs every minute to see if a new post was added to the feed. If so, the service will send out a notification to all the clients. However, some people have been complaining saying that they are not receiving any push notifications. Here is the function that I use to send out the messages:

function _sendMessages($tokens, $message) {
        $payload['aps'] = array('alert' => $message, 'sound' => 'default');
        $payload = json_encode($payload);

        $context = stream_context_create();
        stream_context_set_option($context, 'ssl', 'local_cert', $this->certificate);
        stream_context_set_option($context, 'ssl', 'passphrase', '*********');

        $apns = stream_socket_client('ssl://' . $this->server . ':' . $this->port, $error, $errorString,60, STREAM_CLIENT_CONNECT, $context);

        foreach($tokens as $row) {
            $apnsMessage = chr(0) . chr(0) . chr(32) . pack('H*', str_replace(' ', '', $row->device_token)) . chr(0) . chr(strlen($payload)) . $payload;
            $fwrite = fwrite($apns, $apnsMessage);

            if (!$fwrite) echo 'push error';
            else echo 'push success';
        }

        fclose($apns);
    }

难道我做错了什么？ PHP可以不处理通过这个去为循环数千次的信息流通过该连接？

Am I doing anything wrong? Can PHP not handle going through this for loop thousands of times and streaming messages over the connection?

推荐答案

除了已经被别人提出的建议，这里是一个事物的清单时要考虑推不工作。

Other than the suggestions already made by others, here's a checklist of things to consider when pushes don't work.

1. 如果您的总推包超过了256个字节，包括最初的头，令牌和JSON有效载荷，APNS会简单地放弃它。如果您不使用高级错误检测，你永远不会知道，直到你的用户开始抱怨。你所要做的就是检查连接codeD包的大小，也就是实际的数据，你会抽空电线，如果它的长度超过256个字节，无论是大小拒绝，或切断一些消息文本和连接code一遍，直到它为＆lt; = 256字节


2. 如果有什么不对以任何方式与您的有效载荷，包括长度，APNS将其删除，APNS会下降的连接​​了。


3. 如果您有持久连接，这是闲置约20分钟左右，APNS会悄悄​​地断开连接。你必须ppared为$ P $和重新连接。


4. 如果您的APNS证书已过期或不正确的，你继续尝试以太高的速率连接，APNS将黑名单的时间未知期间您的IP地址，但它是超过几分钟得多了，甚至一个小时以上。


5. 如果iPhone不支持3G的接收，但是拥有无线网络，它会尝试使用推送通知。如果你是在防火墙领域，不允许苹果的网络出站连接，你的iPhone将无法打开一个套接字APNS，你是SOL。


6. 我不知道，如果你的SQL数据库与推更新令牌每一​​个客户端连接到APNS的时间。有一个静态推令牌的数据库是一个问题，因为推令牌不留一样永远 - 它甚至是这么说的APNS编程指南。 iPhone是应该得到推每次启动时间标记，而且传达到服务器端（和我相信你可以优化这 - iPhone可以持久保存最后一个令牌且仅当它已经改变了发送）。但是有些东西会导致推令牌改变，如重新注册了iPhone的推动，我不知道还有什么。我所知道的是，依靠推令牌就像一个GUID是自找麻烦。下一次令牌变化，如果不更新您的数据库，再见推送到客户端。

1. If your total push packet exceeds 256 bytes, including the initial header, token, and JSON payload, APNS will simply drop it. If you are not using the "advanced" error detection, you will never know until your users start complaining. What you have to do is check the encoded packet size, that is, the size of the actual data you will pump down the wire, and if it's longer than 256 bytes, either reject it, or cut off some of the message text and encode it again until it is <= 256 bytes long.
2. If there is anything wrong with your payload in any way, including the length, APNS will drop it, and APNS will drop your connection, too.
3. If you have a persistent connection, and it is idle for about 20 minutes or so, APNS will silently drop the connection. You have to be prepared for that and reconnect.
4. If your APNS certificate has expired or is incorrect, and you continue trying to connect at too high a rate, APNS will blacklist your IP address for an unknown period of time, but it's much more than a few minutes, maybe even an hour or more.
5. If the iPhone does not have 3G reception, but does have WiFi, it will try to use that for push notifications. If you are in a firewalled area that does not allow outbound connections to Apple's network, your iPhone will not be able to open a socket to APNS and you are SOL.
6. I am not sure if your SQL DB is updated with push tokens every time a client connects to APNS. Having a static database of push tokens is an issue, because push tokens don't stay the same forever - it even says so in the APNS programming guide. The iPhone is supposed to get the push token each time it launches, and communicate it to the server side (and I am sure you can optimize this - the iPhone could store the last token persistently and send it only if it has changed). But some things can cause the push token to change, such as re-registering the iPhone for push, and I am not sure what else. All I know is that relying on a push token to be like a GUID is asking for trouble. The next time the token changes, if your DB is not updated, goodbye push to that client.

希望这有助于。

这篇关于为什么只有一些设备来接收推送通知的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！