Brian Densmore wrote: >Rather than using behemoth hardware, what about a "load-balancing" >server situation. Something sort of like network load-balancing. You >would need some kind of monitoring system, so that no one server would >get more connections than it could handle comfortably. > >Something like this (pardon my poor graphics): >____________ ____________ ____________ >| client 1 | | client 2 | ... | client n | >|__________| |__________| |__________| > | | | _____ >----------------------------- ... --------------|lan| > ___|______ |___| > | Load | > |balancer | > |_________| > | > ----------------------------- ... ---------------- > | | | > ____|_______ _____|______ _____|______ > | server 1 | | server 2 | ... | server m | > |__________| |__________| |__________| > > Thus far, when our customers have requested >50 users, we have suggested either more than one server and a segmented network OR a behemoth w/ gigabit backbone. That will always be prefered over something like the above diagram because it decreases the number of points of failure. The above suggested diagram is not far from what we're planning for other cases but the trouble has been that you don't just "have a table that lists all the servers with a number of max clients, keep a running tally of current clients, and direct traffic from the client to the proper server". For one thing, all X11 communications are UDP which, as far as I know, is impossible to automatically get around an IP NAT. At the kernel level, Linux has something thats relatively new in the IPv4 stuff that allows for transparent balancing as you suggested but we haven't tried it yet as there has been no demand. Also, on clusters, there is a pretty high level of hardware requirements you have to meet before doing a cluster becomes cost effective. Some of the hardware thats available now-a-days in rack configurations is really impressive; the sky is literally the limit on some of that stuff. We've tersly examined the possiblity of doing a cluster and believe it would be possible but haven't explored it.