Hi All, I think going forward, we need a queue to be present, for communications going both ways. As Charitha highlighted, when multiple devices are targeted, we need to be able to define a dynamic distribution strategy that will gradually ramp up the rate of distribution, depending on success rate and system throughput. Ofcourse in order to do this, we will need to have guaranteed delivery.
I think maybe when we go forth, we may need to think about a combination of MQTT and Kafka combination to cater all our delivery + connectivity needs. Thanks and Regards, Ruwan Yatawara Associate Technical Lead, WSO2 Inc. email : ruw...@wso2.com mobile : +94 77 9110413 blog : http://ruwansrants.blogspot.com/ https://500px.com/ruwan_ace https://medium.com/@ruwanyatawara www: :http://wso2.com On Thu, Mar 2, 2017 at 10:14 AM, Chathura Ekanayake <chath...@wso2.com> wrote: > Can we get all device requests through a message broker and let the broker > handle spikes? Then the broker has to be scalable.. however, it anyway has > to be scalable as devices can publish monitoring events to the broker > (which can occur frequently by a large number of devices). > > Regards, > Chathura > > On Wed, Mar 1, 2017 at 11:01 AM, Dilan Udara Ariyaratne <dil...@wso2.com> > wrote: > >> Hi Geeth, >> >> IMO, all the current information retrieval and monitoring operations >> could run in parallel from device to device. >> In that case, cannot we maintain a task pool at server side where we >> would allocate some defined set of operations to each task and dynamically >> expand the pool based on demand. >> It's more of a divide-and-concur approach that I am suggesting here. >> >> Thanks, >> Dilan. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> On Mon, Feb 27, 2017 at 11:09 PM, Geeth Munasinghe <ge...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> We have encountered an issue with balancing load distribution of device >>> + server communication. Device and server communication happens through >>> following ways. >>> >>> 1. Polling - Device keeps polling the server >>> 2. Push notification - Server sends a notification to device to come >>> retrieve the operation. (wake up call) >>> 3. Push message - Whole message is pushed to device as notification. >>> >>> In 1 and 2 ways, device always comes to server to pick up the operation. >>> (In MDM scenarios, we use only 1 and 2) We have found few scenarios where >>> this would lead to a request overload to the server. >>> >>> 1. Device information retrieval >>> 2. Device application list retrieval >>> 3. Device location retrieval >>> 4. Policy monitoring >>> 5. Installing/Uninstalling application (Role based) >>> >>> First four scenarios are handled by background tasks. These tasks are >>> responsible for adding an operation against each of the device. This >>> process would notify the device regarding operation or device will come to >>> server at a pre-configured time to retrieve the operation. Specially with >>> the notification process, when an operation is added to all the device, >>> notification is send to all of them. In iOS, we send to the notification to >>> APNS, for android - GCM/FCM and for Windows - WNS. These notification >>> services normally deliver the messages to devices quickly. Therefore as >>> soon as device receives the notification, it starts to contact the server. >>> If this happens with a server which has 1,000s of devices enrolled, most of >>> devices start retrieving the operation from the server which leads to a >>> request a burst. 5th scenario happens when we install an application to a >>> role which has 1,000s of users. This also starts sending notifications to >>> all the devices of those users, which would result in a request burst. >>> >>> As a solution, we can limit the number of devices notified at given >>> moment. Only set of devices will receive the notification at first, then >>> after some time interval second set of devices will receive the >>> notification and continue until all the devices are notified. This way, we >>> can make sure only chunk of devices receives the notification, hence reduce >>> the server load. >>> >>> Please give your feedbacks and suggestions. >>> >>> Thanks >>> Geeth >>> >>> -- >>> >>> *G. K. S. Munasinghe* >>> *Senior Software Engineer,* >>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>> *lean.enterprise.middleware.* >>> >>> email: ge...@wso2.com >>> phone:(+94) 777911226 <+94%2077%20791%201226> >>> >>> <http://wso2.com/signature> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
