Re: [hono-dev] CoAP protocol adapter for Hono

["Hudalla Kai (INST/ECS4)" <kai.hudalla@xxxxxxxxxxxx>]

In CoAP, both parties usually act as both, client and server.

If the protocol adapter wants to e.g. POST something to a resource on the device,
then the adapter is the client and the device is the server.

If the device then wants to publish e.g. its current sensor reading to the
adapter using a CoAP POST, the device acts as the client and the adapter as the
server. Does this help?

BTW I haven't seen a proposal from you on the GSoC proposals page (yet). Are you
aware of the March 27th deadline for proposals [1]?

https://summerofcode.withgoogle.com/how-it-works/

-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
Dr. Stefan Ferber, Michael Hahn


On Sat, 2018-03-24 at 02:42 +0100, Alfusainey Jallow wrote:
> Hi Kai,
> 
> > In our case the device would then e.g. POST to the /telemetry resource on the
> > CoAP protocol adapter
> 
> Thank you. but then does the device not act as a client if it should send a
> post request to a resource on the adapter? i am confuse when you refer to the
> device as the server and the protocol adapter as a client. shouldn't it be the
> other way round?
> 
> kind regards
> 
>  
> 
> 2018-03-23 17:16 GMT+01:00 Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx>:
> > On Thu, 2018-03-22 at 13:36 +0100, Alfusainey Jallow wrote:
> > > Hi Kai,
> > >
> > > Am trying to think about the CoAP observe option and how that is suppose to
> > > work with a protocol adapter. my understanding is that devices only publish
> > > data (telemetry and events) to be consumed on the other side, right? Its
> > more
> > > like a one-way traffic (from devices to hono then downstream).
> > >
> > > if that is the case, then IMHO, devices should not register an interest to
> > > observe state-changes for specific resources. the reason is that even if
> > the
> > > state of a resource should  change, its not the devices that should be
> > notified
> > > about the changes but rather the consumer applications. is that correct?
> > >
> > The devices will _never_ observe resources on the cloud (Hono) side. If at
> > all,
> > the protocol adapter will observe resources on the devices. However, it is
> > questionable if the whole Observe mechanism is actually suitable for long
> > term
> > observations of resources because of its problems with NAT traversal.
> > 
> > The Californium folks instead propose to have the CoAP client (the protocol
> > adapter in this case) executing a resource on the CoAP server (the device) in
> > order to instruct it to start reporting the value of the resource of interest
> > by
> > means of a CoAP POST or PUT. In our case the device would then e.g. POST to
> > the
> > /telemetry resource on the CoAP protocol adapter.
> > 
> > > kind regards
> > >
> > > _______________________________________________
> > > hono-dev mailing list
> > > hono-dev@xxxxxxxxxxx
> > > To change your delivery options, retrieve your password, or unsubscribe
> > from
> > > this list, visit
> > > https://dev.eclipse.org/mailman/listinfo/hono-dev
> > _______________________________________________
> > hono-dev mailing list
> > hono-dev@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or unsubscribe from
> > this list, visit
> > https://dev.eclipse.org/mailman/listinfo/hono-dev
> 
> 
> 
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev