Interfacing the Network 107 The disadvantage doesn t come from the database stuffer (the process that inserts user messages) but rather from the database reader (the main process that retrieves all user messages from the database).To achieve a good chat feeling, we need as little latency as possible and thus a very good response time.The response time is crucial for Web-based chat, as this is how the user will actually feel integrated into the action.When the messages come slower and slower,users quickly become frustrated and quit.Our testing showed that a latency of more than a second is too much.To stay below this value, the poll frequency in which the main process has to read messages from the database must be very short; the default value in phpChat is 0.5 seconds (two checks within a second). Now, as soon as a lot of clients have to be handled by the chat system,the database gets quite busy and takes up more and more resources.At about 40-50 queries per second, our test server spent about one third of its processing time simply executing database queries. Even if this was a disqualifying benchmark for the database system (it should have been able to process many more queries), some optimization is obviously necessary, and this isn t the ideal setup. Creating Lockfiles Our next idea was that, if the database took up too many resources when handling interprocess communication, a file system might be more efficient. But the file system clearly lost the race.Again,the stuffer wasn t the problem creation of the lockfiles worked smoothly.To detect whether a lock was set, however, lots of calls to clearstatcache() had to be done in order to correctly determine whether a lockfile had been deleted or was still present. clearstatcache() had such a hard impact on the system performance that we didn t try to look further into this option; the chat only worked at a quarter of the performance it reached using the database-backed approach. Create your own benchmarks. Make test scripts accessing the database and the file system at high frequency.Write down your results and compare them.This is always a good idea when evaluating data-exchange methods never trust theoretical descriptions of what the systems can be capable of! In practice,most things will look different. Using Semaphores Of course, the reasons for the poor performance of the former approaches are easily recognized.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Interfacing the Network 105 Here s the hard part:We can t send data to the IRC network from just any process. Why not? Because IRC is a state-sensitive protocol, communication is bound to a specific client connection. PHP doesn t allow taking over foreign sockets from other processes; thus, the main process that also handles downstream communication (the process that acts as IRC client) runs isolated from all other processes.The question now is how we can open a door to pass data into the main client. How would you implement upstream communication? Make at least a theoretical approach. Draw the dataflow on paper. If you haven t done so already, write down at least three possibilities for runtime data exchange. The downstream process must keep running and may not be terminated.We can t simply reinvoke it using a POST or a GET for passing data, since that would mean launching another process, with the need to re-login, re-setup, etc. Using such an approach would result in constant login/quit sequences that would be extremely disturbing in a chat.And it would result in data loss, since during the time between a logout and a login, lots of messages could be transmitted (which would be invisible to the newly logging-in client). The chat could be based on a single bot that stayed online all the time and recorded all messages for all users into a database.The user interface would then only need to extract all meaningful data from the database. However, two problems stand against this possibility: a) The chat would be mainly database- backed (something we wanted to avoid); and b) It wouldn t make the clients visible to other IRC clients, as the bot would be the only real client on the network.This would make usage of the IRC network ridiculous. Thus, we need at least two independent processes: one that handles the IRC communication and can t be interrupted, and another to accept incoming messages from the user. Some sort of container must then be used to interface between the two processes. Figure 3.7 illustrates this problem.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
104 Chapter 3 Application Design: A Real-Life Example columns of the table to be present completely to determine the final size of the table. As long as you restrict yourself to outputting text lines one after another, and only use tables when you can print them all at once, everything works fine. Quirks such as streaming HTML are common tricks that you should know. Always keep yourself informed about such things. Streaming HTML also has one implication that some see as drawback and some as advantage: Since the client connection stays open, there must always be one server process handling it.This means that every client requires at least one Web server process to be running only for that client.The advantage is that no overhead per hit occurs. Usually, when the client requests a document, a new process has to be spawned; the script generating that document has to be loaded, parsed, and executed; and finally, the data has to be sent. Since the server process now remains in memory, however, spawning, script loading, and interpretation only have to be done once per client. On sites that would otherwise have hundreds of hits per second, this might be a definite advantage. However, each process now stays resident in memory and demands RAM for itself on Intel x86 systems equipped with Linux,Apache,and PHP 4.0, such processes tend to be as big as 2MB each. Consequently, a small server with minimal RAM on board would soon start to run from swap and that means death. Note: Swap memory is virtual memory that s meant to extend the RAM the physical amount of memory on a computer. Swap memory is stored on a hard disk, which is extremely slow.When physical memory is all used up,modern operating systems start allocating new memory in the slow swap memory. If a chat server gets hit by a lot of clients at once, which eat up all physical memory and start running in swap memory, the operating system will constantly have to exchange parts of the RAM with parts of the swap memory (since programs can t be executed from swap memory),and this starts a cycle of death :The operating system notices that a process in swap needs to be run and loads it into RAM, but has to put another running process from RAM into swap. It executes the process in RAM but finds the old process (now residing in swap) has to be run, so it swaps it back into RAM, and so on and so on.You can quickly kill a server this way, forcing it to be reset or taken off the net. By the way, this is also a common denial of service attack, a bit similar to the ones that Yahoo! and others were exposed to earlier this year. Would you have thought about the implications of resident processes? If not, make sure you do next time! Keep evaluating every situation fully. Upstream Communication Upstream communication that is, accepting user input and sending it to the network is the next stage to consider.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP MySQL Web Hosting services
Interfacing the Network 103 After doing initialization and setup, the application has to surrender control to phpIRC. phpIRC then enters its main event loop and waits for something to happen. During setup, the application has to register callbacks for each event it wants to process (for example, incoming private messages, incoming server messages, and so on). These callbacks are the only possibility for the application to regain control. phpIRC then dispatches all events to all functions that have registered themselves with the library.These functions can in turn enter another idle loop in phpIRC to wait for another event to happen, or they can use phpIRC s API to perform certain actions on the network (send private messages, join/leave channels, and so on). This very basic layout already allows for downstream communication, which means that phpIRC is able to receive messages from other users. People could actually talk to your script. Note: Downstream means from the network to the user. Upstream is the opposite, from the user to the network. Exercise for the Reader Structure a downstream interface that makes use of phpIRC s features. Implement it on paper to become familiar with phpIRC s API.Then build a simple downstream interface that logs onto IRC and displays all messages from a specified channel. Downstream Communication Since chatting is a real-time task, meaning that it happens as you do it and causes instant replies, we don t want to introduce latency into the interface. Latency describes the reaction time of the interface; for example, the time from the point when the reader presses the Enter key to submit a message until it shows up in the chat window. Even though a latency of less than a second might objectively be a very short wait, it seems extremely long and annoying to the user. Ergo, incoming messages must be displayed at once (or at least as soon as possible). HTTP is a stateless protocol, however, and doesn t allow instant updates of pages without reloading a complete document. Of course, there are multipart documents and automatic refreshes, but these options introduce a very nasty flicker each time the page loads again, require database buffering for output, and introduce lag because of constant reconnects and data transfer from the Web server. One solution is streaming HTML, something that s not officially supported anywhere,but works nevertheless:The script that does the interface output simply idles in an endless loop and doesn t terminate the HTML page the browser is receiving.When something has to be sent to the user,it s printed and immediately flushed from the server s buffers.This way,the browser is constantly rendering and always displays the most up-to-date data. One problem persists in this approach, however; no complex HTML entities can be rendered on the fly. For example, you can t output the rows of a table one by one, because the browser requires all rows and
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP MySQL Web Hosting services
102 Chapter 3 Application Design: A Real-Life Example n From one central point of the program, all data can be dispatched to all recipients transparently.You don t have to worry about manually copying and transforming structures; each event handler takes care of receiving its data on its own. n New code can be plugged into the application extremely easily, just by creating a procedure that registers itself to the appropriate event. Thus, once the main event-dispatcher framework is created, the whole application can be created by writing handlers, handlers, and more handlers. Get familiar with the techniques used to implement finite-state machines.These are elemental in programming and information processing in general. Luckily, the event-dispatcher framework is already contained in phpIRC, so we won t need to do that programming for this project. Interface Structure phpIRC forms the IRC client part of the application and is responsible for all network communication.This means that it also needs to be in control all the time to be able to react to network messages in a timely manner. If phpIRC s message- processing functions were activated only occasionally, safe, secure, and speedy communication couldn t be guaranteed. For this reason, phpIRC forces a special program layout, as shown in Figure 3.6. Main application Program entry point Passing control to phpIRC phpIRC Initialization Setup Incoming network data Outgoing network dataCallback 1 Callback 2 Callback 3 Callback n . . . Figure 3.6 phpIRC s forced application layout.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP MySQL Web Hosting services
100 Chapter 3 Application Design: A Real-Life Example The library we ve chosen for this project is phpIRC (www.phpwizard.net/phpIRC), for these reasons: n It s easy to use. n It s a powerful, complete API. n It uses event-based processing. The use of event-based processing is particularly interesting here.This is a technique usually implemented in traditional applications; for example, all Windows programs are event-based. Event-based programs run in an endless loop, waiting for something (an event) to happen. Events can include user input, mouse movements, network events (incoming packets),etc.As soon as an event is signaled,the program breaks out of its main loop and searches for a procedure that handles this event.All procedures that want to handle the event that just occurred are called with the specific parameters of the event (for example, packet data of incoming network traffic). Concretely, using traditional programming, an incoming ping would be handled as shown in Listing 3.1: Listing 3.1 Pseudocode for handling a ping. again: wait_for_network_data(); if(incoming_data == ping) { send_pong(); update_traffic_counter(); } goto again; This code waits until it receives data from the network, then tries to find out whether the data was a ping. If so, the code sends a pong back and updates a traffic counter for statistical reasons.After that,it just jumps back to where it began.Imagine this with hundreds of events, some of which might depend on others, some not, some only under certain circumstances A pain! However, event-based programming makes it significantly easier, as shown in Listing 3.2: Listing 3.2 Event-based pseudocode for handling a ping. event_handler ping() { send_pong();
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Interfacing the Network 101 } event_handler incoming_data() { update_traffic_counter(); case of ping: handle_event(ping); } while(not_done()) { wait_for_event(); case of network_data: handle_event(incoming_data); } The code looks bigger,but also much clearer.The main loop waits for an event to happen. If it finds that an event happened and that it was triggered due to incoming network data, it dispatches this event using the central procedure handle_event(). This function then determines a handler for the event and calls it.The handler in turn updates the traffic counter and launches another event if the first event was a ping. After dispatching the event using handle_event() again, a pong is sent. Alternatively, both ping() and incoming_data() could register themselves to the event incoming_data . However, creating two different events gives a greater variety of events and thus allows for much more detailed, target- oriented processing. It s a bit strange at first getting used to event-based processing of information (it works similarly to a finite-state machine), but it has many advantages: n A modular structure is forced on the application. Each module works independently of the other modules and can easily be changed, exchanged, or extended. n Any part of the program can trigger any kind of event and thus enforce any type of reaction in the application (in other words, you can control any part of your code from any other part of your code).
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Interfacing the Network 99 Interfacing the Network As we mentioned earlier, IRC requires some processing overhead. Hacking a complete protocol handler for interfacing with IRC is a bit of a complex task, but we favored IRC instead of the database-backed solution because an API already exists that does this work for us. Know the market! It s essential for every programming project to know which parts have already been done by other people and which still need to be done. Never reinvent the wheel! Especially for commercial projects, it can pay off tremendously to buy foreign bulletproof solutions for specific tasks, rather than design and develop one yourself.The latter is sometimes more expensive and much more time-consuming. On top of that, external solutions are usually constantly being improved a process that s totally independent of the progress of your own project. By receiving an upgrade from an external company, you simply replace a part of your application with a newer version.This way,you can upgrade certain parts of your application without having to put your own work into the changes. Plus, when using existing libraries, you automatically agree to build your project on common, standardized APIs, which is always a great benefit. On the other hand, binding yourself to foreign products can prove to be a negative decision if the producer fails to improve the product or keep it up to date, as well as if bugs in it aren t corrected. In our experience, Open Source products have been the most successful external parts to be integrated. Open Source products are being improved and extended extremely rapidly and are usually oriented at common and open high-potential standards. Exercise for the Reader Search for applications/libraries written in PHP that make use of IRC and compare them in terms of design, flexibility, and ease of use. Of course, the implementation is also interesting (but shouldn t be your main focus). The design is always the most crucial part of development; after the design is finished, the actual implementation is usually straightforward and easy to do (even though a lot of programmers think differently).
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
Fitting the Application into the Network 97 Multiplexing Client 1 Client 2 Client 3 S e r v Network link Network link Hub . . e . r Client n Demultiplexing Figure 3.3 Network structure from a server s point of view. The structure implemented here is similar to a mixture of a multiplexor, demultiplexor, and a hub. In the direction client to network, the server compresses all data from the clients and sends it to the network links. In the other direction, it determines which information from the network is important for which client and sends it to the appropriate link.All incoming data from the network that has to be passed on to the other network links is sent on directly. Basically, this is the setup we d need for our own chat system. Now take a minute and try to imagine how we can achieve our goal.We need a working server environment that fits the following description: n Accepts IRC network links n Accepts IRC client links n Provides a Web-based user interface n Is as easy to implement as possible Fitting the Application into the Network If you came up with a plan to develop your own server in PHP (or something similar), rethink a bit.You might have gotten a bit confused with the idea that implementing a chat server means implementing a network server.This is indeed something we wanted to lead you to, but don t want you to do, as this is simply unnecessary there s already a well-written server software available for all systems. So how about using one of the existing servers and representing our server to the network as a client? The only thing we d have to do is to add another layer of abstraction to the network, as shown in Figure 3.4.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services
98 Chapter 3 Application Design: A Real-Life Example Client 1 Client 2 Client 3 Client n W e b s e r v e r Network link Network link . . . I R C s e r v e r Figure 3.4 phpChat as an abstraction layer to the server. The Web server will run the PHP chat server. For each client connection it accepts, it will create a client connection to the IRC server.This way,we can make sure that all data we get for this client is meant only for this client and nobody else. Each chat process will carry a single user, and doesn t have to worry about other users. User coordination, traffic control, and so on can be done by the IRC server, for which we ll simply take one of the freely available servers. This technique also has the advantage that this chat server application can be used as a safe gateway to IRC networks (see Figure 3.5).A lot of corporate and private networks are behind firewalls that filter IRC ports. Since this chat is only communicating via HTTP to its clients (which is not filtered), only the chat server itself needs an open connection to an IRC server. Therefore, the only thing we re going to do is to implement the client software that would otherwise be required on the user s side on our Web server. IRC knows all the commands that are required to set up a powerful chat, and the networking issues can all be solved by using standard off the shelf server software that s already available. Thus, if our interface supports all features of IRC in a convenient way, we re done with our work. HTTP HTTP IRC Port 80 Port 80 Port 6667 I R C s e r v e r Network link Client 3 r W Client 1 F e Client 2 i b . es we Network link .a r . lv le Client n r Figure 3.5 phpChat as a safe IRC gateway.
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost PHP Web Hosting services