| 2 |
- |
1 |
Coraid Ethernet Console (cec)
|
|
|
2 |
|
|
|
3 |
Abstract
|
|
|
4 |
|
|
|
5 |
The Coraid Ethernet Console (cec) implements a bidirectional conversation
|
|
|
6 |
over raw ethernet frames with provisions for retransmission and discovery.
|
|
|
7 |
Like serial consoles, each machine has a single shared interface per service
|
|
|
8 |
type, but any number connections can be made from any machine connected to
|
|
|
9 |
the same physical network. The communications from the various connections
|
|
|
10 |
will be interleaved. The first implementation of cec is for console communications
|
|
|
11 |
to Coraid appliances.
|
|
|
12 |
|
|
|
13 |
Outline
|
|
|
14 |
|
|
|
15 |
1. Packet format
|
|
|
16 |
2. The Tdiscover packet and Toffer reply.
|
|
|
17 |
3. Initializing a connection. Tinit[abc]
|
|
|
18 |
4. The connection. Tdata and Tack
|
|
|
19 |
5. Closing the connection. Treset
|
|
|
20 |
|
|
|
21 |
1. Packet Format
|
|
|
22 |
|
|
|
23 |
All cec packets are follow the layout implied by the following structure
|
|
|
24 |
|
|
|
25 |
struct Pkt {
|
|
|
26 |
uchar dst[6]; // destination ethernet address
|
|
|
27 |
uchar src[6]; // source ethernet address
|
|
|
28 |
uchar etype[2]; // service type
|
|
|
29 |
uchar type; // type of packet.
|
|
|
30 |
uchar conn; // unique connection id.
|
|
|
31 |
uchar seq; // packet sequence number
|
|
|
32 |
uchar len; // data length.
|
|
|
33 |
uchar data[1500];
|
|
|
34 |
};
|
|
|
35 |
|
|
|
36 |
The packet types are as follows:
|
|
|
37 |
|
|
|
38 |
enum {
|
|
|
39 |
Tinita,
|
|
|
40 |
Tinitb,
|
|
|
41 |
Tinitc,
|
|
|
42 |
Tdata,
|
|
|
43 |
Tack,
|
|
|
44 |
Tdiscover,
|
|
|
45 |
Toffer,
|
|
|
46 |
Treset,
|
|
|
47 |
};
|
|
|
48 |
|
|
|
49 |
2. The Tdiscover packet and Toffer reply.
|
|
|
50 |
|
|
|
51 |
The Tdiscover packet is used to discover the avaliable cec devices on the local
|
|
|
52 |
network. The packet sent is of the form
|
|
|
53 |
|
|
|
54 |
Tdiscover = {
|
|
|
55 |
[dest] 0xffffffff,
|
|
|
56 |
[src] mac of local interface,
|
|
|
57 |
[etype] service type,
|
|
|
58 |
[type] Tdiscover,
|
|
|
59 |
[seq] 0,
|
|
|
60 |
[len] 0,
|
|
|
61 |
[data] 0,
|
|
|
62 |
}
|
|
|
63 |
|
|
|
64 |
The reply to the Tdiscover packet is of type Toffer which differes from
|
|
|
65 |
Tdiscover in that data and len may be set. The contents of data is application
|
|
|
66 |
specific.
|
|
|
67 |
|
|
|
68 |
3. Initializing a connection. Tinit[abc]
|
|
|
69 |
|
|
|
70 |
A connection is initialized by the following conversation: In addition
|
|
|
71 |
to the fields set for the Tdiscover packet, the client sends a packet
|
|
|
72 |
of type Tinita with the conntag of its choice. The server responds to
|
|
|
73 |
Tinita with a packet of type Tinitb. And finally the client sents a
|
|
|
74 |
Tinitc packet back to the server, completing the connection.
|
|
|
75 |
|
|
|
76 |
4. The connection. Tdata and Tack
|
|
|
77 |
|
|
|
78 |
Data is sent from the client to the console server with the Tdata packet.
|
|
|
79 |
The seq field is incremented for each data packet sent. Thus data packets
|
|
|
80 |
may be transmitted if lost. The data is whatever data the client has to
|
|
|
81 |
send to the server, up to 255 bytes. Typically, however, each keystroke
|
|
|
82 |
is sent in a seperate packet. The len field is the length of the
|
|
|
83 |
data.
|
|
|
84 |
|
|
|
85 |
The server responds to a Tdata message with a Tack message with the
|
|
|
86 |
same seq sequence number.
|
|
|
87 |
|
|
|
88 |
5. Closing the connection. Treset
|
|
|
89 |
|
|
|
90 |
Either the server of the client may send a Treset message to close the
|
|
|
91 |
connection. There is no response to a Treset message, however any
|
|
|
92 |
information associated with that connection (conntag) is discarded
|
|
|
93 |
when the Treset message is recieved.
|