begin quoting Andrew Lentvorski as of Thu, Mar 15, 2007 at 09:56:55PM -0700: > Bob La Quey wrote: > > >We are planning to use it to toss data back and forth between > >web services. It looks promising but I will hold off making strong > >comments until we get further into the project. > > Word of caution: make them put in a debugging time delay before every > transaction. The delay should be turned off in production code, but > should *always* be on in development code.
I know of a project that setup a bunch of soekris boxes running monowall (IIRC) to induce the appropriate delays and dropped-packet rates... > If you really want to get fancy, make that delay 25 milliseconds + .1 > milliseconds per byte. Surely 'fancy' would be 25ms + .1ms * rand(1,10) :) > Without this delay, people will bloat the XML transactions until you are > transmitting megabytes of information per transaction. Everything will > work fine until you deploy. Suddenly, when deployed, the network goes > from being Gigabit Ethernet with a single switch to a piece of damp > string with cascaded routers dropping packets. This of course exposes > the fact that everybody is transmitting far too much crap and then the > political maneuvering begins as to who gets cut. We had something similiar with SOAP -- we *wanted* oodles of data, but it turns out that SOAP has (or had) a timeout. If SOAP is being used, make sure to have a test case that puts in long delays. We were sucking back meterological data, and ran into a 2-minute timeout; the "recommended" solution was to register a callback and stand up a SOAP service of our own, but that was killed dead by the network security folks, who were not interested in poking holes in the firewall for our experiment. > Putting a time delay into the transactions *at the start* short circuits > this process and results in a product which actually works around the > problem at the architectural level rather than slapping on duct tape at > the end. I like that idea. Running through a throttled network connection works well too, I'd think. Restricting the size of the network pipe down to what you might expect from a 56k modem (just for that traffic) and flush some interesting behavior as well. I like to print out "The Fallacies of Networked Computing" and post it on the wall... Hm....there's a wikipedia page now: http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing -- POLICY should trump technological shinyness. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
