The cor protocol - The layer 3 control layer

The first field is a 1 byte long "subprotocol" identifier. Allowed values are:

Neighbor discovery

Neighbor discovery is not documented yet, because it is still subject to change.
When discovery is completed, both peers will start sending pings to each other. At least one ping needs to be successful before data can be sent. When the connectivity is successful, pings should still be periodically sent in order to find out when a neighbor goes down.

Control message

Urgent and "normal" messages: Urgent messages are needed to detect whether the host on the other side is up. They are sent even if it is unknown whether the other host is up and responding correctly or not. Another difference is the behaviour when the retransmit queue is full: If this happens to normal messages, the new message will not be sent and error will be passed backwards until the error can be either recovered or shown to the user. If the urgent messages retransmit queue is full, old messages will be silenty discarded. This is because these old messages are not interesting after some time anyway and the new messages need to be sent.

Values in [] indicate the length of the field in bytes. Messages are not prefixed with a length field.

connection ids: Ids we receive with most significant bit 0 have been generated by us. Ids we receive with most significant bit 1 have been generated by the other side. The lower 31 bits are random bits generated when establishing the connection.

Ping

Requests a pong of the other side. This is sent periodically to detect the other host going down and to calculate the latency and packet loss of the connection.

Urgent: yes
Acked+retransmitted: no
Parameters:

Pong

The response to ping.

Urgent: yes
Acked+retransmitted: yes (so that the packet loss can be calculated for both directions independently)
Parameters:

Ack

Ack a control message packet; It needs to be send for every packet which contains at least one "acked+retransmitted" message.

Urgent: yes
Acked+retransmitted: no (would cause endless loops)
Parameters:

Ack conn

Ack a connection data chunk; When receiving user data either as a full packet or as part or via the "connection data" message this needs to be sent. It is also send to inform the other side of a changed window size, even if there has not been any traffic on this connection for a long time. Another use of this message is responding to the "ping conn" message.
By sending of this message confirms that the data has been received and will only be dropped in case the connection is reset.

Urgent: no
Acked+retransmitted: yes (in some cases data packets will not need to be retransmitted after lost acks)
Parameters:

Connect

Requests the establishing of a new connection. This command has to be answered with either "connect success" or "reset conn". This is sent when the command "connect to neighbor" is sent to the command interpreter. The receiving side of this command must not send any data through this connection until it has received data throught this command of the sender of this command.

Urgent: no
Acked+retransmitted: yes
Parameters:

Connect success

Connect success is sent after a connect request has been received and successfully processed. After this command is sent, the sender is ready to receive data.

Urgent: no
Acked+retransmitted: yes
Parameters:

Connection data

This command allows embedding connection data into a bigger packet which can contain other messages as well. This may help reduce overhead when many connections want to send small amounts of data or if a tiny signaling message would have to be sent otherwise. Data received through this message must be treated the same as data received via a dedicated packet.

Urgent: no
Acked+retransmitted: no (acked by Ack conn instead)
Parameters:

Reset conn

Close a connection; The connection will be closed in both directions without flushing out intransit data. When a connection is closed, every router must generate this message to all neighbors it has not received this message from, so that all routers along the path will know about the close.
This command may be initiated by either end of the connection when there is no more data to send. The layer 4 has to make sure that there is no user data in transit or else it will be lost. A connection may also be closed be an intermediate router, e.g. due to neighbor disconnect, ressource constraints or long idleness.

Urgent: no
Acked+retransmitted: yes
Parameters:

Set max control delay

When a message needs to be sent, it may be queued for some time in order to reduce the number of packets which need to be sent. This message tells the remote host the maximum delay so retransmit timing can be adjusted. The receiver must apply this message before sending an ack. The sender may not assume that this message has been applied before receiving the ack. A node should assume a delay of 1 second before receiving this message. This message should be sent after connecting to a new neighbor, so that the real delay will be known. The delay only applies to the messages ack,ack conn and ack conn ooo.

Urgent: no
Acked+retransmitted: yes
Parameters:

Data message

Contains data which should be passed to higher layers.