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 
On Wed, 2018-06-13 at 13:23 +0000, Frank Karsten (INST/ECS4) wrote:
> > > 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
> > > 
> > 
> > In cases where this behavior makes sense, i.e. there only exists one
> > consuming
> > application for the devices of the tenant, the organization's "tenant
> > manager"
> > will know about this fact and can set the option. Otherwise, default behavior
> > is
> > applied ...
> 
> IMHO why not just always support the "no command-message"?
> 
> If a "tenant manager" knows that it does not want the immediate response to a
> request, the applications (that belong to himself)
> would just not send the "no command-message". And then the PA will wait until
> ttd expired, giving the chance to other application instances
> to send a command during this time frame.
> 
> So, no extra tenant-parameter - just use the "no command-message" inside the
> applications belonging to the tenant,
> or _not_ use it.
> 
> Would you agree to this?
> 

My concern would be that while an organization might find it easy to control that
only a single application is allowed to use the tenant, it might be more
difficult to prevent the addition of a malevolent application if there are
already many applications being allowed to connect.

In addition to that, FMPOV the default behavior should be the safe variant which
will always work and only allow explicit optimization in cases where the
administrator knows exactly what he is doing.

> Otherwise I can live well with the tenant configuration, too - to me it just
> seems to introduce a config parameter that is for now not really enabling (or
> preventing) new patterns.
> 
> > 
> > > 
> > > > -----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
> > > 
> > > _______________________________________________
> > > 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