[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Implementation of RFC 7967: Constrained Application Protocol (CoAP) Option for No Server Response
|
Hi,
this sounds like an interesting feature :-) It also doesn't sound too hard to do
so this could be a good opportunity for you to contribute to Californium. I can
provide some pointers for you regarding how to start and where you need to do the
changes.
--
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, 2017-01-12 at 17:58 +0530, Abhijan Bhattacharyya wrote:
>
> Dear List,
> On August 2016 RFC 7967 was published. It adds an option to CoAP header for No-
> Server response. It is registered in CoAP registry as option number 258.
> About this option from the abstract of the RFC:
>
> " There can be machine-to-machine (M2M) scenarios where server
> responses to client requests are redundant. This kind of open-loop
> exchange (with no response path from the server to the client) may be
> desired to minimize resource consumption in constrained systems while
> updating many resources simultaneously or performing high-frequency
> updates. CoAP already provides Non-confirmable (NON) messages that
> are not acknowledged by the recipient. However, the request/response
> semantics still require the server to respond with a status code
> indicating "the result of the attempt to understand and satisfy the
> request", per RFC 7252.
>
> This specification introduces a CoAP option called 'No-Response'.
> Using this option, the client can explicitly express to the server
> its disinterest in all responses against the particular request.
> This option also provides granular control to enable expression of
> disinterest to a particular response class or a combination of
> response classes. The server MAY decide to suppress the response by
> not transmitting it back to the client according to the value of the
> No-Response option in the request. This option may be effective for
> both unicast and multicast requests. This document also discusses a
> few examples of applications that benefit from this option."
>
> To best of my knowledge Californium does not yet incorporate this option. This
> option is actually useful for several applications as mentioned in the quoted
> text and can actually be useful in system level debugging. Could it be possible
> to have this option included into Californium (and Copper) sometimes down the
> line?
>
> Regards
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, Innovation Lab, Kolkata, India
> Tata Consultancy Services
> Mailto: abhijan.bhattacharyya@xxxxxxx
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> _______________________________________________
> 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
