misc/possible_hub_states.txt

   1 Possible node-internal states
   2 =============================
   3
   4 These states are the node's own states and not a state of any other node, e.g.
   5 when you start the software, there is currently no state [instance], the
   6 node's state is 'null' (also null from $stateInstance is initially null).
   7
   8 ---------------+------------------------------------------------------+-------------
   9  Initial state | Reason of change                                     | New state
  10 ---------------+------------------------------------------------------+-------------
  11  Null          | Node application has been initialized                | Init
  12  Init          | Node has generated session id                        | Virgin
  13  Virgin        | Node has initialized all listeners, queues           | Active
  14  Active        | Node has reached itself from outside (self-connect)  | Reachable
  15  Active        | Node has attempted to announce itself to other nodes | Announced
  16  Reachable     |        -"-      -"-      -"-      -"-      -"-       | Announced
  17 ---------------+------------------------------------------------------+-------------
  18
  19 Possible states for a regular-node connection
  20 =============================================
  21
  22 This is a brief summary of possible states a regular-node connection may be
  23 setted. These ideas should later be implemented in a XML file with e.g. a
  24 StateXmlParser class with a XmlFileReader as a data source.
  25
  26 ---------------+------------------------------------------------------+-------------
  27  Initial state | Reason of change                                     | New state
  28 ---------------+------------------------------------------------------+-------------
  29 ---------------+------------------------------------------------------+-------------
  30
  31 A previous state is a non-fatal state that the node was before the "trouble"
  32 started. This state is stored along with a timestamp to watch the overall
  33 performance of this node reacting a troubleous node.
  34
  35 Karma lose or added karma is being remembered in a lose/add-seperated summary
  36 for "productive" and addionally as a full list for debugging purposes if the
  37 debug mode is enabled.
  38
  39 A "connection" should be interpreted as a incoming socket "connection". That
  40 means in this state table we threat UDP "connections" as same as TCP
  41 connections to make things easier. Of, course the script will be the last one
  42 to seperate between these very different protocols.
  43
  44 A "ping" is a small message that should be responded by a pinged node within a
  45 time period else the pinged node would loose some karma. When a "ping" is
  46 issued it should not be resend within a time period to not ping the node to
  47 death.
  48
  49 So pings are not issued while there is no trouble with the node. This does
  50 reduce network load for certain. Troubleous nodes are being detected by the
  51 above state changes (see Connected->Timed out for example).
  52
  53 Some state changes are no *real* state changes. They are sometimes remarks
  54 attached to the node connection. A good example is the state 'Karma lose' which
  55 a node does never change to.
  56
  57 A "list" should be interpreted as a DHT (Distributed Hash Table). All list and
  58 object transfers are being validated by final hashes for best reliablity.