[Kimchi-devel] [RFC] discover Kimchi peers

Tue Jul 8 02:20:31 UTC 2014

On 07/07/2014 08:51 PM, Sheldon wrote:
> 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.
>

The openSLP patches are almost done!
Simon Jin can work in other task as we have a lot to do for Kimchi 1.3 :-)

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