> The only bright point I can offer here is that I'm 100% certain that
> the LVS source code has __not__ been modified.

Which really makes me annoyed, because I cannot right now see any other obvious path (i.e. simpler). 

g-)

 

>
> Sorry,
> Paul
>
>
> On Apr 11, 2005 4:46 AM, Greger V. Teigre <greger@teigre.com> wrote:
> After my last email, I looked at ktcpvs and realized I ignored a
> couple of things: ktcpvs only supports tcp (http is obviously
> tcp-based, but I thought it supported udp for other protocols).  I
> don't know how much work implementing udp would be.  
>     Here is a discussion of SIP and LVS that I found useful (though
> not encouraging).
> http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html
>
> Paul: I'm starting to get really curious on the standard LVS
> components used for your stickiness!  I'm not aware (also after
> searching now) of an LVS balancing mechanism that allows correct
> stickness on SIP udp...!  
> And I found other too who are looking for it:
> http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html
>
> My understanding is that ipvs must be extended (according to the
> developer) with a call-id based scheduler and that this work has
> several people willing to fund development, but that this has not(?)
> started yet.  The problem is that ipvs is based on ip header analysis
> and extending the hashing algorithms to also include payload-based
> analysis is not straight-forward.    
> g-)