[Kimchi-devel] [RFC] discover Kimchi peers

[Sheldon]

On 07/08/2014 03:44 AM, Aline Manera wrote:
>
>
> 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.
Thanks.
Simon Jin is working on this feature.


>
>>
>>> *
>>>>
>>>>> 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
>
>


-- 
Thanks and best regards!

Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center