-
Notifications
You must be signed in to change notification settings - Fork 407
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
Send registration event after sending response to device #249
Conversation
I have tested your PR and it works a little bit strange.
` I would expect that client will start register, then server receive the response, finally after 30 seconds my listener code will execute but behavior is different.
|
You're right. I thought that "exchange complete" notification was called after the response was sent, but it seems I was wrong ... : / . So, if I understand correctly how californium( the JAVA CoAP library we use) works, I can't see any good solution for this problem... @sophokles73 What did you think about that ? Did you see any solution to sent registration notification after we send the CoAP response ? |
registrationService.fireUnregistered(deregistration.getRegistration()); | ||
} | ||
registrationService.fireRegistred(registration); | ||
Runnable whenSended = new Runnable (){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whenSent
@sbernard31
So working on californium eclipse-californium/californium#202 I would guess 2 will be the right. So may be we introduce/extend a "callback", which informs us, if the message is send or droped. |
I like the idea. |
Sorry for joining the party this late but I am not sure if I understand the intention fully. Do you guys want to make sure that the event is only fired once we are sure that the LWM2M client has received the server's response to its registration request? If not then IMHO it doesn't really make a difference which stage of Cf processing the response we use as the trigger for firing the event. The most likely reason for the client not receiving the response will be that the message gets lost during transmission. It is pretty unlikely that the message gets lost while flowing through Cf's stack... |
No, we want to make sure event is only fired once we sent the message. |
4a1af01
to
533fb58
Compare
Ok, I have taken a close look at your code @sbernard31. The problem is that
|
Because,
(This is not the case here but we can also imagine that the response is sent using block mode and we would like to be notify when the last block is sent) |
In case we have no I will do that and @tomaszszlek would be able to test it and tell us if it's better. |
That's true but you cannot rely on the order the UDP packets will be delivered to the client anyway so I do not see why this should be a problem ... |
According eclipse-californium/californium#104 messages should be dropped, if they were "sent" into the wrong DTLS session. Though the message process flow seems to be potential asynchron/parallel, the right time point in my opinion would be the one, when the DTLS session used for encryption is known and either matching on not matching (and therefore the message should be dropped). |
I agree but most of the time users want to send request just after registration is done. (using registered event). Like David explained here it works even with disordered message . But most of the time, messages are sent in right order, so this change can avoid the first retransmission. |
533fb58
to
3155c31
Compare
@tomaszszlek I pushed the solution described by @sophokles73. Does it better for you ? |
any news on this? FMPOV this is an improvement anyway so I would be ok to merge this even without further feedback from @tomaszszlek ... |
8cf9e02
to
2be3144
Compare
Finally, integrated in master (commit ece1c3e) |
…ipse-leshan#249) * Provide proper OSGi meta-data for all modules eclipse-leshan#248 Signed-off-by: Dirk Fauth <dirk.fauth@googlemail.com>
This PR was motivated by #247.
It aims to send registration event (register, update, deregister) after we effectively send the LWM2M response to the device. Even if UDP does not guarantee ordered and like it is explain here it is not mandatory to make it works, this could be an improvement most of the time.
It is largely inspired by what I have done here for #16, but trying to keep the
LwM2mResponse
immutable.