This is a duplicate article. It is a prior version of the Fat Client vs. Thin Client article. It was so good we had to keep it on here and just link back to it.
Here is the original article that was written by our founder, Phil Martin.
Hold on, this may get a bit technical...
Most Local Area Networks or LANs run as file servers, meaning they operate as a shared remote disk drive for client workstations. These networks are optimal for document based processing such as word-processing and spreadsheet applications because they provide a dedicated processor for working with large amounts of data in memory and share the infrequent access to disk drives. Transaction based systems, such as accounting applications, are the opposite. They process a single transaction at a time requiring little memory and processor resources and spend most of their time moving data between memory and the disk drives. For example, processing a sales order is not much more than extending the quantity by the price but the Customer Master, Sales Order, Terms Code, Salesman, and Inventory files, to name a few, must be read and written over the network. Not the same as reading a document, moving lots of data around for ten minutes, then writing it back. So, for transaction based applications, forget about performance on a File Server LAN. The dedicated processor and abundant memory are wasted and the slowest link, the remote disk access, is overworked.
And what about reliability? While the programs do reside on the File Server host, they are downloaded and actually execute on the workstation. Because moving data in memory is so much faster than accessing the disk drive, the workstation hoards as much data from the server's disk files as possible in large blocks of memory called buffers. As data is needed, the computer first reads a segment of the disk file into a buffer and then uses the memory based version for the program's subsequent access to that portion of the file. Consequently, during a program's execution, data in the buffers get "out of sync" with their disk file counterparts. If no unused buffers are available, the oldest used buffer is written back to the disk file and it becomes available for reuse. Individual buffers usually hold only a fraction of a complete file. Therefore, the disk files being updated by a program become "corrupted" with these partial write backs until the program ends and all of the remaining buffers are written back to the disk. While the program is running, the disk files are vulnerable. If the network connection is dropped or the workstation is restarted, data being held in the buffers is lost and can never be written back to "resync" the disk files. Database Server applications using products such as SQL Server overcome the "dirty buffer" problem by keeping the data file access on the server. This improves reliability but doesn't do as much for performance because the programs are still downloaded and all of the application's data records, not just the portion required for the user's screen display, are read and written over the network to be processed at the workstation.
The Application Server environment of MAS 90cs is similar to the internet. Everything is on the host except the user interface. No programs are downloaded and no application data files are opened on the user's workstation.; But unlike the internet, there is no delay for graphical images to be downloaded for display. In fact, MAS 90cs actually runs on the server in character mode. The thin-client "browser" running in Windows on the workstation receives a text command from the host with the specifications for each Windows "object" to be drawn on the workstation's display followed by the text designated for the data fields on the displayed form. Also, to minimize network traffic, static MAS 90 components such as the Help text files are kept on the workstation in a local "cache". Remote dial-up users really benefit from MAS 90cs because, like the internet, they make a serial TCP/IP connection directly to the server. It is not necessary to connect through products such as Winframe or pcANYWHERE. These methods copy the entire graphical screen image from a Windows NT task or a local workstation and download it to the remote computer. Even over high-speed lines, there is often a tedious wait for the screen to display.