mirror of
https://gitlab.com/fabinfra/fabaccess/bffh.git
synced 2025-02-22 15:52:53 +01:00
Cleanup: remove /docs dir because we put it to https://docs.fab-access.org
This commit is contained in:
parent
c8f0337c1e
commit
fdde8a933c
@ -1,39 +0,0 @@
|
|||||||
strict digraph connection {
|
|
||||||
Establish [label="TCP/SCTP connection established"];
|
|
||||||
Closed [label="TCP/SCTP connection closed"];
|
|
||||||
Open;
|
|
||||||
SASL;
|
|
||||||
Authenticated;
|
|
||||||
STARTTLS;
|
|
||||||
Encrypted;
|
|
||||||
|
|
||||||
Establish -> Open [label=open];
|
|
||||||
|
|
||||||
Open -> Closed [label=close];
|
|
||||||
|
|
||||||
Open -> SASL [label=auth];
|
|
||||||
SASL -> SASL [label=step];
|
|
||||||
// Authentication fails
|
|
||||||
SASL -> Closed [label=fails];
|
|
||||||
// Authentication succeeds
|
|
||||||
SASL -> Authenticated [label=successful];
|
|
||||||
|
|
||||||
Open -> STARTTLS [label=starttls];
|
|
||||||
// TLS wrapping succeeds
|
|
||||||
STARTTLS -> Encrypted [label=successful];
|
|
||||||
// TLS wrapping fails
|
|
||||||
STARTTLS -> Closed [label=fails];
|
|
||||||
|
|
||||||
Authenticated -> SASL_TLS [label=starttls];
|
|
||||||
SASL_TLS -> Closed [label=fails];
|
|
||||||
SASL_TLS -> AuthEnc [label=successful];
|
|
||||||
|
|
||||||
Encrypted -> TLS_SASL [label=auth];
|
|
||||||
TLS_SASL -> TLS_SASL [label=step];
|
|
||||||
TLS_SASL -> Closed [label=fails];
|
|
||||||
TLS_SASL -> AuthEnc [label=successful];
|
|
||||||
|
|
||||||
// Only authenticated connections may open RPC. For "unauth", use the `Anonymous` SASL method.
|
|
||||||
AuthEnc -> RPC [label=bootstrap];
|
|
||||||
Authenticated -> RPC [label=bootstrap];
|
|
||||||
}
|
|
@ -1,42 +0,0 @@
|
|||||||
# Stream initiation
|
|
||||||
|
|
||||||
In a session there are two parties: The initiating entity and the receiving
|
|
||||||
entity. This terminology does not refer to information flow but rather to the
|
|
||||||
side opening a connection respectively the one listening for connection
|
|
||||||
attempts.
|
|
||||||
In the currently envisioned use-case the initiating entity is a) a client
|
|
||||||
(i.e. interactive or batch/automated program) trying to interact in some way or
|
|
||||||
other with a server b) a server trying to exchange / request information
|
|
||||||
with/from another server (i.e. federating). The receiving entity however is
|
|
||||||
already a server.
|
|
||||||
|
|
||||||
Additionally the amount and type of clients is likely to be more diverse and
|
|
||||||
less up to date than the servers.
|
|
||||||
Conclusions I draw from this:
|
|
||||||
- Clients are more likely to implement an outdated version of the communication
|
|
||||||
protocol.
|
|
||||||
- The place for backwards-compatability should be the servers.
|
|
||||||
- Thus the client (initiating entity) should send the expected API version
|
|
||||||
first, the server then using that as a basis to decide with which API
|
|
||||||
version to answer.
|
|
||||||
|
|
||||||
# Stream negotiation
|
|
||||||
|
|
||||||
Since the receiving entity for a connection is responsible for the machines it
|
|
||||||
controls it imposes conditions for connecting either as client or as federating
|
|
||||||
server. At least every initiating entity is required to authenticate itself to
|
|
||||||
the receiving entity before attempting further actions or requesting
|
|
||||||
information. But a receiving entity can require other features, such as
|
|
||||||
transport layer encryption.
|
|
||||||
To this end a receiving entity informs the initiating entity about features that
|
|
||||||
it requires from the initiating entity before taking any further action and
|
|
||||||
features that are voluntary to negotiate but may improve qualities of the stream
|
|
||||||
(such as message compression)
|
|
||||||
|
|
||||||
A varying set of conditions implies negotiation needs to take place. Since
|
|
||||||
features potentially require a strict order (e.g. Encryption before
|
|
||||||
Authentication) negotiation has to be a multi-stage process. Further
|
|
||||||
restrictions are imposed because some features may only be offered after others
|
|
||||||
have been established (e.g. SASL authentication only becoming available after
|
|
||||||
encryption, EXTERNAL mechanism only being available to local sockets or
|
|
||||||
connections providing a certificate)
|
|
@ -1,93 +0,0 @@
|
|||||||
strict digraph state {
|
|
||||||
rank = 0
|
|
||||||
subgraph "cluster_internal_state" {
|
|
||||||
rank = 1
|
|
||||||
ctr = applied
|
|
||||||
start
|
|
||||||
[shape=doublecircle, label="BFFH"]
|
|
||||||
created
|
|
||||||
[label="Machine object created"];
|
|
||||||
start -> created;
|
|
||||||
|
|
||||||
created -> attach
|
|
||||||
[label="New state or loaded from disk"];
|
|
||||||
|
|
||||||
attach
|
|
||||||
[label="Attach actor", shape=box];
|
|
||||||
|
|
||||||
unapplied
|
|
||||||
[label="Unapplied"];
|
|
||||||
applied
|
|
||||||
[label="Applied"];
|
|
||||||
verified
|
|
||||||
[label="Verified"];
|
|
||||||
|
|
||||||
wait_apply
|
|
||||||
[label="Wait ∀ Actors", shape=box]
|
|
||||||
wait_verify
|
|
||||||
[label="Wait ∀ Actors", shape=box]
|
|
||||||
|
|
||||||
unapplied -> wait_apply -> applied;
|
|
||||||
applied -> wait_verify -> verified;
|
|
||||||
|
|
||||||
applied -> unapplied
|
|
||||||
[label="statechange received"];
|
|
||||||
verified -> unapplied
|
|
||||||
[label="statechange received"];
|
|
||||||
unapplied -> unapplied
|
|
||||||
[label="statechange received"];
|
|
||||||
|
|
||||||
unapplied -> attach -> unapplied;
|
|
||||||
applied -> attach -> unapplied;
|
|
||||||
verified -> attach -> unapplied;
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
subgraph "cluster_actor" {
|
|
||||||
rank = 1
|
|
||||||
center = actor_applied
|
|
||||||
actor_start
|
|
||||||
[shape=doublecircle, label="Actor"];
|
|
||||||
actor_fresh
|
|
||||||
[label="Actor was just constructed"];
|
|
||||||
actor_start -> actor_fresh;
|
|
||||||
|
|
||||||
actor_attached
|
|
||||||
[label="Attached"];
|
|
||||||
actor_unapplied
|
|
||||||
[label="Unapplied"];
|
|
||||||
actor_applied
|
|
||||||
[label="Applied"];
|
|
||||||
actor_verified
|
|
||||||
[label="Verified"];
|
|
||||||
|
|
||||||
wait_initial
|
|
||||||
[label="Recv", shape=box];
|
|
||||||
wait_state
|
|
||||||
[label="Recv", shape=box];
|
|
||||||
|
|
||||||
actor_fresh -> wait_initial -> actor_attached;
|
|
||||||
|
|
||||||
actor_attached -> actor_applied
|
|
||||||
[label="initialize/apply"];
|
|
||||||
actor_unapplied -> actor_applied
|
|
||||||
[label="apply"];
|
|
||||||
actor_applied -> actor_verified
|
|
||||||
[label="verify"];
|
|
||||||
|
|
||||||
actor_unapplied -> wait_state;
|
|
||||||
actor_applied -> wait_state;
|
|
||||||
actor_verified -> wait_state;
|
|
||||||
|
|
||||||
wait_state -> actor_unapplied;
|
|
||||||
}
|
|
||||||
|
|
||||||
attach -> wait_initial
|
|
||||||
[label="Send initial state to that actor", style=dotted]
|
|
||||||
unapplied -> wait_state
|
|
||||||
[label="Send new state to all actors", style=dotted];
|
|
||||||
actor_applied -> wait_apply
|
|
||||||
[label="Confirm apply", style=dotted];
|
|
||||||
actor_verified -> wait_verify
|
|
||||||
[label="Confirm verify", style=dotted];
|
|
||||||
}
|
|
Loading…
x
Reference in New Issue
Block a user