misc/possible_hub_states.txt

   1 Possible States For A Hub Connection
   2 ====================================
   3
   4 This is a brief summary of possible states a hub connection may be setted.
   5 These ideas should later be implemented ina XML file with e.g. a StateXmlParser
   6 class with a XmlFileReader as a data source.
   7
   8 -------------------------------------------------------------------------------
   9  Initial state | Reason of change                            | New state
  10 -------------------------------------------------------------------------------
  11  New peer      | Appears as a simple connection              | Connected
  12  Connected     | Has dropped the connection                  | Disconnected
  13  Connected     | Does not do anything within a timeout       | Timed out
  14  Disconnected  | Is purged from the connection list          | Removed
  15  Timed out     | Is being pinged                             | Pinged
  16  Pinged        | Does not response on a ping                 | No response
  17  Pinged        | Does reply slowly on a ping                 | Slowed down
  18  Pinged        | Does reply fast on a ping                   | <prev. state>
  19  No response   | Does still not response on X pings          | Lost connection
  20  No response   | Does reply on a ping                        | Slowed down
  21  Slowed down   | Does not response on a ping                 | No response
  22  Slowed down   | Does still response slow on X extra pings   | Karma lose
  23  Slowed down   | Does reply faster on a ping                 | <prev. state>
  24  Lost connect. | Is maybe disconnected/crashed/etc.          | Disconnected
  25  Karma lose    | Has lost some karma                         | <prev. state>
  26 -------------------------------------------------------------------------------
  27
  28 A previous state is a non-fatal state that the peer was before the trouble
  29 started. This state is stored along with a timestamp to watch the overall
  30 performance of this hub reacting a troubleous peer.
  31
  32 Karma lose is being remembered in a summary for "productive" and addionally as
  33 a full list for debugging purposes.
  34
  35 A "connection" should be interpreted as a incoming socket "connection". That
  36 means in this state table we threat UDP "connections" as same as TCP
  37 connections to make things easier.
  38
  39 A "ping" is a small message that should be responded by a pinged peer within a
  40 time else the ping would loose some karma. When a "ping" is issued it should not
  41 be resend within a time period to not ping the peer to death.
  42
  43 So pings are not issued while there is no trouble with the peer. This does
  44 reduce network load for certain. Troubleous peers are being detected by the
  45 above state changes (see Connected->Timed out for example).
  46
  47 Some state changes are no *real* state changes. They are sometimes remarks
  48 attached to the peer connection. A good example is the state 'Karma lose' which
  49 a peer does never change to.