| Re: [hono-dev] [Hono #927 & #929] Limit number of connections and messages based on data volume for a tenant |
|
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) 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 |