<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV>> The only bright point I can offer here is that I'm 100% certain
that<BR>> the LVS source code has __not__ been modified. <BR></DIV>
<DIV>Which really makes me annoyed, because I cannot right now see any other
obvious path (i.e. simpler). </DIV>
<DIV>g-)</DIV>
<DIV> </DIV>
<DIV>> <BR>> Sorry,<BR>> Paul<BR>> <BR>> <BR>> On Apr 11, 2005
4:46 AM, Greger V. Teigre <greger@teigre.com> wrote:<BR>> After my last
email, I looked at ktcpvs and realized I ignored a<BR>> couple of things:
ktcpvs only supports tcp (http is obviously<BR>> tcp-based, but I thought it
supported udp for other protocols). I<BR>> don't know how much work
implementing udp would be. <BR>> Here is
a discussion of SIP and LVS that I found useful (though<BR>> not
encouraging). <BR>>
http://www.austintek.com/LVS/LVS-HOWTO/HOWTO/LVS-HOWTO.services_that_dont_work_yet.html<BR>>
<BR>> Paul: I'm starting to get really curious on the standard LVS<BR>>
components used for your stickiness! I'm not aware (also after<BR>>
searching now) of an LVS balancing mechanism that allows correct<BR>>
stickness on SIP udp...! <BR>> And I found other too who are
looking for it:<BR>>
http://archive.linuxvirtualserver.org/html/lvs-users/2005-02/msg00251.html<BR>>
<BR>> My understanding is that ipvs must be extended (according to
the<BR>> developer) with a call-id based scheduler and that this work
has<BR>> several people willing to fund development, but that this has
not(?)<BR>> started yet. The problem is that ipvs is based on ip header
analysis<BR>> and extending the hashing algorithms to also include
payload-based<BR>> analysis is not straight-forward.
<BR>> g-)</DIV></BODY></HTML>