[Kimchi-devel] [RFC] discover Kimchi peers

[Aline Manera]

On 07/03/2014 12:03 PM, Sheldon wrote:
> On 06/05/2014 08:53 PM, Aline Manera wrote:
>> On 04/17/2014 10:38 AM, Sheldon wrote:
>>> I'd like to talk about how to discover Kimchi peers.
>>>
>>> Now I just talk about  discover a peer in a same network here.
>>>
>>> I will use a local multicast subnetwork address
>>> <http://en.wikipedia.org/wiki/Multicast_address#Local_subnetwork> to
>>> find peers in one network.
>>> Choose 224.0.0.132 as the kimchi multicast address, and 8000 as the port.
>>>
>>
>> How will you choose the multicast address?
>>
>> You can not assume all Kimchi servers is running in the default port 8000
>> The user can change it.
>>
>> In my mind I think we should send a broadcast message in the network
>> and wait for the responses.
>> And we need to add a hook in Kimchi to respond to those messages with
>> the IP and port number Kimchi is running.
>
> zhengsheng suggested *upnp-inspector. *
> looking into *upnp-inspector
>

What about openSLP? Seems it is simple to use.
We just need to register kimchi server on startup and unregister on shutdown

http://www.openslp.org/doc/html/IntroductionToSLP/index.html
http://www.openslp.org/doc/html/UsersGuide/SlpReg.html

> *
>>
>>> For cross network  that need the router support multicast, so I give
>>> up discover a peer cross network.
>>> I will let user add the remote peers manully.
>>>
>>> In the whole system all peers are equal. There will not be a center
>>> discover service.
>>>
>>> We will define two kinds of multicast message Notify and Search.
>>> the format as follow.
>>>          #  ____________________________________________
>>>          # |        head       |  message body   | tail |
>>>          # |___________________|_________________|______|
>>>          # |sizeof(messageBody)|  json message   | EOL  |
>>>          # |___________________|_________________|______|
>>>
>>> the flow of  discover Kimchi peers:
>>> 1. one host multicast a "search" message. in this message it tell
>>> himself information, and ask others tell their information.
>>> Like this:
>>>    {"search": {"domain": "kimchi-host1", "IP": "192.168.0.3",
>>> "httpport": "8000", "httpsport": "8001"}}
>>>    this means "hello, I'm a kimchi host, this is my information, can
>>> you tell me who you are?"
>>> 2. others received a search will response an "notify" message.
>>> Like this:
>>>    {"notify": {"domain": "kimchi-host1", "IP": "192.168.0.3",
>>> "httpport": "8000", "httpsport": "8001"}}
>>>     this tells others that "hi, I'm a kimchi host, I'm alive and this
>>> is my information"
>>>
>>> o (user)  1 is "search"
>>> /\  -------->                                        2 is "notify"
>>>               | 1                        _____ ________________
>>>     kimchi-host1 ------2-<---| DB |<----2-----|multicast listen |<--2--
>>>                               |           |____| |_______________|
>>>         |
>>> ----------------------1------------------------------->  |
>>> |
>>> _____ |_____
>>> |                 |
>>>                                                              |
>>> switch     |
>>> |                 |
>>> |___________|
>>> o   (user) |
>>> /\  --------- -----------------------------2----------------------- --->|
>>>               |             |            _____
>>> ________________           |
>>>     kimchi-host3 ------1<---| DB |<---1------|multicast listen |<---1--|
>>>                                         |____| |_______________|
>>>
>>>
>>> we need to discuss:
>>> 1. should we support beat heart?
>>> every kimchi host will send periodic notify to tell others himself
>>> information?
>>>
>>
>> I don't think we need it. Kimchi should only send the information when
>> it is requested for
>>
>>>
>>> 2. should we support a "quit" message?
>>> "quit" message tell other peers, that this kimchi quit normally.
>>> others can remove this from peers list.
>>> But the kimchi can not send "quit" when aborting abnormally.
>>>
>>> 3. Do we store the local peers information in DB?
>>> we can collection the local peers and send them immediately when user
>>> need to discover the peers.
>>>
>>
>> I don't like it. It is an easy point of failure as we will make sure
>> the DB is consistent, ie, make other
>> request to kimchi servers so there is no need to store that info.
>>
>>> We will extend to support remote peers, these information need to be
>>> stored in DB.
>>>
>>> --
>>> Thanks and best regards!
>>>
>>> Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
>>> IBM Linux Technology Center
>>>
>>>
>>> _______________________________________________
>>> Kimchi-devel mailing list
>>> Kimchi-devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
>
> --
> Thanks and best regards!
>
> Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
> IBM Linux Technology Center
>