[Kimchi-devel] [RFC] discover Kimchi peers

[Sheldon]

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140703/72c2325f/attachment.html>