By definition, every TCP/IP application is a client/server application. In this scenario the client makes requests of a server. That request flows down the TCP/IP protocol stack, across the network, and up the stack on the destination host. Whether the server exists on the same host, another host of the same LAN, or on a host located on another network, the information always flows through the protocol stack.
From the information presented to this point, the client/server model has some general characteristics:
- The server provides services and the client consumes services.
- The relationship between the client and the server is machine-independent.
- A server services many clients and regulates their access to resources.
- The client and server can exist on different hardware platforms.
- The exchange between client and server is a message-based interaction.
- The server’s methodology is not important to the client.
- The client carries the bulk of the processing workload so that the server is free to serve a large number of clients.
- The server becomes a client to another server when it needs information beyond that which it manages.
By specifying only the interface between the Application layer and the Transport layer, the TCP/IP Application layer permits various Application layer models. This open-ended approach to the Application layer makes it difficult to draw a single model that illustrates all TCP/IP applications. On one end of the scale, applications run as shell-level commands; on the other, applications run in various window environments. For example, the traditional telnet is run from the shell. Yet, some implementations of the telnet client take advantage of windows technology. To make life more complicated, telnet implementations are also available for the distributed computing environment (DCE). C++ client/server applications use the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) model. Consequently, trying to define a universal Application layer model is an exercise in futility.
However, even with all the variations, the Web browser continues to grow as a popular Windows environment for the implementation of the client side of the equation.
Not too long ago, programmers developed applications; now they develop applications, plug-ins, and applets. Although a program is a program, the name attached to it tells us something about the nature of the program. Alas, there are more gray zones than black and white ones. In spite of this overlap, some well-defined characteristics separate applications, plug-ins, and applets.
Starting with an application, the common characteristics are that:
- It is a standalone program.
- A desktop program, including Web browsers, invokes an application in a separate window.
- An application normally implements a specific application protocol such as FTP, telnet, or SMTP.
On the other hand, a plug-in’s characteristics are that:
- It represents an extension to a Web browser.
- It implements a specific MIME type in an HTML document.
- It normally operates within the browser window.
And then we have the Java applet. Is it a “small application,” or is it something else? A Java applet
- Is written in the Java language and compiled by a Java compiler
- Can be included in an HTML document
- Is downloaded and executed when the HTML document is viewed
- Requires the Java runtime to execute
Whereas applications and plug-ins must be ported to each hardware platform, applets run on any platform that has a Java runtime. Thus, applets provide an object-oriented, multiplatform environment for the development of applications.