Re: Is Client/Server Dead? Conference May 15th

neal@fohnix.metronet.com (Neal Howard) wrote: [...] > Would all the database I/O that my apps will be doing under maximum >full user load be happily handled if that I/O were being done on a >typical 486 PC to it's IDE hard drive? This is an interesting analysis but I'm afraid it could mislead some into viewing the data exchanges between client and server as comparable to the disk I/O done by a database engine. They aren't. A client query (for example) might involve several network exchanges totalling a few hundred bytes plus the amount of application data sent and/or retrieved. Executing the query at the server might require thousands of disk I/O requests (searching indexes, scanning, sorting, etc.) or it might require none (given a shared server with strong caching capabilities). The application designer should understand the network loading characteristics of the particular c-s protocol -- as used by the application or tool -- relative to the capacity of the network to be used. The better combinations of front end and protocol require fewer send/receive operations with economical datastreams. I suppose a thoughtless application developer could design something that required retrieving (or sending) very large sets of application data from (or to) the server and thereby saturate the network regardless of protocol efficiency, but that seems like an obvious and fundamental error to me. I'm not disputing that client-server is challenging to implement. But I think many of the challenges are related to things like network complexity and reliability, poor (suboptimal) integration between client tools/interfaces and servers, and prosaic matters such as distributed software installation and maintenance. /b -- Bill Manry - Mainframe & Integration Technologies - Oracle Corp. USA The above statements and opinions are my own and do not necessarily represent those of Oracle Corporation.