| Re: [cf-dev] Don't send Ack if MessageObserver throws |
On Mon, 2017-03-27 at 14:20 +0200, Martin Scheffler wrote:
> Hi Kai,
> thanks for your detailed response!
>
> You are probably right that I am not using the protocol as intended in some
> way.
> What I actually want to do is use the observation mechanism to reliably
> transfer data, which it was probably not designed for.
>
> my idea was to make my device send data as CON observation replies. The device
> would wait for the last sent data to be ACKed before sending the next one.
> This way low frequency stuff like button pushes could be reliably transmitted.
>
> I managed to get this working OK, but internal network troubles or randomly
> crashing hardware could result in
> lost data when ACKs are sent by the server before the data was actually
> processed.
>
You could always do an explicit GET on the observed resource if you e.g. cannot
access the database when receiving the notification. This way you would use the
notification more like a trigger for retrieving the value. A pattern which is
required for large resource bodies as well because they need to be retrieved
using a block2 transfer from the client side anyway.
> It would be a really nice thing if somehow reliable transmission was possible
> via observation, especially as LwM2m is based on it.
> Maybe a better way would be to not use observation and instead bypass LwM2M?
>
> Cheers,
> Martin
>
>
> 2017-03-27 9:42 GMT+02:00 Hudalla Kai (INST/ECS4) <kai.hudalla@xxxxxxxxxxxx>:
> > On Mon, 2017-03-27 at 08:35 +0200, Martin Scheffler wrote:
> > > Hi all,
> > >
> > > I took a look at ReliabilityLayer::receiveResponse and it seems that the
> > ack is
> > > sent to the sender before the MessageObservers are called with the
> > response.
> > > Wouldn't it make sense to allow the MessageObservers to throw an exception
> > if
> > > they can't handle a response, so that the Ack is not sent?
> > >
> > > This would make sense if for example the response should be stored to a
> > > database. If the MessageObserver cannot reach the database then it can't
> > store
> > > the request, and it will potentially be lost. Now if the message was not
> > acked,
> > > the device could resend it, and maybe another service instance could pick
> > up
> > > the next response, successfully storing it.
> > >
> > > Do you think that makes sense?
> > >
> > The MessageObservers can throw an exception but these exceptions do not have
> > an
> > impact on the fact that the message has been received properly by the
> > protocol
> > stack. My assumption is that you want to "abuse" the protocol layer means to
> > implement application layer acknowledgement. While I understand the
> > intention, I
> > do not think that it would be wise to allow for this in Cf.
> >
> > The ACK sent by the CoAP stack merely indicates to the peer that the CON has
> > been
> > received. Its semantics is not that the payload has been processed properly
> > by
> > any kind of application.
> >
> > Transposed to TCP this would mean that the application layer would have a
> > word in
> > the acknowledgement of the TCP packets, which doesn't make much sense since
> > reliable delivery of packets is a property of TCP and should not be
> > controlled by
> > the application layer. FMPOV we have a similar situation here as well. The
> > CoAP
> > protocol provides means for "kind of reliably" transmitting a message (using
> > CON)
> > and this should not be interfered with from the application layer.
> >
> > IMHO the problem in your example is the fact that the database cannot be
> > accessed. I do not see how this problem could be solved by retrying the
> > request
> > to the CoAP server. Wouldn't you face the same problem if you would use an
> > HTTP
> > GET request instead of a CoAP GET request? However, using HTTP GET you
> > probably
> > wouldn't think about fixing the problem by means of adding a hook to the TCP
> > stack allowing you to "reject" the response received from the HTTP server,
> > would
> > you?
> >
> > >
> > > Just put upper().receiveResponse() in a try block, then send the ack after
> > that
> > > command has successfully completed
> > >
> > > Cheers,
> > > Martin
> > > _______________________________________________
> > > 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