| Re: [hono-dev] [Hono #927 & #929] Limit number of connections and messages based on data volume for a tenant |
Hi Jens & Karthees,
first I was a little concerned regarding the direct dependency on the metrics back end that your proposal would introduce to the protocol adapters. But in fact, we already have that anyway, so abstracting that dependency using a strategy interface seems like a good idea.
I also like the idea of using a combination of (potentially cached) information from the metrics back end and local (more recent) information. This reminds me of car that has GPS but uses local sensors when inside of a tunnel ...
I would still propose to manage the limits for a tenant in the Tenant service and transfer them as part of the get Tenant operation's response to the protocol adapters. The adapters can then make a local decision based on all of that information. If the limits are adapted for a tenant then IMHO it should not be too much of a problem for the change to take effect only after all cached values have timed out. In the end we already have that problem for the "enabled" flag as well.
Cheers,
Kai
_______________________________________________Hi all,
In my last mail, I sent a proposal regarding limiting the number of device connections [#927] and messages based on data volume [#929] per tenant. As part of that, two new methods are to be introduced to the TenantObject, which can be used by the protocol adapters before accepting any new connections or messages. And the implementation to verify those limitations was proposed be part of the TenantService implementation. Hono file system based device registry (FileBasedTenantService) will contain a reference implementation using metrics data to verify against the configured limits .
Today in the Hono community meeting, we had a chance to discuss about this topic.
@Jens Thanks for the suggestion. Which is instead of implementing this as a part of the TenantService to bring this as part of a new Service (ex. TenatLimitationService or TenatPlanService). I like this separation of concern approach.
Also Hono users would bring their own Device Registry (so the TenantService implementation). If the metrics based reference implementation is part of the new Service, then it is easy for them to reuse.
I gave a thought about this approach. Currently protocol adapters before accepting any new connections or messages, make a request to the TenantService to get the TenantObject. In addition to that, to verify the limitations, the adapters must also make a request to the new Service.
It seems to me, that it brings more amqp traffic. Considering this, IMHO it seems good to have these 2 methods (if to allow connections and messages) as part of the TenantService. WDYT?
To make the method names more intuitive, I would suggest to rename “boolean checkWithConnectionPlan()” to “boolean allowConnections()” and “boolean checkWithMessagePlan()” to “boolean allowMessages()”.
Best Regards,
Karthees
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx> On Behalf Of Kalidass Kartheeswaran (INST/ECS4)
Sent: Montag, 21. Januar 2019 18:21
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: [hono-dev] [Hono #927 & #929] Limit number of connections and messages based on data volume for a tenant
Hi all,
I would like to talk about the below two issues, share an implementation proposal and hear your views on it.
#927 - Limit the number of simultaneously connected devices. (Example: Tenant A can has a connection plan of 10000 simultaneously connected devices).
#929 - The data volume over a period should not exceed the configured value per tenant. (Example: Tenant A has a data usage plan of 2 GB per month).
In the above cases, protocol adapters must ensure that the number of simultaneously connected devices and the data volume (used over a period) for a tenant don't exceed the configured limits. In a real world scenario, apart from the number of connections and the data volume, more plans based on other factors are also possible such as limiting the number of messages per tenant for a time period. FMPOV it is basically connection and message plans for a tenant.
I can imagine very well the below two methods, which can be used by the Protocol adapters to check the plans before accepting a connection or a message. I think device registry (TenantObject) might be a suitable central place to hold these two methods.
Users with their own implementation of device registry can have their own implementation of these methods. I would like to start with #927 by providing a reference implementation with the default device registry shipped with Hono. As part of this, I would like to make the limits configurable by adding a parameter “connections-limit" to the tenant configuration. Inside method “checkWithConnectionPlan(tenanId)”, connections related metrics data from Prometheus Backend will be used to validate the connections limit and the result is returned. Followed by changes in Protocol adapters to use this method to check the connections limit before accepting a connection.
/**
* Checks with the connection plan before accepting a new connection for a given tenantId
* @param tenantId The tenant for which the object is constructed.
* @returns if a new device connection is allowed or not.
*/
public static boolean checkWithConnectionPlan(final String tenantId);
/**
* Checks with the message plan before accepting a message for a given tenantId
* @param tenantId The tenant for which the object is constructed.
* @returns if a message can be accepted or not.
*/
public static boolean checkWithMessagePlan(final String tenantId);
WDYT?
Best Regards
Karthees
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev