|
Hello,
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?
Daemon
> 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
Regards
--
Julian Anastasov <ja@xxxxxx>
|
