-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Registration Message Flow #7
Comments
Using a separate CON response (see rfc 7252, 5.2.2) and waiting for that ACK of the response may ensure, that the client received the registration response. Piggyback flow (currently normally used, rfc7252, 5.2.1):
After sending the reponse, the LwM2M server has no information about the client receiving the response. Separate flow (rfc 7252, 5.2.2):
Waiting for the the ACK from the LwM2M Client the server may ensure, that the responses is received from the LwM2M client. |
@boaks after reading the spec I don't think it's mandatory to wait for the end of registration for accepting read/write on the DM interface. Would that cause a problem? or maybe I'm misunderstanding the spec. |
@jvermillard |
It bother me to use seperate ack/response for register because it make the whole process heavier and longer (I count bytes on cellular networks or SMS) so I prefer to keep it like that. Do you think we can close this issue? or do you want some spec clarification? |
From my view, this issue was opend because of different incompatible implementations. |
I think, though I haven't report this issue, I'm not the one to close it :-). |
According to comments => to be closed |
Just for those, who read issues later: And to be frank: I just don't see a clarification, how a LWM2M client should react on device management operations before it receives the answer from the registration. Please keep in mind, that message order is not granted in UDP. A server which sends the ACK and short afterwards a Request (e.g. READ) is not able to ensure the receiving order of the client. If the order is wanted, a separate response is required. if the order is undefined, the specification should clarify the processing, if the order has changed! |
The last OMA-TS-LightweightM2M-V1_0-20161031-D said : So it seems that now separate response is mandatory for Register Request. |
I fail to see how this mandates a separate response. The problem fixed by this is issue #162. Regards |
It depends on what means "The LWM2M Server MUST NOT perform any operation on this interface until the registration of this LWM2M Client completed." I understand it as "the server must not send any request until the client receive the response". So, If the server need to know the response is well received, it must used a confirmable separate response. Am I wrong ? |
The intended meaning was : "the server must not send any request before sending the ack to the registration message." |
As message order is not granted in UDP, I'm not sure to understand why we want to be sure that server will send the ack before the read (#162). |
I agree with @sbernard31, this new sentence about the server behaviour is quite unclear:
If the client ignores the commands received before the registration ack, it seems to me that relying on the retransmission mechanism is enough to ensure the messages order. |
Noted. |
Thx David :) |
Closing issue per agreement above and no further comments since 11/2016 |
It can happen that the Client receives a request (Read or Write operations) before the registration is completed, (it received
2.01 Created
response).How should the client respond?
What the Server should expect?
Due to UDP re-ordering this can happen any time.
A time out or backoff could cause problems with the sleep mode of the Client.
Expected behaviour must be defined in the TS.
The text was updated successfully, but these errors were encountered: