[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Release Plan for Californium ?
|
> To me this indicates that a client that claims to support blockwise transfers as defined by RFC 7959 also MUST understand and consider ETags on block2 responses.
> AFAIC this would allow us to _always_ include an ETag in a response that requires a blockwise transfer, wouldn't it?
According RFC 7252, 5.10, Table 4, ETag is not critical.
So it's safe to include it, even if the receiver isn't able to process it.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Dienstag, 6. Dezember 2016 10:22
An: cf-dev@xxxxxxxxxxx
Betreff: Re: [cf-dev] Release Plan for Californium ?
On Tue, 2016-12-06 at 08:58 +0000, Kraus Achim (INST/ESY1) wrote:
> I think, the most clients will not support "dynamic blockwise" resources.
And those, which support changing blockwise resource, either implement ETag or they have to define, how they want to handle that (best by starting a RFC core discussion :-) ).
As you already pointed out, RFC 7959, Section 2.4 states that a server SHOULD include an ETag option for dynamically changing resources. It also states that "If an ETag Option is available, the client, when reassembling the representation from the blocks being exchanged, MUST compare ETag Options."
To me this indicates that a client that claims to support blockwise transfers as defined by RFC 7959 also MUST understand and consider ETags on block2 responses.
AFAIC this would allow us to _always_ inlude an ETag in a response that requires a blockwise transfer, wouldn't it?
> Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Dienstag, 6. Dezember 2016 09:53
An: cf-dev@xxxxxxxxxxx
Betreff: Re: [cf-dev] Release Plan for Californium ?
I am currently working on a fix for #155 [1] and in that course I am thinking about implementing (transparent) support for ETags in blockwise transfers as well.
A Resource implementation may include an ETag in a response it has created and this ETag will then be used by the BlockwiseLayer for the block2 transfer to the client. If the response created by the Resource implementation does not contain an ETag, the BlockwiseLayer will create one transparently and use it for the
block2 transfer.
On the client side, the ETag from the response will be used to retrieve the remaining blocks in a block2 transfer, making sure that all response blocks actually carry the same ETag.
My only concern with this would be whether all clients supporting blockwise also support proper handling of ETags.
WDYT?
--
Mit freundlichen Grüßen / Best regards
Kai Hudalla
Chief Software Architect
Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
On Thu, 2016-11-17 at 09:54 +0000, Kraus Achim (INST/ESY1) wrote:
RFC7959 (blockwise), section 2.4, page 13,
"Block-wise transfers can be used to GET resources whose representations are entirely static (not changing over time at all, such as in a schema describing a device), or for dynamically changing resources. In the latter case, the Block2 Option SHOULD be used in conjunction with the ETag Option ([RFC7252], Section 5.10.6), to ensure that the blocks being reassembled are from the same version of the representation: The server SHOULD include an ETag Option in each response."
So the issue with dynamic content is more bound to the proper use of the ETag option.
As far as I understand californium, to provide a ETag is the responsibility of the " CoapResource" or "Resource" implementation.
And the CoAP client should check the ETag to detect a change in the payload. Currently this seems to be missing in the blockwise transfer on the client side. But I hope, this should be not a too big story.
Mit freundlichen Grüßen / Best regards
Achim Kraus
Bosch Software Innovations GmbH
Communications (INST/ESY1)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.dewww.blog.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn
-----Ursprüngliche Nachricht-----
Von: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Hudalla Kai (INST/ESY1)
Gesendet: Donnerstag, 17. November 2016 10:10
An: cf-dev@xxxxxxxxxxx
Betreff: Re: [cf-dev] Release Plan for Californium ?
On Wed, 2016-11-16 at 16:55 +0100, Simon Bernard wrote:
It sounds good to me to put coap+tcp in a more long term branch.
ok, we seem to agree on that.
About the blockwise, we currently use the 2.0.0M2 version of
californium and it seems to works :).
I wish this were true. However, the more complex cases where a client
receives another notification while a blockwise transfer (for the
previous notification) is still ongoing, do not work because we
(currently) create a new Exchange object for each notification
received and therefore the ObserveLayer cannot determine whether it is already conducting a blockwise transfer for the token.
It will therefore always start an additional series of blockwise GETs
to retrieve all blocks. The "older" blockwise transfers will therefore
end up intermixing "old"
blocks with "new" blocks and for each notification received the
application layer will receive a Response containing the (potentially
erroneously) assembled payload.
This is just a feeling but I have some doubt about the possibility
to extract the blockwise transfer from the stack without extracting
the observe layer which is upper it.
As a Leshan developper and so Californium user, I also appreciate
the transparent way blockwise is currently handled. How will this
change impact the API ?
I do understand that from a user's perspective it seems desirable to
have Californium handle the blockwise transfers automagically "under the hood".
However, the way this currently is implemented is a maintenance nightmare.
Whenever I change one line of code in the matcher, I spend days trying
to get the blockwise tests succeeding again. My hope is that we can
reduce the CoapStack to its basic functionality of simply sending a
request and receiving a response and let code outside of the CoapStack
do the interpretation of observe flags and, in particular, handle blockwise transfers.
Coming back to your question: I think that this will completely change
the API (at least when doing blockwise transfers) and that is also the
reason why we need to do it as part of a major version change (like
2.0.x ;-))
About fixing the scope or the date, I prefer to fix the scope. This
allow us to know which modification go in the 2.0 banch and which go
in the more long term branch (3.0 ?)
Fine with me. The challenge will be to agree on scope, I guess ...
Le 16/11/2016 à 16:01, Hudalla Kai (INST/ESY1) a écrit :
On Wed, 2016-11-16 at 14:52 +0100, Simon Bernard wrote:
Hi,
At Leshan, we currently think about releasing a first Leshan version.
You can see the plan on leshan-dev [1].
This version of Leshan will be based on Californium 2.0.x as
we need the persistent ObservationStore.
There is a lot of activity on this branch which is a good
point for californium project but I'm wondering if this is
compatible with the needs to get a stable version of Californium 2.0.x ?
WDYT ?
I understand your concerns regarding "convergence" of the 2.0.x branch.
However,
the 2.0.x branch provides the opportunity to make some more
radical changes that involve breaking the API. This "window of opportunity"
will be closed once we do a 2.0.0 release and we will then need to
create a 3.0.x branch in order to work on other changes that will
potentially break the API (again). IMHO we therefore need to come
to an agreement what we think should be part of 2.0.x and what
should be postponed to the next release(s).
The recent developments around the coap-over-tcp-draft have led me
to believe that we will not be able to have coap+tcp support
(based on the latest coap-
over-
tcp draft) in Californium any time soon. It also seems like we
will need to do some more (bigger) changes in Californium to
support observations and clustering over TCP correctly.
Personally, I would therefore like to postpone TCP to a later version.
The biggest problem I currently have with the 2.0.x branch is the
quality of the transparent blockwise transfer behavior. My gut
tells me that we should remove the Blockwise layer as part of
2.0.0 in order to simplify the core protocol stack and make it
easier to change things in the stack later on.
I know that I have been talking about this for quite some time now
but haven't really started to work on it. However, I really would
like to get this into 2.0.0.
Maybe we can set a dead-line for work on 2.0.x and at that point
simply release whatever we then have finished?
Simon
[1]
https://dev.eclipse.org/mhonarc/lists/leshan-dev/msg00631.html
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
