[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Do you use CoapClient API?
|
Hi Achim,
>
> I think, in draft-ietf-core-block-19, 3.4 Combining Observe and Block2, the GET
> following the notify doesn't use option observe. So
> | ------- CON [MID=4712, T=0xDEAD], GET, /obs, 2:1/0/64 -> |
> | <------ ACK [MID=4712, T=0xDEAD], 2.05, 2:1/1/64 ------- |
> should be
> | ------- CON [MID=4712, T=0xDEAD], GET, 2:1/0/64 -------> |
> | <------ ACK [MID=4712, T=0xDEAD], 2.05, 2:1/1/64 ------- |
> (and so on).
>
[KH] I think the "/obs" was not meant to indicate the observe option being set but is supposed to represent the observed resource's path.
> The principle idea, as I understand it, is that, notify for blockwise resource
> indicates, that the resource has change, but leaf the completion of the GET-
> transfer to the client.
> And the client uses the same function for reading the left stuff as for any other
> GET.
>
> | ------- CON [MID=4712, T=0xDEAD], GET, /obs, 2:1/0/64 -> |
> | <------ ACK [MID=4712, T=0xDEAD], 2.05, 2:1/1/64 ------- |
> | |
> | ------- CON [MID=4713, T=0xDEAD], GET, /obs, 2:2/0/64 -> |
> | <------ ACK [MID=4713, T=0xDEAD], 2.05, 2:2/1/64 ------- |
>
> Though the client is free to chose the token, it's valid to use The same "0xDEAD".
> But as example, it's bad, because in the past, people thought, that they MUST use
> the SAME token and so they put a wrong "semantic" on the token.
>
[KH] That's a good point and in fact, IIRC Californium indeed uses fresh tokens for doing the subsequent blockwise GETs ...
> | ------- CON [MID=4714, T=0xFEFE], GET, /obs, 2:1/0/64 -> | Start new
> | blockwise transfer
> | <------ ACK [MID=4714, T=0xFEFE], 2.05, 2:1/1/64 ------- |
> | |
> | <-- CON [MID=1233, T=0xBEEF], 2.05, Obs:664, 2:0/1/64 -- | New notification,
> lower Obs number:
> | ------- ACK [MID=1235], 0.00 --------------------------> | Ignore
> | |
> | ------- CON [MID=4715, T=0xFEFE], GET, /obs, 2:2/0/64 -> |
> | <------ ACK [MID=4715, T=0xFEFE], 2.05, 2:2/1/64 ------- | ETag: 0xB0B0
> | |
> | ------- CON [MID=4714, T=0xFEFE], GET, /obs, 2:3/0/64 -> |
> | <------ ACK [MID=4714, T=0xFEFE], 2.05, 2:3/1/64 ------- | ETag: 0xB1B1 -> wrong
> representation
> | | Cancel
> | blockwise transfer
>
> Depending on the timing, the last ACK may be the same as the first :-) (I think the
> reuse of the MID was not intended.)
>
> So on my view, your example should be:
> CLIENT SERVER
> | |
> | ------- CON [MID=4711, T=0xBEEF], GET, /obs:0 ---------> |
> | |
> ... ...
> | |
> | <-- CON [MID=1234, T=0xBEEF], 2.05, Obs:665, 2:0/1/64 -- | | ------- ACK
> [MID=1234], 0.00 --------------------------> |
> | |
> | ------- CON [MID=4712, T=0xDEAD01], GET, 2:1/0/64 -----> | | <------ ACK
> [MID=4712, T=0xDEAD01], 2.05, 2:1/1/64 ----- |
> | |
> | ------- CON [MID=4713, T=0x02DEAD], GET, 2:2/0/64 -----> |
> | <------ ACK [MID=4713, T=0x02DEAD], 2.05, 2:2/1/64 ----- | not finished !
> | |
> | <-- CON [MID=1235, T=0xBEEF], 2.05, Obs:666, 2:0/1/64 -- | New notification,
> higher Obs number:
> | ------- ACK [MID=1235], 0.00 --------------------------> | Cancel old blockwise transfer
> | |
> | ------- CON [MID=4714, T=0xFEFE05], GET, 2:1/0/64 -----> | Continue only the new
> blockwise transfer | <------ ACK [MID=4714, T=0xFEFE05], 2.05, 2:1/1/64 ----- |
> | |
> | <-- CON [MID=1233, T=0xBEEF], 2.05, Obs:664, 2:0/1/64 -- | New notification,
> lower Obs number:
> | ------- ACK [MID=1235], 0.00 --------------------------> | Ignore
> | |
> | ------- CON [MID=4715, T=0x0AFEFE], GET, 2:2/0/64 -----> | | <------ ACK
> [MID=4715, T=0x0AFEFE], 2.05, 2:2/1/64 ----- | ETag: 0xB0B0
> | |
> | ------- CON [MID=4716, T=0xFEFE], GET, 2:3/0/64 -------> | | <------ ACK
> [MID=4716, T=0xFEFE], 2.05, 2:3/1/64 ------- | ETag: 0xB1B1 -> wrong
> representation
> | | Cancel blockwise transfer
> ... ...
>
[KH] Makes sense to me :-)
Regards,
Kai
