On Tue, Feb 28, 2017 at 7:41 AM, Charitha Goonetilleke <charit...@wso2.com> wrote:
> Hi All, > > I think it is better to have a solution which could be implemented in > server side to distribute operations among devices. Because as we know > device agents in IoTS devices are different to each other. In according to > our architecture, we are letting anyone to write their own device types as > well as the agents. Also we don't have our own agent for windows devices > but using default windows workspace configurations to provide MDM. So > implementing agent side solution would be more complex for some device > types and will not move forward with all device types. > > Anyway as according what to suggested by Geeth & Menaka, we could use > batch processing in server side to deliver operation to device batches > rather than sending it to all devices. So we can use operation queue to > deliver operations periodically to device batches. However we need to > figure out few more things in there. > > > 1. How we figure out optimum number of devices we should call in a > batch? > 2. What is the time span of delivering operation to all target devices? > 3. What we do if someone want to send operation immediately? > 4. Can we assure guaranteed delivery and can avoid repeated operations? > > For 1 & 2, we could use configuration to provide capability to set size of > a batch and time span. However for 3, we need to have additional option to > send operations immediately, probably using a priority queue. Also when it > comes to 4, we need to keep records about the operations we have delivered > and would be enough to add one additional operation status like "Queued". > So we can change operation status to pending, when operation is delivered. > > WDYT? > > Thanks & Regards, > /charithag > > On Tue, Feb 28, 2017 at 12:39 AM, Menaka Jayawardena <men...@wso2.com> > wrote: > >> Hi, >> >> IMO we can send a timeout with the operation which, once the operation/ >> notification is received by the device, it waits for the given timeout and >> respond back to the server to perform the operation. All operations are >> sent to devices at ones and the timeout should be different to each device. >> So that each device gets its own time to contact the server and complete >> the operation. >> >> Also, this can be used for batch processing as well. >> As an example, if there are 1000 devices, for first 100 devices, the >> timeout will be 0s, for next 100, 10s and so on. Then the first batch will >> come to the server just after they received the operation and the next >> batch will wait for 10s(or any given time) to respond back. This will >> reduce the overhead of waiting for a set of devices to complete the >> operation. >> >> I think through this we can limit the number of devices which contact the >> server at a given time and handle a reasonable amount. >> >> Appreciate any feedback. >> >> Thanks and regards, >> Menaka >> >> >> 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. >>> >>> How about adding another way 4. Device initiated calls to server > 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) >>> >>> Considering above, 2, 5 and 4 are not so frequent. 1 and 3 may change frequently, but we can send it only when a change is happened by using device initiated call. Not sure who would this align with the MDM protocols and how difficult to implement in different environments. Another approach is to send 1,2,3 and 4 on the time of device enrollment. And then again send these when a change is present. This is also required for the advanced searching functionality. Harshan is working on this and may give some insight. > >>> 1. >>> >>> 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> >>> >> >> >> >> -- >> *Menaka Jayawardena* >> *Software Engineer - WSO2 Inc* >> *Tel : 071 350 5470* >> *LinkedIn: https://lk.linkedin.com/in/menakajayawardena >> <https://lk.linkedin.com/in/menakajayawardena>* >> *Blog: https://menakamadushanka.wordpress.com/ >> <https://menakamadushanka.wordpress.com/>* >> >> > > > -- > *Charitha Goonetilleke* > Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 77 751 3669 <%2B94777513669> > Twitter:@CharithaWs <https://twitter.com/CharithaWs>, fb: charithag > <https://www.facebook.com/charithag>, linkedin: charithag > <http://www.linkedin.com/in/charithag> > > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Susinda Perera* Software Engineer B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) Mobile:(+94)716049075 Blog: susinda.blogspot.com WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
