search

intel / liblwm2m

liblwm2m is an implementation of the LWM2M protocol from the Open Mobile Alliance.
BSD 3-Clause "New" or "Revised" License
44 stars 28 forks source link

Keepalives #14

Closed tobyjaffey closed 8 years ago

tobyjaffey commented 10 years ago

Testing liblwm2m through NAT, I find that after a few minutes the client no longer receives packets sent by the server.

This appears to be because the NAT gateway's punched hole collapses, requiring keepalives.

My solution has been to implement a lwm2m_ping(lwm2m_context_t *) for the client which sends an empty CoAP message to the server. The application then needs to call this on a timer.

Is this the right way, or should an LWM2M client be doing keepalives as "UPDATE" messages? Or something else?

If my way is acceptable, I'll commit and raise a pull request.

Thanks.

dnav commented 10 years ago

Hi,

The LWM2M Technical Specification explains how servers and clients should operate behind a firewall/NAT. It relies on Queue mode and server lifetime. These features are yet-to-be-implemented in liblwm2m. To sum up, the server queues all requests for the client. when it receives a packet from the client (typically a notify or an update), the queued requests are sent.

See chapters 8.3 and 8.2.1 of http://member.openmobilealliance.org/ftp/Public_documents/DM/LightweightM2M/Permanent_documents/OMA-TS-LightweightM2M-V1_0-20140115-D.zip for details.

tobyjaffey commented 10 years ago

As I understand it, Queue mode is required so that sleepy devices can shutdown then pick up messages at a later time. In my case, my device is not sleepy, but a keepalive is required to maintain the NAT gateway's connection.

Perhaps the best answer would be for me to implement periodic "UPDATE" messages (5.2.2), which would (for now) be ignored by the server. That would keep the NAT connection open and move towards a correct solution.

jvermillard commented 10 years ago

The LWM2M spec is quite light on the NAT subject. From a CoAP RFC point of view, Toby's idea is valid (use empty CON messages for checking the connection status).

""Provoking a Reset message (e.g., by sending an Empty Confirmable message) is also useful as an inexpensive check of the liveness of an endpoint ("CoAP ping").""

I agree that queue mode is not convenient if you are connected but just behind a NAT.

dnav commented 8 years ago

Project moved to http://github.com/eclipse/wakaama