Mostly done.. must find a way to allow master registration and
reception of peer list BEFORE validating incoming messages to the peer
list -- chicken and egg problem. Easily solved, but needs an EFFICIENT
solution since EVERY PACKET will be passed through this test.
There was no reason for the IPSC class to contain the function for
processing a peer list. It makes the class more self-sustaining, but
the goal should be a *module* to handle connection maintenance. I moved
the peer list process, and built a mode decoder function from the
previos mode printing function, as well as added decoded mode items to
the data structure… and cleaned up the prining function so it doesn't
re-process the data.
Mostly references to my_ipsc_config data structure items that are
commonly used. These received shortened names within the IPSC class…
also makes it easier to read, and should be self explanatory. Some
cruft also removed - object aliases that were no longer used.
These have been open issues. They are mostly completed. Now, once a
master or peer is registered, keep-alives start, and run every
(configurable) time, unless (configurable) times are missed, and then
it de-registers the peer. The outstanding counter still needs work, but
the important parts are there.
Work done on issues of timed actions for us to initiate relationships
with IPSC peers.
Tons of comments added so it likely actually makes sense to a reader
now.
In the data structures, I had kinda been storing things randomly. In
preparing to address more of the issues, it was clear this needed (and
still does) cleaned up. Other than a few mods along the way, the goal
has been to minimize conversions while processing "real" in/out network
traffic, and do as much as possible one-time (such as the peer list),
or in formatting for output -- which is really mostly debugging and
will go away.
I tried to better explain the communcations with masters and peers by
adding flowcharts to document the states, timers and counters
associated with establishing and maintaining the relationships.
Currenlty, the configuration file is merely a python data structure of
nexted dictionaries and lists. Eventually it should be moved to a
regular text-based configuration file with a parser to build the data
structure.
Added new datatypes (and changed the names on some that were figured
out). Fixed the master registration timing issue so that registrations
are attempted repeatedly until there is a reply, then keep-alives start.
