Link failure detection [question]

[sunng87]

Hi, we are using a long running pushy 0.3 connection for apple push and it works great by far. But one thing I'm not quite confident about is the link failure detection.

As you may know, there could be a situation when the connection is broken without a FIN sent to client (e.g. net wire unplugged). Then there's no way to know the connection failure on pushy side. Pushy will still hold the ApnsConnection, and Netty's writeAndFlush will always success in both handler and its listener. However, no data will actually be sent to APNS.

Basically, we used heart-beat packet to detect failure in a long-live connection. However, Apple doesn't provide such kind of packet in their protocol. And even worse, there's no response for a success call. So we are totally unaware of the packets' state.

Although we haven't got this issue, but I'm afraid it's possible. So I just want to know if any of you and pushy users had this issue, and how do you deal with that? Do you keep the connection in your application, or just close it after some time ?

Thanks everybody!

[jchambers]

We are, indeed, aware of the issue (I think it first came up in #14). I regret that I don't have a great solution to offer right now, but now that I'm thinking about it more, I'm surprised that SO_KEEPALIVE doesn't solve this problem for us. Let me investigate that a little more thoroughly.

Cheers!

[sunng87]

Thanks for quick response. Actually, I think this is not a Pushy issue but a defect in design of APNS protocol. The lack of successful response makes it almost impossible to detect connection state.

To minimize the risk of writing to a dead connection, I'm going to recreate the connection every, for example, 5 minutes.

Edit: sorry I didn't notice this is already listed in the known issue. But I hope you can keep this open for users to track.

[jchambers]

Actually, I think this is not a Pushy issue but a defect in design of APNS protocol.

Agreed, but I'd still like to work around it if we can ;)

Regarding SO_KEEPALIVE specifically, the problem seems to be that connections have to sit for a really long time (hours by default) before keepalive packets will start flowing. This is configurable at the OS level, but not really on a per-process basis. Lower-level networking stuff can configure the keepalive interval for individual sockets, but that's not really something we can do here (or anywhere in Java, really).

Will keep thinking about it.

[jchambers]

With all of the attention SSL heartbeats have been getting lately, it occurs to me that they may also be a viable way to detect link failure, though I am (again) surprised that it's not just happening automatically. I'll admit I know very little about SSL heartbeats, but it seems like an avenue worth exploring.

[eager]

I am (again) surprised that it's not just happening automatically

Given how APNs is designed to avoid any sort of acknowledgement, I imagine they have SSL heartbeats disabled on their side.

[jchambers]

Though we still have no way to detect link failure, #116, #117, and #118 should jointly cover this issue. I regret that we can't do something that offers stronger guarantees.