[Kimchi-devel] [RFC] discover Kimchi peers

[Aline Manera]

On 07/04/2014 02:24 PM, Aline Manera wrote:
>
>
> 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

I've just tested openSLP and it works pretty well and attends Kimchi needs.
I will send a RFC patch soon.

>
>> *
>>>
>>>> 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
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel