[DotGNU][Load Balancer Proposal]<Original>Stargazer

[Vassilis Pandis]

--- PROPOSAL ---

* Subject Line:

* This Proposal is For a New:

        [X] DotGNU software development project

                Project name: Stargazer

                Packages in this project: Stargazer

        [ ] Other
                List here:


* Essential Resources:

        [ ] Mailing lists
                Mailing list names: 

                Mailing list descriptions:

        [X] Website resources
        [X] Savannah location and space
                Savannah username: <what do i put here ?>

                Savannah Project Name: stargazer

        [ ] Other
                List here:

* Are you willing to lead this project?:        
        
        [X] Yes
        [ ] No

* Description:

Note: I sent this to [Proposals] and after receiving
no reply, and after 
      discussing it on the IRC channel, I was told to
post it here.

I had been writing a TCP/UDP load balancer as an
alternative to commercial solutions. Then after
surfing www.gnu.org I ran across the DotGNU project
and took a look at the FAQ. There I saw that you were
planning to develop a load balancer. I thought that it
would be far better to support the DotGNU project than
to release it on my own and found out a few years
later that I can't use the Internet without
Microosofts products. Anyway, could this code serve as
a base for future development ? It has been written in
C with portability as a primary objective. It also has
proxying capabilties. It consists of approximately
1700 lines of code and compiles to be 30KB, 24KB
stripped. It does not require root to run ( actually,
root must start it, but it then drops to a
user-configured UID, since it needs to bind() to ports
under 1024 ). It
also chroot()s. It uses a simple send()/recv()
mechanism that hopefully works. It is not done yet,
not even for RC1. The configuration file parsing code
is a little bit broken :) but it should be quite easy
to fix. In the unlikely case that the redirection code
doesn't work either, it can be easily rewritten using
a select() call. TCP fail-over mechanisms have also
been implemented : when one TCP server fails, the load
balancer automatically evenly distributes the requests
over the network. When the TCP server is operationable
again, it automatically returns to its previous
configuration. It uses a simple balancing algorithm
based on percentages ( this server gets 50%, the other
30% and that slow 386 box 20% ). Configuration can be
changed on the fly ( via a SIGUSR1 ). Future plans are
to incorporate a real benchmarking tool that will
measure all servers' performances and will print out
the recommended load percentage for each server. No
non-free information or technologies were used when
designing/coding it. Stability and efficiency are
primary objectives. For now, I am willing to lead the
project but since school hasn't started I can't really
judge ( i'll be able to tell in a month or so ).
Please reply if this is of any interest.

Ps: Let's change the name if you find a cool, quad
recursive acronym >:)


* Proposal Version (integer): 1

* Proposal Version date stamp: 25/8/2002

* Proposal Maintainer name: Vassilis Pandis

* Proposal Maintainer e-mail: address@hidden

* Revisions: - 

--- END PROPOSAL ---


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com