Hi all
Californium handles the blockwise transfer of large notifications in a separate exchange (as it should be done). If the
client does not get the blocks in time, only this separate exchange is cleaned up.
I have been running some tests with Copper and observe keeps working over a long time, with and without getting the remaining
blocks.
From the logs, it is hard to see why the LWM2M Server rejects the notifications (probably because the relation was dropped,
but why?).
I could not find the details about the proxy issue. However, make sure you dimension the cleanup timeout according to
the speed of your client. Also make sure that all blocks of a large notification can be collected between notifications; a minimum period (pmin) might be necessary, if notifications are too big.
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx]
On Behalf Of rahxepon12 .
Sent: Freitag, 18. Dezember 2015 11:32
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] RE : Clean-up mechanism for blockwise transfer is removing observe state
Hi,
I have posted about the same issue while using the proxy example in a project. So this not only related to observe.
On Thu, Dec 17, 2015 at 11:33 AM, Gilles Cannenterre <gcannenterre@xxxxxxxxxxxxxxxxxx> wrote:
Hi Julien,
Yes we are. The observe is OK, notifications are well received and displayed but at some point the server start rejecting notifications.
{capture from leshan UI}
11:17:20.321 NON-2.05 437 4a6e97e1 Observe: Hex:e4280a00000000
11:17:20.377 NON-2.05 439 4a6e97e1 Observe: Hex:e4280a00000001
11:17:25.432 NON-2.05 441 4a6e97e1 Observe: Hex:e4280a00000000
11:17:25.487 NON-2.05 443 4a6e97e1 Observe: Hex:e4280a00000001
11:17:30.551 NON-2.05 445 4a6e97e1 Observe: Hex:e4280a00000000
11:17:30.551 RST- 445
11:17:30.596 NON-2.05 447 4a6e97e1 Observe: Hex:e4280a00000001
11:17:30.596 RST- 447
11:17:35.662 NON-2.05 449 4a6e97e1 Observe: Hex:e4280a00000000
11:17:35.663 RST- 449
{capture from leshan UI}
Gilles Cannenterre
Main: +33 (0)5 61 00 52 90
Fax: +33 (0)5 61 00 51 46
gcannenterre@xxxxxxxxxxxxxxxxxx Lake Park
ZAC de l\'Hers - Allée du Lac
BP 87216
31672 Labège Cedex - France
www.anyware-tech.com
This message and any attachments (the "Message") are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. Neither Sierra Wireless nor any of its subsidiaries shall be liable for the
Message if altered, changed, falsified or edited, diffused without authorization.
________________________________________
De : cf-dev-bounces@xxxxxxxxxxx [cf-dev-bounces@xxxxxxxxxxx] de la part de Julien Vermillard [jvermillard@xxxxxxxxx]
Date d'envoi : jeudi 17 décembre 2015 10:44
À : Californium (Cf) developer discussions
Objet : Re: [cf-dev] Clean-up mechanism for blockwise transfer is removing observe state
Hi,
Do you use different message Ids for the different notification messages?
--
Julien Vermillard
On Wed, Dec 16, 2015 at 6:11 PM, Gilles Cannenterre <gcannenterre@xxxxxxxxxxxxxxxxxx<mailto:gcannenterre@xxxxxxxxxxxxxxxxxx>> wrote:
Hi all,
I have been using observe on a big object requiring Block2 option on the initial observe request.
This is handled nicely on leshan sandbox server but after sometimes (a few minutes) the notification associated to the said object are rejected with CoAP reset messages.
I have switched back to a local leshan instance and noted that prior to the notification being rejected I have this message in the server console:
Dec 16, 2015 5:13:01 PM org.eclipse.californium.core.network.stack.BlockwiseLayer$BlockCleanupTask run
INFO: Block2 transfer timed out: CON-GET MID= 2565, Token=e0d964cec5, OptionSet={"Observe":0, "Uri-Path":["<my object id here>","0"]}, no payload
It seems like the blockwise transfer cleaning task is cleaning to much...
Gilles
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx<mailto:cf-dev@xxxxxxxxxxx>
|
