Recently Apple modified their Technical Note TN2265 - Troubleshooting Push Notifications. They added a section about throughput and error checking.
This is taken from that section :
Here's how to check for errors when using the enhanced binary interface. Keep writing until a write fails. If the stream is ready for writing again, resend the notification and keep going. If the stream isn't ready for writing, see if the stream is available for reading.
If it is, read everything available from the stream. If you get zero bytes back, the connection was closed because of an error such as an invalid command byte or other parsing error. If you get six bytes back, that's an error response that you can check for the response code and the ID of the notification that caused the error. You'll need to send every notification following that one again.
Once everything has been sent, do one last check for an error response.
It can take a while for the dropped connection to make its way from APNs back to your server just because of normal latency. It's possible to send over 500 notifications before a write fails because of the connection being dropped. Around 1,700 notifications writes can fail just because the pipe is full, so just retry in that case once the stream is ready for writing again.
My APN provider server is written in Java using blocking sockets (SSLSocket).
Is it possible to do what they suggest in the bold text using SSLSocket?
After a write fails, can I write again to the socket? Doesn't the socket close in this case? How do I know if the stream is ready for writing again? How do I know if it is available for reading?
I want to avoid using NIO, because that would require using SSLEngine, which seems painful to implement.