For a code example of how you do this see MP3 server with IO::Socket. HTTP is a request response protocol where a client sends requests to a server that then produces a response. Essentially you create a Socket connection (using IO::Socket is easiest) to communicate across the network. Once the socket is created you talk across it using HTTP and tcp/ip. There are a number of modules that implement HTTP client/server functionality on CPAN, see HTTP:: for details. Although many think of WWW and HTTP together this need not be the case.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

It sounds to me like you're getting confused between two different concepts. The proxy servers have nothing to do with MVC per se. They are there to help performance by handling requests for static files and by caching any pages that the app servers say can be cached (by looking at the Expires headers). They also handle sending out the result to the client, which keeps slow modem users from tying up a process on the app servers during download. The communication between the proxies and the app servers is HTTP, as you said.

The MVC stuff is all in the app servers. The model, controller, and view components are separate classes (well, technically the views are all Template Toolkit templates in this case), and they communicate to each other through standard method calls. None of the components is ever active on the proxy servers. Those are really just web serrvers with mod_proxy and mod_rewrite installed, and they don't run any Perl code.

I hope that clears it up for you. If you have more questions, ask away.

Sir, Thanks a lot for the explanation.It really helped me to understand that the MVC is in the app.server side.You also mentioned that the business data objects like the product data is cached and if my understanding from the doc.is right,you mentioned that the caching mechanism in written in C (for performance in the app side).So the question is , are you using socket in the model layers to communicate it to the cache to fetch the data objects? If so, do we have any custom written message protocol to accomplish this. Too much of interest in your article is making me to ask these kind of foolish questions, so kindly bear with me.

The caching of data objects was done using BerkeleyDB. We wrote a simple cache interface on top of it to keep track of an expiration time for each entry and only return unexpired items. These days, you could just use Cache::Cache for this. That module wasn't around when we started.

The part in C was a daemon on each app server to broadcast shared data to all the other app servers. The only data we shared was the read-only product data which should be the same on any server.