[Java Device Client]Configurable ping interval

[tameraw]

From @BlueBasher on June 23, 2016 15:50

The Java Device Client sends a ping message every 120 seconds.
This is different than the .NET Client, which sends a ping every 230 seconds.

The behavior of both clients should at least be the same.
Even more preferable would be to be able to configure this interval.

Copied from original issue: Azure/azure-iot-sdks#653

[tameraw]

From @anhashia on June 23, 2016 23:12

Looking into the issue

[tameraw]

From @zolvarga on July 6, 2016 21:30

Hi BlueBasher,

We are going to modify the keep alive interval to use the same value what .NET client is using.
Could you please verify what protocol you are using when you measured the 120 seconds?

Thanks,
Zoltan

[tameraw]

From @BlueBasher on July 7, 2016 16:38

We were using the AQMP protocol.

[tameraw]

From @zolvarga on July 8, 2016 17:32

Hi BlueBasher,

I took a look at the specification for AMQP idle timeout handling.
The standard says: "Each peer has its own (independent) idle time-out. At Connection open each peer communicates the maximum period between activity (frames) on the connection that it desires from its partner. The open frame carries the idle-time-out field for this purpose. To avoid spurious time-outs, the value in idle-time-out should be half the peer’s actual timeout threshold."

To be on the safe side, the client (both our Proton-J and C client) takes the idle timeout value from the server's open frame (which is currently 240 sec) and divides it by 2 to set the client idle timeout. The generated extra traffic is very low, an empty frame in every 2 minutes.
Unfortunately the C# client implements it differently. I propagated the question to the C# team, but it is not a high priority for them to change the behavior as the spec does not mandate how often the client must send based on the peer's value.

Also make the idle timeout configurable does not makes sense as the user of the API would not know what idle timeout value sent by the server in the open frame.

Please let me know if we can close this issue.

Thanks,
Zoltan

[tameraw]

From @BlueBasher on July 13, 2016 14:6

Ok, sounds clear to me. We'll check the total bandwidth usage now with the fix from #655 and if these pings aren't an issue I'll let you know asap.

[tameraw]

From @BlueBasher on July 14, 2016 13:43

Could you verify that you indeed also see that the device sends a ping to the server every 120 sec?
We're currently testing #655 with the version from the develop branch and it looks like it is now sending a ping every 60 seconds.
We've been looking into the proton library as well but haven't found the reason yet why this is.
Are these pings generated by the proton library itself or are they generated by the Java ServerSocket?

[tameraw]

From @anhashia on July 22, 2016 18:41

Looking into this

[tameraw]

From @anhashia on July 26, 2016 0:35

Hi @BlueBasher
I wasn't able to reproduce the issue on latest develop branch using Java AMQP sample. I see the ping sent by the Java AMQP client every 120 seconds. Can you please double check traffic on port 5671 (AMQP over SSL) the traffic sent by the client ? How large is your TCP ping packet length sent by the client ?

[tameraw]

From @BlueBasher on July 27, 2016 14:35

Double checking it. Running tests on multiple machines, will let you know asap. Packet length is 123 bytes.

[tameraw]

From @BlueBasher on July 28, 2016 15:18

I've doubled checked and I indeed also see that the client is sending a ping every 120 seconds.
The additional pings we saw turns out to be the pings coming from the server, these are send every 105 seconds.

Can you explain where this 105 seconds is coming from? And what the rational is with having both client and server initiating pings?

The pings initiated by the client are 123 bytes with ack from server 60 bytes.
The pings initiated by the server are 123 bytes with ack from client 54 bytes.
So that's roughly a total of 271Kb data per day for pings.
I did a 3 hour test with an idle device client on a stable network and the total of pings and reconnects (every 70 minutes to renew SAS token) was a total of 54.5Kb.
So that makes it around 440Kb a day and 13.5Mb per month.

All our devices are connected via mobile networks and data usage is expensive, that's why we're searching for ways to reduce this 13.5Mb.
I understand the 120 seconds pings because of the 1/2 timeout of the Azure 4 minutes.
Is it possible to reduce the number of pings coming from the server? Or to increase the 105 seconds interval?
Or possibly even have the server only initiate pings if it hasn't received a client ping after x time?

[tameraw]

From @anhashia on August 3, 2016 17:54

Looking at it.

[tameraw]

From @olivierbloch on August 3, 2016 22:47

Hi @BlueBasher
You are correct, the client is sending a keep alive message every 120 seconds and the server is also sending a message every 105 seconds.
We have added a couple items in our Service backlog to find the best way to remove any unnecessary traffic and reduce data usage. These should be tackled during next milestone after the current one. Stay tuned!

[tameraw]

From @BlueBasher on August 4, 2016 6:54

Hi @olivierbloch
Cool! Thanks a lot!

[tameraw]

From @anhashia on August 11, 2016 18:17

Current ETA for this is end of September.

[tameraw]

From @anhashia on September 1, 2016 18:22

Issue is being worked upon. Current ETA for this is end of October.

[tameraw]

From @anhashia on September 23, 2016 19:48

Current ETA for this is end of October.

[tameraw]

From @anhashia on October 25, 2016 17:6

Revised ETA is end of Nov.

[tameraw]

From @anhashia on December 6, 2016 0:14

Work in progress !

[anhashia]

Service side change has been made. For increasing limit of AMQP timeout to max 25 minutes for your Hub, please open ticket with Azure Support. Client side SDK change is work in progress. Currently, it is only available in C SDK. Please see Azure/azure-iot-sdk-csharp#46 for more details on this topic.

[jasmineymlo]

Due to lack of interest in this enhancement, we are closing it. Feel free to re-open and discuss if this is not the case.