|
Hello,
On Wed, 24 Jan 2001, ratz wrote:
> > you haven't checked out is a bad ass utility which you can d/l from
> > www.insecure.org) to allow for a fastest responce type scheduling
> > algorithm... I don't really see why the code couldn't keep(or allow us to
>
> Well, as far as I see the LVS code, there is already some kind of stateful
> connection handling. On the other hand I have to admit that if you fake
> sequence numbers and a SYN -> SYN/ACK timeshifted you could fill up the
> LVS-table, maybe.
There is another danger: creating one connection and sending
many packets. When one real server dies, continue with the next one.
I'm not sure whether the netfilter's target "limit" will prevent this.
May be we need per-connection packet rate limit in LVS? Or the user
needs more complex setup, for example using QoS features?
> > derive) information about the responce time because the netfilter code also
> > has the ability to shape bandwidth through an add on( the compleate details
>
> The traffic bandwidth shaping IMHO isn't done by the netfilter code,
> it's in the routing and QoS code. Netfilter can hook to the QoS code
> and profit from it. But maybe we are also talking about completely
> different things ;)
Yes, QoS hooks in the pre-routing, pri=1. DNAT/BALANCE will not
benefit but LVS will do.
> Best regards,
> Roberto Nibali, ratz
>
> --
> mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
Regards
--
Julian Anastasov <ja@xxxxxx>
|
