Search390.com Web Enabling Tip August 29, 2001 ======================================================== SPONSORED BY: Storage Decisions 2001 ======================================================== If you're going to spend $5 million+ on storage hardware and software next year, don't miss a must-attend FREE conference developed just for you. Attend Storage Decisions 2001 in Chicago September 26-28. Learn to set strategy/make the smartest decisions to most effectively manage your storage initiatives for 2002. Pre-qualified audience of your peers and NO vendor sales pitches. Visit: http://ad.doubleclick.net/clk;3230190;5058249;c?http://www.StorageDecisions2001.com ======================================================== TODAY'S WEB ENABLING TIP: For Some Web Needs: "UDP - You da Man!" Jim Keohane Years ago I recall telling some of the developers under me to stop looking at source code and instead play some computer games. State of the art back then was Space Invaders or Wizardry, one of the original RPG's*. The reason I did so was the strong belief that everyone, especially Ian K, should come up for air once and a while. All work and no play ... Today, I can make almost the same recommendation to Internet developers but for an even better reason. If a mainframe developer can follow and appreciate the discussions of serious network game developers, they'll see how it brings a needed perspective. Which brings us to UDP (User Datagram Protocol), the underappreciated sibling of TCP (Transmission Control Program). UDP is termed unreliable and connectionless when contrasted with TCP. Both sit on top of IP (Internet Protocol) but UDP does not keep track of the order of data nor does it "automagically" attempt to ensure delivery of every packet. TCP is termed reliable but the definition is not what you might expect. It does not mean guaranteed delivery of every packet but only a sophisticated approach to do so with failure notification attempted. Even this is hardly reliable in that a truly broken connection, with no alternate route, can mean no delivery and no failure notification. TCP attempts automatic retry. Nice. But TCP is also concerned with congestion. At some point TCP will stop retries under the assumption it may be worsening a congestion problem (bandwidth capacity overrun). With today's Internet you'll find bandwidth is less and less the problem leaving latency (response time) as the major concern. The TCP timeout after a number of retries can prove intolerable for some applications. The advantages UDP, a so-called lightweight protocol, has are greatly reduced processing overhead, lessened bandwidth needs and, most importantly, much better lag or latency (round trip times). It is quite likely a UDP message is delivered and a response received before a TCP connection is even established. Even small datagrams over an established TCP connection will likely take longer than UDP since UDP's datagram service is at the lower transport level. TCP's sophisticated retry mechanism can greatly improve the likelihood of delivery. However a simple retry mechanism by UDP sender can have near equivalent results with much improved response time in many cases. One ideal case is a simple query function involving a small amount of data sent and received. Let's say an ATM machine sends a UDP packet containing account and withdrawal amount and the responder answers back with yes or no if funds are sufficient or not. No actual funds are transferred. This is query only. The ATM machine could resend if an answer is not received in a certain period. After a number of unanswered sends a message could flash "Sorry, unable to verify sufficient funds at this moment, try later." What if you actually want to withdraw funds? You can still use UDP but you probably will communicate back to central via a TCP connection. This is one of the tricks used by developers of multi-user network games. Critical data, like onscreen character movement or weapon fired, is sent over a TCP connection but data of lesser import like off-screen position or body/eye movement or sound effects are sent via UDP. Off-screen vs. onscreen position can be reasonably determined since you have current position info on other characters from their UDP and TCP messages. Game developers shoot for fastest delivery of current data. TCP may improve chances of data getting through but at the cost of response time. Game developers often prefer to discard old data. They follow the motto "Better Never Than Late!" A mainframe server can listen for UDP and TCP over the same socket number. That mechanism provides the prioritization needed for many applications. Federal Express may use UDP for truck location and TCP for actual delivery or dropoff. If they lost the occasional truck location update, no sweat. It can easily be projected. The truck could also send one location update via TCP periodically as a fallback. UDP doesn't guarantee the delivery order of packets. There are also complicated issues if the size of UDP datagrams causes fragmentation when encountering a narrow-mouth network (X.25 limit is about 125 bytes). That's no problem for most network game developers. It's also no problem for many mainframe purposes. You could even elect to send big packets over TCP and small datagrams over UDP. If you are concerned with order of delivery for some packets use TCP. The sending side, mainframe or workstation, can approach the efficiency of delivery over UDP while also keeping delivery rates high. If UDP is dropping a high percentage of datagrams then the sender could take a few countermeasures. One is to use TCP more. Another is to tweak retry parameters to retry more quickly. Just make sure the other end has no problem with duplicate deliveries. One game developer had a unique solution. If he detected a high rate of loss with UDP to one of the many characters in his network game he start to piggyback the waiting but unacknowledged datagrams on the back of new datagrams being sent. In other words, he would do pretries! Dupes were discarded at other end. No additional packets need be sent. The data for 2 (or more?) messages could still fit within a small packet. There are some caveats. Firewalls are often less UDP-friendly than TCP-friendly. Routers are more likely to drop UDP packets than TCP packets if there is a bottleneck. Even some TCP/IP stacks along the route have an understandable preference to dropping UDP rather than TCP packets. Now before you too quickly dismiss UDP be advised that SNA-over-IP approaches very frequently use UDP as the mechanism since SNA error checking is quite robust and latency is a top concern. OK, now you and some friends over the Internet bring up Multi-Player Quake and start your UDP analysis. If the boss catches you tell her I told you to do so. {smile} For extra credit: Visit http://www.cs.cornell.edu/vogels/Galaxy/ftquake.htm.http://www.flipcode.com/network/. Visit http://www.gamers.org/dEngine/quake/QDP/qnp.html. Visit http://www.jfind.com/articles/glass033100.shtml. *RPG means role playing game and not the world's first 4GL still beloved in AS/400 circles. -------------------------------------------------------------------------------- Jim Keohane ([EMAIL PROTECTED]) is president of New York consulting company Multi-Platforms, Inc. His company specializes in commercial software development/consulting with emphasis on cross-platform and performance issues. -------------------------------------------------------------------------------- What did you think about this tip? Let us know by sending an e-mail to [EMAIL PROTECTED] Have questions concerning e-business and Web Integration? Want free advice from industry experts as well as your peers? Well then, visit our new discussion forum "Executing E-Business." The name may have changed, but the great advice hasn't. In the Executing E-Business forum you'll find everything from tips on how to get your business to the Web (we hope painlessly), to software implementation tips and tricks, to problem solving, etc. To take advantage of the forum immediately, go to http://search390.discussions.techtarget.com/WebX?50@@.ee83ff8 ================================================= TIPS CONTEST ================================================= Think you can do a better job writing tips than Jim Keohane? Well, show us what you've got. Send us a Developer, Web-Enabling or Systems Management tip and let us be the judge. If your tip is chosen the winner, you'll take home a really cool prize--a fun, radio control King T-Rex dinosaur. So, send us your tip today! For more information, or to submit a tip, go to: http://search390.techtarget.com/tipsPrize/0,289492,sid10_prz750651_cts750650,00.html ======================================================== The Learning Zone Related Book ======================================================== The Eternal E-Customer Author: Bryan Bergeron Summary: The Eternal E-Customer focuses on getting e-businesses to the next level of customer loyalty. In the competitive world of e-commerce, the winners know that the key to success is customer appreciation and retention. Emotionally intelligent interfaces (EII) are driven by data from previous customer interactions, explicit customer preferences, and based on customer profiles. EIIs build trust and customer loyalty by offering shoppers the intimacy and individual attention they expect from the corner store. In this groundbreaking book, Harvard professor Bryan Bergeron provides a roadmap to get readers up to speed on all crucial business and technology aspects of EIIs, and explains how to create the information infrastructure needed to support EIIs tailored to their businesses. http://www.digitalguru.com/DigitalGuru/product_detail.asp?catalog_name=Books&category_name=&product_id=007136479X&partner_id=54 ========================================================= ========================================================= Don't Miss the Latest Industry News ========================================================= Whether you're a Developer, Systems Manager, or busy Web Enabling the mainframe, you need to stay abreast of the latest S/390 news and technologies. As a member of search390, you can get the News delivered right to your inbox. To try out this free e-mail service for yourself, just update your user profile at http://search390.techtarget.com/register/1,,sid10,00.html, and be sure you select the "News" checkbox. ======================================================== If you would like to sponsor this or any TechTarget newsletter, please contact Tim Keough at [EMAIL PROTECTED] ======================================================== If you no longer wish to receive this newsletter simply reply to this message with "REMOVE" in the subject line. Or, visit http://search390.techtarget.com/register and adjust your subscriptions accordingly. If you choose to unsubscribe using our automated processing, you must send the "REMOVE" request from the email account to which this newsletter was delivered. Please allow 24 hours for your "REMOVE" request to be processed.
