[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cf-dev] Don't send Ack if MessageObserver throws
|
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
