It cost me and my team weeks because we didn't notice the issues until we went live. The overhead and cost of web services is documented all over Google (no one particular place) as I recall. There seemed to be more written about it on the Java side. So, after spending some time to isolate the problem, we got our network team involved and then isolated the problem.
During the research, one of the engineer's mentioned that the phone speed was close to an old 1200 baud modem, and that's when it struck me. Why not communicate like we did during the 70's? Heck we got great speed out of even those 300 baud modems. So, basically we post/get a xmodem/ymodem package back and forth. We don't chunk it up into packets, but basically take the data and encrypt it and then add a CRC to it and post it. On the server side we uncrypt it and check the CRC, now TCP/IP keeps the data clean, so the CRC is just because the engineer's wanted to be able to post without TCP/IP. Theoretically, we could do a dialup an post to a modem without TCP/IP therefore the CRC would come into affect. The other thing was serializing objects to XML really creates a PIG XML set if you really look at it. For example, your XML has elements that are empty or set to the default and look something like this: <First Name>Billy</ First Name> <Middle Name></Middle Name> <Last Name>Bob</Last Name> Notice the overhead? also notice that middle name is empty but you're sending the overhead to tell the ever it is empty. So we wrote classes to serials objects like this: <1>Billy| <3>Bob| The second example uses only 17 characters instead of 85 which is 80% smaller. Now if you take out the SOAP, you can see the difference you can start making. Notice that 1 is used instead of the proper name, also notice that element 2 is not sent therefore the server will assign the default to it. Also, we use the pipe character to end the element (downside you cannot send a pipe). Overall do this for a large object and a few thousand phones and all these bytes add up. It does mean you have to build some custom classes on each end to handle the serializing and know that element 1 maps to the First Name we keep the mapping in the class and then just version the classes and hope like hell nobody fobar's sourcecontrol <lol>. Anyway, just my 2ยข ________________________________ From: monodroid-boun...@lists.ximian.com [mailto:monodroid-boun...@lists.ximian.com] On Behalf Of cgraus Sent: Sunday, November 06, 2011 11:28 PM To: monodroid@lists.ximian.com Subject: Re: [mono-android] Calling arbitrary web services Thank you Tim, that's super helpful info at this stage of our development cycle. On Mon, Nov 7, 2011 at 12:57 PM, Tim Kelly [via Mono for Android] <[hidden email]> wrote: > Web service is just a URL and we dynamically build them all the time. > Matter of fact we use a random number generator. For example, we have > 20 websites and we us ws_x.hostURL.com. ws_0 ws_1 ws_2 etc etc we also > dynamically build the hostURL too. > > Note however, we dropped web services in our android projects because of > the overhead. We replaced it with a simply post/get. The network > overhead of directly consuming web services caused network to memory > issues. When we added all the SOAP it was BLOATed and caused issues on > phones etc which have less bandwidth and memory. > > After messing around with web services we decided the overhead was too > much so we built a webpage that accepts Post/Gets. Now, we build a > special XML record set that only has elements that are not empty (or not > set to default - no need to pass them). We then encode it, add SOH + > BLOCK + data + CRC + ETX (yes the old xmodem data pack) and post it to > the website. The website makes sure there is a SOH and ETX, calculates > the CRC on data and compares it. Then we process the xml if it passes. > This reduced our overhead by over 80% compared to using web services. > We pass binary data the same way. Bottom-line we never noticed issues > on computers, but when we went to hand held devices (with slower > bandwidth) the web services was transmitting to much data and causing > memory issues. > > > > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf Of cgraus > Sent: Wednesday, November 02, 2011 8:01 PM > To: [hidden email] > Subject: [mono-android] Calling arbitrary web services > > We have an application which we want to write some supporting mobile > apps > for. The idea is that if you buy our app, it comes with a web service, > and > you will host that service on your server, so it has access to your data > store and can be used to provide access to your data. Therefore the > interface is strongly typed, but the location is unknown. We're > expecting > to write this with WCF. All the examples I am seeing, require me to > create > a reference to a service. I can do that, but I'll need to dynamically > change the location of the service. Are there any examples along those > lines, or any advice anyone can offer ? > > > -- > View this message in context: > http://mono-for-android.1047100.n5.nabble.com/Calling-arbitrary-web-serv > ices-tp4959774p4959774.html > Sent from the Mono for Android mailing list archive at Nabble.com. > _______________________________________________ > Monodroid mailing list > [hidden email] > > UNSUBSCRIBE INFORMATION: > http://lists.ximian.com/mailman/listinfo/monodroid > _______________________________________________ > Monodroid mailing list > [hidden email] > > UNSUBSCRIBE INFORMATION: > http://lists.ximian.com/mailman/listinfo/monodroid > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://mono-for-android.1047100.n5.nabble.com/Calling-arbitrary-web-services-tp4959774p4970013.html > To unsubscribe from Calling arbitrary web services, click here. ________________________________ View this message in context: Re: Calling arbitrary web services <http://mono-for-android.1047100.n5.nabble.com/Calling-arbitrary-web-services-tp4959774p4970176.html> Sent from the Mono for Android mailing list archive <http://mono-for-android.1047100.n5.nabble.com/> at Nabble.com.
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
