1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
//! Beyond the pure running of machines, a structure should be imposed upon them, allowing for interaction.
//! Many different organizational structures exist, which could be utilzed. This is one of them, it is a
//! Component, Connector model with a Coordinator Component providing orchestration. Although this is the
//! model being discussed there is no requirement that it be the only model used. It is one I happen to
//! like and provides some nice characteristics.
//!
//! The primary benefit of this model is that it reduces most things down to a wiring problem, which
//! works nicely if you can accomplish everything by wiring senders together. The other benefit is
//! the incredibly small API which needs to be exposed. Ideally, it consists of a configure per
//! component.
//!
//! There are two examples provided, that illustrate this:
//! * A chat server, which allows all joiners to chat with each other via TCP.
//! * An echo server, which echos back anything sent to it.
//!
//! Components may interact with the network as well as other components. They are factories for
//! connections. Connections are the work-horses of machines. They may spawn additional machines
//! as part of their function. They provide scaling of the server. The Coordinator is a Component
//! with some added responsiblities. It is responsible for wiring Connectors together in a meaningful
//! manner.
//!
//! Taken together, this model can be used for implementing a simple echo server all the way up to a
//! more complex conference server, which would include audio, video, recording and translating services.
extern crate smart_default;
extern crate serde_derive;
use Arc;
use thread;
use Duration;
use AtomicRefCell;
use AtomicCell;
use channel;
use *;
use *;
use send_cmd;
use *;
use ;
use ;