[RFC] discover Kimchi peers
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. 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? 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. We will extend to support remote peers, these information need to be stored in DB. -- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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.
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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. can you elaborate how hook works?
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 ACK.
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. ACK
We will extend to support remote peers, these information need to be stored in DB.
-- Thanks and best regards!
Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(???)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
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@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards!
Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
on 2014/07/08 10:20, Aline Manera wrote:
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 :-)
Took a look at SLP. It looks exactly what Kimchi needs. I makes use of multicasting under the hood, and provide a meaningful URL scheme for the applications. -- Zhou Zheng Sheng / 周征晟 E-mail: zhshzhou@linux.vnet.ibm.com Telephone: 86-10-82454397
participants (3)
-
Aline Manera -
Sheldon -
Zhou Zheng Sheng