RE: Data Piping
Hi friends,
there ae a lot of load-balancer outside. All of them have probelems in some
listed points below:
- graceful dead (can I shutdown a server without distrubing my users?)
- amount of concurrent sessions
- is the balancer itself redundant
- when redundant : failover time
- are there sticky ports (if there is a http-connection and additional
sound, will both be forwarded to the same server ?)
- cookies
- https (ssl traffic)
- throughput
of course, as you can see I'm an enterasys employee and we have some
loadbalancers. And of course, nothing is perfect!
something I would keep in mind is always a clean design with powerful
options for taking some traces. If you do not know the way your packets are
going (or balanced) it is difficult to find those which are lost ...
-----Original Message-----
From: Benjamin Lee [mailto:benjaminlee@consultant.com]
Sent: Thursday, November 09, 2000 2:22 AM
To: Ryu, Cheol
Cc: Steve Gonczi; lvs-users@LinuxVirtualServer.org;
debian-firewall@lists.debian.org
Subject: Re: Data Piping
On Thu, Nov 09, 2000 at 10:15:43AM +0900, Ryu, Cheol wrote:
> Let me explain one apllication;
> Resonate(www.resonate.com) has a patent on delayed resource binding,
according to
> the URL which the client requests they select a web server. But if the
requests are in one
> persistent connection, they probably need switch to another server
according to the URL
> binding rule. They can disconnect the original connection and can
establish a new connection
> internally, but they can also maintain multiple connections. If you keep
TCP end points
> (IP address and Port Number) and TCP sequence number, you can demultiplex
or translate.
>
> Basically, this is one of NAT techniques.
Hello,
Now this *is* an interesting motivation.
Ben.
--
B. http://makelinux.org/ "Always real." http://realthought.net/
__________________________________________________________________________
For my birthday I got a humidifier and a de-humidifier... I put them in
the same room and let them fight it out.
-- Steven Wright
--
To UNSUBSCRIBE, email to debian-firewall-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Reply to: