[Apple notifies APNs] I wonder if PushSharp has been used by many people ?, Apnspushsharp

[Apple notifies APNs] I wonder if PushSharp has been used by many people ?, Apnspushsharp

I haven't written anything for a long time. I have recently studied Jenkins. If you are interested, you can come and have a chat. It is very important to learn DevOps.

Recently, I am in charge of a project that requires the notification of APNs. It is quite difficult to develop this independently, so we use the third-party open-source PushSharp. There are many notifications, such as Amazon, GSM, BlackBerry, Windows, and apple.

First, let me talk about the problems encountered during use. When intensive requests are sent to the APNs server after the connection, there are usually two situations: InvalidToken and ConnectionError, however, there is a small potential rule in it, that is, continuous feedback on InvalidToken, whether you are the correct Token in the future, it will reject your connection and directly feedback ConnectionError, which I often encounter, after checking du Niang, someone said that Apple's APNs was used to prevent malicious attacks. Think about what APNs can endure if people generate a random invalid Token to request you in large numbers, it must be rejected consecutively. Of course, it will certainly be able to be sent again after a while, because it will not ban IP addresses.

If no notification is sent successfully, you can filter out ConnectionError and send the notification again. Also, if you think its sending request is too slow, you can adjust the number of internal connection object pools. The Code is as follows:

Var config = ApnsConfigurationFactory. createConfiguration (); var apnsBroker = new ApnsServiceBroker (config); apnsBroker. changeScale (10); // number of internal connection object pools. We recommend that you use up to 10. Generally, a quad-core server can be controlled at a maximum of 40% apnsBroker. start ();

If the machine is strong enough, you can open more points, 20, 30, 50 can all be, the more open, he can process large concurrent request notifications faster.

By the way, after deploying the production environment of PushSharp, I found that sending requests in large concurrency will cause service downtime and found two major problems:

I. The Buffer part of the Console. WriteLine method will cause memory overflow. Therefore, I have confined this Code. The Code is adjusted as follows:

        static Log()        {            counters = new Dictionary<CounterToken, Stopwatch>();            loggers = new List<ILogger>();#if DEBUG            AddLogger(new ConsoleLogger());#endif        }

The above is the static constructor in the PushSharp. Core. Log class adjusted the code, and I will not allow the execution of Console. WriteLine

2. The problem is caused by the internal failure of the thread security queue. I will replace it with the thread security queue, as shown in the figure below:

Location: PushSharp. Apple. ApnsConnection

 

After the above changes, the system is still running well and has not experienced any downtime. We also hope to give you a warning.

If you need the changed DLL, contact me.