[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hono-dev] Commands using the HTTP adapter
|
I also like the idea for "no commands" message. If a solution has a single command source (e.g. command/operation manager) then this single command source would handle ALL command exactions and could (and probably would like to) send such "no commands" message.
However there are two options:
1. Hono implement "standard" no message mechanism
2. The solution could have its own (solution proprietary) command that will be interpreted just by adapter (not send to device) that will mean "no commands" - that, in fact, was my first idea how to work-around the problem with waiting unnecessarily when there are no commands.
Поздрави / Best regards,
Avgustin Marinov
Engineering Cloud Services Device Manager
(INST/ECS8)
Bosch Software Innovations EOOD | 47B Tsarigradsko Shose | Sofia 1124 | BULGARIA | www.bosch-si.com
Tel. +359 2 9055801 | Mobile +359 889 464664 | Fax +359 2 9532617 | Avgustin.Marinov@xxxxxxxxxxxx
-----Original Message-----
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Sandy Meier
Sent: 08 юни 2018 г. 17:18
To: hono-dev@xxxxxxxxxxx
Subject: Re: [hono-dev] Commands using the HTTP adapter
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";
}
}
_______________________________________________
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
