[tickets] [opensaf:tickets] #2610 dtm: Propagate peer IP addresses dynamically

2019-07-22 Thread Gary Lee via Opensaf-tickets
- **Milestone**: 5.19.07 --> future



---

** [tickets:#2610] dtm: Propagate peer IP addresses dynamically**

**Status:** assigned
**Milestone:** future
**Created:** Wed Oct 04, 2017 11:53 AM UTC by Anders Widell
**Last Updated:** Wed Jul 03, 2019 06:28 AM UTC
**Owner:** Anders Widell


When using unicast, the initial list of IP addresses may be become out of date 
when new peers are added. We can dynamically update the list of peer IP 
addresses using several mechanisms. The newly detected addresses should at 
least be stored in RAM inside osafdtmd, but can possibly also be written down 
to disk on persistent storage so that they are remembered after a restart of 
OpenSAF or even after a complete node reboot. The mechanism to detect new 
addresses include:

* Look at the source IP address of incoming TCP connections and check if it is 
a known or unknown (new) source
* Use some form of protocol (e.g. a gossip protocol) to exchange peer IP 
addresses between nodes that are connected with each other.

We probably also need some mechanism to purge the list of peers, when an 
auto-detected IP has not been in used for a period of time.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2610 dtm: Propagate peer IP addresses dynamically

2019-01-09 Thread Gary Lee via Opensaf-tickets
- **Milestone**: 5.19.01 --> 5.19.03



---

** [tickets:#2610] dtm: Propagate peer IP addresses dynamically**

**Status:** assigned
**Milestone:** 5.19.03
**Created:** Wed Oct 04, 2017 11:53 AM UTC by Anders Widell
**Last Updated:** Wed Jan 09, 2019 09:23 PM UTC
**Owner:** Anders Widell


When using unicast, the initial list of IP addresses may be become out of date 
when new peers are added. We can dynamically update the list of peer IP 
addresses using several mechanisms. The newly detected addresses should at 
least be stored in RAM inside osafdtmd, but can possibly also be written down 
to disk on persistent storage so that they are remembered after a restart of 
OpenSAF or even after a complete node reboot. The mechanism to detect new 
addresses include:

* Look at the source IP address of incoming TCP connections and check if it is 
a known or unknown (new) source
* Use some form of protocol (e.g. a gossip protocol) to exchange peer IP 
addresses between nodes that are connected with each other.

We probably also need some mechanism to purge the list of peers, when an 
auto-detected IP has not been in used for a period of time.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2610 dtm: Propagate peer IP addresses dynamically

2018-09-29 Thread Gary Lee via Opensaf-tickets
- **Milestone**: 5.18.09 --> 5.18.12



---

** [tickets:#2610] dtm: Propagate peer IP addresses dynamically**

**Status:** assigned
**Milestone:** 5.18.12
**Created:** Wed Oct 04, 2017 11:53 AM UTC by Anders Widell
**Last Updated:** Thu Aug 30, 2018 12:45 PM UTC
**Owner:** Anders Widell


When using unicast, the initial list of IP addresses may be become out of date 
when new peers are added. We can dynamically update the list of peer IP 
addresses using several mechanisms. The newly detected addresses should at 
least be stored in RAM inside osafdtmd, but can possibly also be written down 
to disk on persistent storage so that they are remembered after a restart of 
OpenSAF or even after a complete node reboot. The mechanism to detect new 
addresses include:

* Look at the source IP address of incoming TCP connections and check if it is 
a known or unknown (new) source
* Use some form of protocol (e.g. a gossip protocol) to exchange peer IP 
addresses between nodes that are connected with each other.

We probably also need some mechanism to purge the list of peers, when an 
auto-detected IP has not been in used for a period of time.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets


[tickets] [opensaf:tickets] #2610 dtm: Propagate peer IP addresses dynamically

2017-10-04 Thread Anders Widell via Opensaf-tickets



---

** [tickets:#2610] dtm: Propagate peer IP addresses dynamically**

**Status:** assigned
**Milestone:** 5.17.10
**Created:** Wed Oct 04, 2017 11:53 AM UTC by Anders Widell
**Last Updated:** Wed Oct 04, 2017 11:53 AM UTC
**Owner:** Anders Widell


When using unicast, the initial list of IP addresses may be become out of date 
when new peers are added. We can dynamically update the list of peer IP 
addresses using several mechanisms. The newly detected addresses should at 
least be stored in RAM inside osafdtmd, but can possibly also be written down 
to disk on persistent storage so that they are remembered after a restart of 
OpenSAF or even after a complete node reboot. The mechanism to detect new 
addresses include:

* Look at the source IP address of incoming TCP connections and check if it is 
a known or unknown (new) source
* Use some form of protocol (e.g. a gossip protocol) to exchange peer IP 
addresses between nodes that are connected with each other.

We probably also need some mechanism to purge the list of peers, when an 
auto-detected IP has not been in used for a period of time.


---

Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/opensaf/tickets/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/opensaf/admin/tickets/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets