1200 baud... Whoever decided not compress the stream, over looking performance was missing insight into GZip and implementation with practically 'any' web server, that is IF you elected to use HTTP... there are options and this is a messaging format, not really designed for massive binary transfers, although I've transferred 2mb TIFF images, compressed and re-compressed in the stream for auto-motive manufacturers and seen these messages delivered with minimal delay.
Possible transports include; HTTP is a standard protocol for web services – quite verbose, with data transferred as XML and of course you can eliminate and optimize dynamically if you like. TCP is similar to HTTP but has a more compressed, binary data transfer method and of course Named Pipes, normally used for inter-process communication, is in effect very efficient. Operation selectors allow for combinations and mixtures of these, based on use case scenario. There is no hard and fast rule stating that you have to transmit XML... the specific case you pointed out, is the simple case of entities VS attributes, which is always a case of flexibility at the end of the day and I don;t see any performance increase based on shredding an empty element. My 5 cents On Tue, Nov 8, 2011 at 8:45 AM, Tim Kelly <tim.ke...@designerware.com>wrote: > ** > > 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] <http://user/SendEmail.jtp?type=node&node=4970176&i=0>> > 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 > > -- Glen Hassell Inner Technique http://innertech.com.au/ Office: 03 9687 0006 Mobile: +61 (0) 438 340 385
_______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
