Clarification of link life cycle

[alanz]

Does the following correctly capture the life cycle of a link?

First establish line A<->B via direct open or seek/peer

• link A->B to establish unidirectional link
• possible path optimization process (async)
• send keepalive every link-ping seconds (30 atm)
• If no rx within link-timeout seconds (60 atm) go into first fail mode
• resend original open (with original timestamp) on all known paths (and as a peer message to the original seed if it is still alive)
• if line not reestablished within link-timeout secs go into second fail mode
• send new on all known paths (and as a peer message to the original seed if it is still alive)
• if line not reestablished within link-timeout secs go into fully failed mode
• If connection still desired, restart seek process

[alanz]

More thoughts on this process. Comments please

Link state machine

States
------

IDLE          : not linked
LINK_RX_WAIT  : their link up, waiting for ours
LINK_TX_WAIT  : waiting for our link to come up
LINK_TX_WAIT2 : ours up, waiting for theirs
LINKED        : both up
FAIL1         : ping missed, re-open original
FAIL2         : ping missed, re-open new

Transitions
------------

State         event         action(s)         next

-- remote initiated
IDLE          link_rx       tx_link,tx_ack LINK_RX_WAIT

LINK_RX_WAIT  link_rx       tx_link,tx_ack LINK_RX_WAIT
LINK_RX_WAIT  link_ack       -             LINKED
LINK_RX_WAIT  ack_timeout   tx_end         IDLE
LINK_RX_WAIT  link_cmd      tx_link        LINK_RX_WAIT
LINK_RX_WAIT  ping_rx       tx_ping_ack    LINK_RX_WAIT
LINK_RX_WAIT  end_rx        tx_end         IDLE
LINK_RX_WAIT  err_rx        tx_end         IDLE

-- own initiated
IDLE          link cmd      tx_link        LINK_TX_WAIT

LINK_TX_WAIT  link_ack       -             LINK_TX_WAIT2
LINK_TX_WAIT  ack_timeout    -             IDLE
LINK_TX_WAIT  link_rx       tx_ack         LINK_RX_WAIT
LINK_TX_WAIT  end_rx        tx_end         IDLE
LINK_TX_WAIT  err_rx        tx_end         IDLE

LINK_TX_WAIT2 link_rx       tx_ack         LINKED
LINK_TX_WAIT2 timer         tx_ping        LINK_TX_WAIT2
LINK_TX_WAIT2 ping_timeout  tx_end         IDLE
LINK_TX_WAIT2 end_rx        tx_end         IDLE
LINK_TX_WAIT2 err_rx        tx_end         IDLE

-- maintenance [essentially two parallel state machines]
LINKED        timer         tx_ping        LINKED
LINKED        ping_timeout  tx_end,reopen  FAIL1
LINKED        ping_rx       tx_ping_ack    LINKED
LINKED        end_rx        tx_end         IDLE
LINKED        err_rx        tx_end         IDLE

-- failure/retry process
FAIL1         open_timeout  reopen2        FAIL2
FAIL1         link_ack      -              LINK_TX_WAIT2
FAIL1         link_rx       tx_link,tx_ack LINK_RX_WAIT

FAIL2         open_timeout  seek           LINK_TX_WAIT

Events
------
link_rx : link message received from remote

link_ack : positive response received from remote to our link message

ack_timout : no response received from remote to our link message
             within designated time

link_cmd : we choose to send a link message

timer : periodic (29sec) event, used to initiate ping messages

ping_rx : keepalive received from remote

ping_timeout : no response received from remote to our ping message
             within designated time

end_rx : message received from remote with end set

err_rx : message received from remote with err set
         [Note: could also mean underlying channel failure]

open_timeout : no response to open message within timeout

Actions
--------
tx_link : send link message to remote
tx_ack  : send link ack message to remote
tx_end  : send end message to remote
tx_ping : send keepalive message to remote
tx_err  : will not be sent by this state machine, but may be sent by lower layers
reopen  : resend original OPEN message on all known paths to remote, as
          well as original peer to original seed, queue tx_link for when open
reopen2 : send new OPEN message on all known paths to remote, as
          well as original peer to original seed, queue tx_link for when open
seek:   : throw away all knowlede of the remote and start the connection
          process from the beginning, queue tx_link for when open

[quartzjer]

While the link semantics have changed with v3 and it documents some of the state, there are still things that need to be clarified, putting this on the list for the v3 milestone.

[quartzjer]

I'm going to close this as the link logic in v3 is now being combined with the handshake in #110 which has a different state engine that was being discussed here.

@alanz if you're interested in helping make sure the e3x exchange handshake state table is clearly mapped out, just ping me via chat/email if you have any questions :)