ClientRegistryListener execute during client registration

[tomaszszlek]

Hi,
We discovered issue with custom ClientRegistryListener.
We implemented some logic in registered method which is time consuming.
The issue is that registered method code is invoked by the same thread which handle client registration.
It means that when client is registering, server should register client and then invoke Listener method.
We saw that javadoc of registered method says

Invoked when a new client has been registered on the server.

while the method is invoked before client complete registration.

[sbernard31]

If you want to do time consuming task, you should do that in new thread.

About Leshan, I don't think it could be a good idea to create a new thread automatically, I rather prefer to let the choice to Leshan users.

About complete registration, the response to the register request is not confirmable, this means that we can not know if the device receive the response or not. So at server point of view we consider that the client is registered as soon as we add the registration in the store. So I think the javadoc is correct. (but maybe we should be more explicit)

Anyway, we should probably send the response before invoking listener method, but keep in mind that packet could be lost or recieve in wrong order with UDP.

[tomaszszlek]

Thank you for answer.
I agree about time consuming task but let's imagine scenario when in listener you would like to read some particular resources of client - you can't do it because client is pending registration and server will receive timeout.

Regarding javadoc - for me registered "client registered on the server" = server sent response, this is something that made me confused.

Because of scenario I described above I think that sending response before invoking listener makes a lot of sense.

About UDP - when packets will be damaged during server registration response, client will need to resend registration request because response will be incorrect ? How Leshan will behave when request/response sent by server will be damaged due to UDP nature ? I found in COAP specification following:

CoAP implements a lightweight reliability
mechanism, without trying to re-create the full feature set of a
transport like TCP. It has the following features:

o Simple stop-and-wait retransmission reliability with exponential
back-off for Confirmable messages.

o Duplicate detection for both Confirmable and Non-confirmable
messages.

Thank you in adavance.

[sbernard31]

I agree about time consuming task but let's imagine scenario when in listener you would like to read some particular resources of client - you can't do it because client is pending registration and server will receive timeout.

Not exactly because of retransmission mechanism (see)

Because of scenario I described above I think that sending response before invoking listener makes a lot of sense.

I will see if I can change the code in that sense.

About UDP - when packets will be damaged during server registration response

damaged ? With UDP, packets can be reordered or lost but not damaged.

[tomaszszlek]

Yes sorry, i meant package reorder.
Regarding packets reorder I have question - when I call Leshan method leshanServer.send(destination, request, timeout) then Leshan waits for response from client. What will happen if client will send response after that timeout ? Will Leshan server just ignore it ?

[sbernard31]

Yes it should.

[sbernard31]

I try to fix this in the #249 PR. Please tell us, if it behave better now.

[tomaszszlek]

Thank you, I am testing it now and give you feedback

[boaks]

Thank you for answer.
I agree about time consuming task but let's imagine scenario when in listener you would like to read some particular resources of client - you can't do it because client is pending registration and server will receive timeout.

Did you read OMA OpenMobileAlliance/OMA_LwM2M_for_Developers#7 ?

client is pending registration and server will receive timeout.

Sure? I thought the "last" specification was, that a LWM2M client ignores request from a LWM2M server until it receives the registration reponse. This should then trigger the request retries, which then (mostly) are received after the registration response.
What exactly is the behaviour of yout client, that it runs into a timeout?

The alternative approach using a CON response for registration has been seen as to "heavy".

[boaks]

About UDP - when packets will be damaged during server registration response, client will need to resend registration request because response will be incorrect ? How Leshan will behave when request/response sent by server will be damaged due to UDP nature ? I found in COAP specification following:

CoAP implements a lightweight reliability
mechanism, without trying to re-create the full feature set of a
transport like TCP. It has the following features:

o Simple stop-and-wait retransmission reliability with exponential
back-off for Confirmable messages.

o Duplicate detection for both Confirmable and Non-confirmable
messages.

"damaged due to UDP nature" I'm not sure, what kind of damage you expect.

1. CoAP tries to use "very small messages", so that the UDP layer doesn't usually requires assembling of a message-sequence. So, based on one message, which fits into the (smallest)
   MTU on the transmission, which kind of damage do you expect?

Consider, the damage would be that hard, that californium doesn't detect the message as a CoAP message, the message is droped.

Consider, the damage is only that hard, that californium detect the message as a CoAP but as damaged: if its a CON message a RST is sent. Otherwise it's ignored.
(the degree of damage is currently implementation depending and a PR in californium is pending the process more damaged CON messages with RST, but I'm not sure, it this is going to be merged.)

As long as your CoAP message is detected as being a damaged CoAP message, the retry with a proper one will then be processes without concerning the previous damaged dialog.

But if a CoAP message is processed as CoAP and then repeated, then you may get either the previous response, or, if that is still not available (too long time for registration callback), the duplicate request is ignored (assuming that the first request is still being processed and the response will the be sent back to the client.)

[sbernard31]

Should be fixed by #249.