Inhibit TCP Keep Alive for MQTT #7324
-
Hello! I'm trying to make use of the NATS MQTT bridge for a low power IoT application. My colleague has been trying to get eDRX working, but has noticed that the broker seems to be pinging the client frequently enough to cause a full rx/tx on every paging window (currently set to 10s). This increases our power draw on the modem 4x. We noticed issues #1561 and #1562 which points out TCP keep alive defaults to 15s. It's been resolved in #1562 for the NATS protocol from what I understand, but taking a look at startMQTT it looks to me that MQTT is still using the default and offers no configuration. I have since made and deployed a server including this change, which simply mirrors the fix from #1562 onto MQTT and as expected it's turned off keep alive and therefore allowed eDRX to work effectively. As mentioned in #1561, the go default can lead to tens of MBs of traffic from just the keep alive which is untenable for many IoT situations. For these two reasons I'm wondering if I've missed something as it seems like many use cases would have run up against this issue before? Is there another work around for this issue or is this something that should indeed be fixed up in main? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Will have @kozlovic take a quick peek and comment. |
Beta Was this translation helpful? Give feedback.
-
I believe that is simply because the code crossed path. While PR #1562 was done in August 2020, the MQTT code was merged in November of that year, but its development started before that, so I think I simply did not know or missed that change. I have submitted PR #7329 to make the change. That PR has the change for the websocket listener too, although in that case I am checking with the developer that worked on PR #1562 to know why the change was not made for websocket, so the PR may have to be changed. If not, and once it is merged, I will close this discussion as resolved. |
Beta Was this translation helpful? Give feedback.
I believe that is simply because the code crossed path. While PR #1562 was done in August 2020, the MQTT code was merged in November of that year, but its development started before that, so I think I simply did not know or missed that change. I have submitted PR #7329 to make the change. That PR has the change for the websocket listener too, although in that case I am checking with the developer that worked on PR #1562 to know why the change was not made for websocket, so the PR may have to be changed. If not, and once it is merged, I will close this discussion as resolved.