Re: [hono-dev] Commands using the HTTP adapter

[Sandy Meier <sandy.meier@xxxxxxxxxxxx>]

Hallo,

I find Karsten's Idea good, as if there is no command to be send to a
device, there should be no wait time.

Regards,

Sandy


On 09.05.2018 11:42, Frank Karsten (INST/ECS4) wrote:
>> -----Original Message-----
>> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On
>> Behalf Of Hudalla Kai (INST/ECS4)
>> Sent: Montag, 7. Mai 2018 11:09
>> To: hono-dev@xxxxxxxxxxx
>> Subject: Re: [hono-dev] Commands using the HTTP adapter
>>
>> On Mon, 2018-05-07 at 08:37 +0000, Frank Karsten (INST/ECS4) wrote:
>>> Thanks for the response, Kai - see my answers inline below...
>>>
>>>>>
>>>>> The "problem" I like to discuss is that I have some concerns about
>>>>> the HTTP response delay:
>>>>>
>>>>> Looking at step 3.) and 4.) and the expectation that commands are
>>>>> much less frequent than downstream messages, it would result in
>>>>>
>>>>> 3.) results in a quick answer
>>>>>
>>>>> 4.) results in a long delayed answer (will take the whole number
>>>>> of seconds that were specified by "ttd")
>>>>>
>>>>>
>>>>> My feeling is we should have some information from the receiving
>>>>> application if there is NO command as well, not only if there IS a command.
>>>>>
>>>> I do not see how we could accomplish this, given that Hono cannot
>>>> know which applications would potentially send a command.
>>> We could offer the application a way to inform the adapter that there
>>> is no command, so the Adapter can answer the device request quickly
>>> without having to wait for the timeout.
>>>
>>> Would consider this:
>>> - future extension (not for M6)
>>> - being optional to use it from the application
>>>
>> My point is: how does the protocol adapter know, which applications it should wait
>> for? Getting a NACK from one application does not necessarily mean that no other
>> application wants to send a command does it? In the end you will (again) need to
>> define an arbitrary timeout at the protocol adapter after which it stops waiting for
>> NACKs from other applications. So, we end up where we started, right?
> FMPOV the protocol adapter never knows which application to wait for - it just delays the response by the timeToDeliver
> parameter and then finally answers it. 
> Or answers it much quicker if it received a message via the AMQP 1.0 command link that was opened for the device.
>
> And if there is a possibility to not only send a command via this link, but also that there is "no command waiting", the adapter can answer the request directly 
> after it received this.
>
> How this would be used by applications is transparent for us, we would only offer a message format for signaling "there is no command now" (specific content-type for
> commands e.g.).
>
> If a command was provided, it will close the request also - without considering if there were "more" applications that would also like to send a command.
> That was the idea (as future extension).
>
>

-- 
{
 "name": "Sandy Meier",
 "job": "Software Developer",
 "phone": "+49.30. 72 61 12-134",
 "social": "google.com/+SandyMeier",
 "company": {
  "name": "Bosch Software Innovations - Bosch Group",
  "web": "http://www.bosch-si.com";
 }
}