Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hono-dev] Commands using the HTTP adapter 
>> 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.).
>> 

>And this is where we seem to disagree. I do not think that we can simply "let any application send the no-command message" and then send the (empty) response to the device, because we have no control >over which and how many applications will actually be involved. This mainly depends on the implementation and capabilities of the AMQP network. However, we could add a configuration option at the tenant >level (i.e. to be configured in the Tenant service) which would allow a protocol adapter to take such a "no-command" message at face value and end the device's request. If this option is not configured for a >tenant, then the adapter would behave as usual and wait for the TTD to expire. WDYT?

This would improve the current implementation a lot IMHO (since we can configure tenants where usually downstream messages with ttd are always anwered fast), but I ask myself why this would address your concerns?

Since the applications that may send such a "no command-message" are bound to the tenant of the device that sent a downstream message with time-til-disconnect parameter,
we still have the same situation:
- one application of the tenant sends the "no command-message" (in reaction to downstream message), the PA closes the request with a quick answer then
- other applications may have some commands that they would like to send, but they cannot do this since they are not being informed

IMHO the way to support multiple applications that may want to send a command is out of our scope and should be done on the application level. E.g. by broadcasting the detection of a ttd-parameter
in a downstream message to all application instances instead of immediately send a command or a "no command-message". Then the PA would have to wait until ttd expired, or that the application instances
coordinated themselves to find out that no instance wants to send a command, and one instance could send a "no command message" in this case..
But all this is not in the responsibility of Hono, I think. We only have to offer a way for applications to signal the "no command-message", and react to it in the PAs.

Am I missing something? WDYT?


> -----Original Message-----
> From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On
> Behalf Of Hudalla Kai (INST/ECS4)
> Sent: Mittwoch, 13. Juni 2018 08:06
> To: hono-dev@xxxxxxxxxxx
> Subject: Re: [hono-dev] Commands using the HTTP adapter
> 
> On Wed, 2018-05-09 at 09:42 +0000, 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.
> >
> 
> Of course, I understand the benefit of the intention.
> 
> > 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.).
> >
> 
> And this is where we seem to disagree. I do not think that we can simply "let any
> application send the no-command message" and then send the (empty) response
> to the device, because we have no control over which and how many applications
> will actually be involved. This mainly depends on the implementation and
> capabilities of the AMQP network. However, we could add a configuration option
> at the tenant level (i.e. to be configured in the Tenant service) which would allow a
> protocol adapter to take such a "no-command" message at face value and end the
> device's request. If this option is not configured for a tenant, then the adapter
> would behave as usual and wait for the TTD to expire. WDYT?
> 
> 
> > 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).
> >
> >
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> 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

Back to the top