Graham. I already accept that this seems to fait-accomplis. So I am just arguing for entertainment purposes.
If the solution is a p2p one then it might be somewhat interesting. Otherwise, it just seems (to me) to be re-inventing the wheel ... potentially very badly. Adding load-balancing/clustering to software projects seems to be popular (i know of others :-) lately ... it seems like the idea that every end-user application adds features until it can do email. On Mon, 2006-31-07 at 18:26 +0200, Graham Leggett wrote: > On Mon, July 31, 2006 6:16 pm, Guy Hulbert wrote: > > >> At the network layer, your metrics are pretty much "volume of data" or > > > > Nope. > > > > Routers can look at anything in the packets which is not encrypted. > > They can also measure server response (by packet stats) directly or via > > SNMP. There are all sorts of things that *cannot* be done on the server > > without introducing all sorts of p2p communications requirements. > > I'm sure they can. This doesn't make them the right solution for all cases. > > In a multi tier architecture, you already have front end servers > implementing URL strategies, common logging, all sorts of other things. The 1997 system I referenced was already a multi-tier architecture. The integration group was implementing systems on large world-wide private networks. > > Adding an extra router layer to handle load balancing, when your already > existing frontend can do this job is not only extra cost, but extra > complexity and an additional point of failure. Without knowing the specific network involved this is just wanking. The implementation of the IBM software solution software solution I described previously required 4 PCs precisely because of the problem of redundancy, monitoring and failover. The PCs were paired with a heartbeat running on loop-back interfaces. Do you know anyone running an apache service over the internet without a router somewhere? I doubt that IP via carrier pigeon has sufficient bandwidth. My only interest in this is you are putting all the additional complexity into the Apache server. > > Regards, > Graham > -- > > -- --gh
