Re: Release new code: Scheduler for distributed caching- API

To: Mark <mark@xxxxxxxxxxxx>
Subject: Re: Release new code: Scheduler for distributed caching- API
Cc: "Matthew S. Crocker" <matthew@xxxxxxxxxxx>, Thomas Proell <Thomas.Proell@xxxxxxxxxx>, lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Sat, 28 Oct 2000 10:56:11 +0000 (GMT)

On Sat, 28 Oct 2000, Mark wrote:

> While we are talking about an API for the real servers to talk to the
> director, here's a feature that I will be needing in the future:
> A command to let the real server change a Connection persistence mapping on
> the director. Looking through the code it  seems like only a couple of lines
> manipulating the hash table..(lock, remove,add,unlock). The library could
> have a function call like "ERROR_CODE lvs_UpdatePersistantHashTable(Client
> Identifier, Old Real Server, New Real Server);"

        What is the exact scenario for this trick.

> Just thought I would mention it in the hope that if an API gets developed,
> this feature is added.
> If not and I decide to go with LVS when I cluster my server, someone from my
> team will be patching the LVS code to do this.
> Here's a quick question: what would be the best way to implement the API
> library?.
> My thoughts went along the line of a client library that sends commands to
> the director through UDP packets.

        This is the transport, we can use many transports - the user
decides. May be the user will prefer to use TCP.

> If so, does the director have a daemon running to listen to those commands
> or does the LVS code do it directly?


> If a daemon is used, how does it call the functions to update the
> persistence hash table?

        See how ipvsadm.c is using setsockopt().

> (Sorry for the newbie question but I only switched from NT a while ago and
> I'm still getting used to the idea if modifying/reading kernel code (I love
> it!:) so I'm not quite sure of the schematics...
> I'm hoping its just a matter of a including the right header/lib file but
> somehow I doubt that :)
> Mark Pentland


Julian Anastasov <ja@xxxxxx>

<Prev in Thread] Current Thread [Next in Thread>