Sep 13 2010
The Client-Server Model
0 commentsAs I mentioned in the last PHP article, one of the requirements of using PHP on a page is that it must be on a server in order to work. This fact often confuses web developers who are familiar with XHTML and CSS: until this point, they have been able to store and view their web pages on almost any digital device. That is not true of pages that feature PHP.
In order to understand why, we need to look at the very basics of the internet. In particular, we must define two terms:
A client is, for our purposes, a device, or some software, that requests a resource on the internet. The client is often, but not exclusively, a web browser running on a computer. Other possible clients include internet-accessing software running on other devices such as smartphones, eMail programs, games, etc.
A server is software or a device that provides services in response to requests from clients. The possible services are many and varied:
Print servers forward documents from clients on a network to appropriate printers, controlling printer queues and priorities.
Game servers provide a single location for game clients to form teams, and communicate the moves, current positions, actions, and scores of players.
File servers store files in a centralized location so that everyone in an organization has equal access to resources.
Web servers store web pages and associated files (such as images), and provide those resources in response to client requests.
Servers are often specialized machines. If they consider them at all, most people probably think of servers as giant humming computers with blinking lights in a vast, cavern-like room, like something out of a movie in the 60s. The reality is that almost any device with a computer processor in it can be turned into a server: what makes a computer a server is the software, not the nature of the physical hardware that it runs on. Obviously, computers with more memory, hard drive space, and processors tend to make better servers, as most are expected to respond to simultaneous requests from dozens to thousands of clients.
So in the traditional client-server model, a request for a web page could be shown as something like this:
Note that the only role for the server during this simple request is to provide the requested files: the HTML page, CSS, JavaScript code, and images. It does not process any of this material: it just finds it and hands it over. All the processing, or interpretation, is done by the client. That is, the web server does not “understand” HTML, CSS, or JavaScript: to the server, they are all just text files. It is your client that interprets the code in these files and displays the result.
The analogy I use for the client-server relationship is that of a well-to-do Victorian household in the late 19th century. You, a London gentleman (or woman), reside in the upper story of your home. The “help” – the servants and cooks – live downstairs. Being a very proper and somewhat class-conscious Victorian, you don’t ever wish to be seen by the staff. Instead, all interaction with the help downstairs is made via a dumbwaiter: a small goods elevator in the wall that travels up and down between the floors. When you are hungry, you write requests for food on little slips of paper, sending them down in the dumbwaiter. The hired help reads the note, places food in the dumbwaiter, and sends it back upstairs to fulfill your request.
At the beginning of this arrangement, you have very primitive level of communication with your staff. If you ask for potatoes, the servants will simply put potatoes in the dumbwaiter and send them up to you – it’s up to you to do the peeling, mashing, and cooking. This means that your staff can respond very quickly to requests, but it places a good portion of the work of actually making food on you.
In the same way, all HTML, CSS, JavaScript code is requested from the server but is interpreted (i.e. run or executed) by the client. This is one of the reasons that Flash (another format that is client-side) is not supported or blocked on many mobile phones: the computing power needed to run complex Flash is beyond the capacity of the processors used in current smartphones.
As a basic request-response system, this works well. If you want more work done by your help staff (you send a request down for potatoes, and your cooks prepare potatoes au gratin in just the way you like) then the server must do more work. This means you (the client) gain prepared meals, but at the expense of working your servants harder. Obviously, if you have a dinner party, during which all of your guests order special meals, then your serving staff will have to work even harder. Too many requests and deliveries flying up and down the dumbwaiter run the risk of slowing down service.
In our case, why would you want to place more work on the server? Typically, server-side languages are used to create dynamic web pages: features on the page that alter under certain conditions. HTML (and to a certain degree, CSS) are stateless: they have no comprehension of the passing of time or (broadly speaking) the actions of a user on a web page. Some scenarios for using a server-side language such as PHP might include:
You always want to place today’s date on your webpage, to make it appear current.
You want the user to select an option from a drop-down menu, and show them different pictures based on their choice.
You want to alter the appearance of the site based on seasonal changes, or the time of day.
Combing both server-side and client-side processing, our diagram becomes:
Central to this model is the issue of balancing client-side processing with server-side demands. You will never be able to fully anticipate the power or abilities of web clients (they will always have different connection speeds, different browser versions and plugins, different processor speeds, etc). But placing too much work on servers starts to bog them down. Ideally, the two are balanced: some work is done by the client (interpreting HTML, CSS, JavaScript and images), and some by the server (PHP, ASP, and other server-side technologies), to create a seamless experience.
There are some other important reasons to use server-side technologies:
- Reliability
So long as the server is running and not overloaded with requests, server-side technologies always work. You don’t have to worry about browser type, available plugins, or platform: the server always remains the same, and PHP code always works.
- Security
Server-side code is inherently more secure than client-side, as the client never sees the server code, just as our Victorian gentleman never saw his servants: the server works to fulfill a client request, and sends the completed order. The client never sees the actual process of chopping, cooking, etc.
Now that we understand why a server is required for PHP, we will turn to setting one up for testing purposes.
- Tags
You must be signed up and logged in to leave a comment. Doing so only takes a moment.
