--- Andre Garzia <[EMAIL PROTECTED]> wrote: > Hello Folks, > > I am here experimenting with a new approach to > building revolution > based servers. We've been asking for threads or > forks for a while but > until the day of such implementation comes, we need > to use what we > can. One other language I always liked (to the point > that we created > a whole company around it some years ago) was REBOL. > I remember from > the blogosphere that someone did a REBOL based > webserver with some > nice benchmarks, I decided to check it out because > last I remembered, > REBOL was also a single thread language. After > checking many sites, I > discovered that they along with other people around > are using a > process pool and a scheduler that handles the > connections and > redirect them to the next free process on the pool. > > I decided to take the same approach, I made a > tweeked version of my > RevHTTP server that can be launched from a shell() > call so that I can > create a scheduler that can launch some number of > processes to make > the pool. I created a simple communicating scheme > using wget to make > little semaphores so that each server instance can > tell the scheduler > where it is busy or free. So far, so good but > there's one problem. > > Suppose the scheduler is running 8080 and each > server instance in the > pool is running from 8081 onwards. When the client > connects to 8080, > the scheduler sends back a redirection response so > that the client > refreshes to a different port (of a free instance in > the pool). The > problem is that a http client such as a browser will > then request > favico and all the links in the html from the same > port for it re- > uses data from the connection that yielded that > result to fill > missing data in the URL. For example, if you make a > link that goes > to /newpage.html, then the server will make it > http://yourserver/ > newpage.html. If I answered from port 8081, all > links in the page > will "inherit" that port and I want all the > connections to come to > the scheduler running on a different port. > > One approach to solve this is to parse all the > response and change > all the html responses to include the correct URLs. > This is very > boring and slow for we must cope with href, src, > link, rel and all > kinds of css includes and stuff. What I hoped to > find was some HTTP > header field that would tell like: "hey this server > is acutally > running at port bla bla bla" such as: > > host: localhost:8080 > > despite the fact that that answer came thru 8081. > This way the whole > thing would work and maybe we would have a a web > server built with > Rev that could see some real world use... > > Anyone has two cents? > > Andre >
Hi Andre et al, During one of my similar experiments, I ended up with an http server that didn't do any of the serving itself, but acted as a router between the client computer and the server apps. The server apps ran on ports that were blocked from outside access, instead of using redirects. The housekeeping can be done fairly easily, and you can use a chunking approach along with asynchronous write to socket commands. However, rapidly refreshing the browser can result in a serious overload of the routing/scheduling app so you'll want to add the necessary logic to cancel requests that are being processed by the server apps. Just my two eurocents, Jan. Quartam Reports for Revolution <http://www.quartam.com> ===== "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld) ____________________________________________________________________________________ Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution