(c

)D
an
Designing
C a Protocol
os
m
a
(c
)
1. Choose the patterns of communication and data
transmission Da
2. Establish the design ngoals
Co “philosophy”
3. Choose the message format
sm format, fields, types
4. Design the message structure:
of messages, etc. a
5. Design the communication rules (sequences)
(c
Steps 4 and 5 go together )
Da
n
Co
1
s m
a
 (c
)D
an
Patterns
C of communication
os
m
a
(c
• Client - server )
Dacommunication,
one party initiates the
the other responds n
Co
sm
a
• Peer-to-peer
any party may initiate the
communication (c
)
Da
n
Co
s
See Robin Sharp, Principles of protocol design, Springer,
2 2008

m
a
 (c
)D
an
Patterns
C of communication
os
m
a

•
(c)
Hierarchical communication
Da in a
many parties, organized
n only
hierarchy, and communicate Peer
Co
via the branches of the tree
sm Peer Peer

a
Peer Peer

(c
Peer
) Peer

Da
n Peer

Co
s
See Robin Sharp, Principles of protocol design, Springer,
3 2008

m
a
 (c
)D
an
Patterns
C of transmissions
os
m
a
• One-to-one
(c
only two parties involved in communication at a time
)
• Multicast Da
n
one or more parties may transmit data to multiple parties at a
time
Co
• Broadcast sdata to all parties at the
one or more parties may transmit m
same time a

(c at different
Each or all of these patterns may be used
)
stages in the communication D an
Co
4
s m
a
 (c
)D
an
DesignC Goals
os
m
a
• Define the framework for communication
- Should the communication be fast?
(c
)
- Do we need reliable exchanges? (E.g. confirmations and such)
Da
- How important is the authentication of parties?
- Is the transferred data confidential? What degree of authorization is
needed? n
Co
- How many types of parties are involved? Can they all communicate to
each other? sm
a
- Are there bandwidth or connection availability limitations?
- Do we need to maintain communication channels? Are
connectionless models more suitable, instead?
- Do we need complex error handling?
- ... (c
)
Da
n
Co
5
sm
a
 (c
)D
an
DesignC Goals
os
m
a
• A communication protocol should be:
- simple
(c
)
~ don’t make easy tasks hard to do
Da
~ don’t provide two ways for doing the same thing
- scalable
n
~ estimate the number of clients per server (or peers communicating)
Co
~ design the protocol so that it balances the responsibilities (e.g.
sm
shifts the communication balance to the clients, to free the servers
which are already full of responsibilities)
- efficient
~ minimize the command overhead
a
~ minimize the data traffic

(c
- extensible

)
~ make room for further extensions

Da
~ don’t overdo it, though

n
Co
6
s m
a
 (c
)D
an
Message
C formats
os
m
a
(c
• Two approaches:
)
Da
n protocols
- Text-orientedCo
- Protocols usingsmbinary messages
a

(c
)
Da
n
Co
7
sm
a
 (c
)D
an
Text-Oriented
C os
m
•
a
All messages are readable character strings
• Advantages
- human readable,
(c) easy to understand and monitor
Da (if properly designed)
- flexible, easy to extend
- easy to test, even withn‘‘standard’’ clients (telnet?)
• Disadvantages Co
smby unauthorized persons
- human readable, easy to read
(without encryption) a
- may become complex, harder to parse in code
- may make the messages unjustifiably large
(c
)
Da
n
Co
8
sm
a
 (c
)D
an
BinaryC messages
os
m
a
• Messages are blocks of structured binary data
(c
• Advantages
)
D
- Better ways of structuring the data
an data transfers
- Suitable for large or complex
Co
- Messages are as small as possible
• Disadvantages s
- Hard to read, debug or test m
a
- Need to consider the data representation conventions on
hosts and network (e.g. the “endianness”: little-endian vs.
big-endian)
(c
)
Da
n
Co
9
sm
a
 (c
)D
an
Designing
C the Message
os
m
a
(c
• A very important aspect in protocol
design )
Da
• Influences all then characteristics of the
Co
communication: scalability,
sm efficiency,
simplicity, extensibilitya
• The design involves two aspects:
a) types of messages (c
b) message structure )
Da
n
Co
10
sm
a
 (c
)D
an
Types Cof Messages
os
m
a
• One message type for each distinct aspect of the
communication
(c
)
Da
• Three categories of messages:
- commands
n
- data transfer
- control Co
sm
Each category may include severalamessage types

(c
)
Da
n
Co
11
sm
a
 (c
)D
an
Command
C Messages
os
m
a
• Define the stages of the dialogue between the parties
(c)
• Address various communication aspects:
Da or ending
- communication initiation
n
- describe the communication stage (e.g. authentication, status
request, data transfer) Co
- status changes (e.g. requests
transfer mode)
sfor switching to the data
m
a new communication
- resource changes (e.g. requests for
channels)
- ...
(c
)
Da
n
Co
12
sm
a
 (c
)D
an
Data transfer
C os
m
a
• Messages that carry data over the network
• They are usually(csent as a responses to specific commands
)
D in multiple messages
• Data is usually fragmented
an
•
C
Besides the actual data, may describe:
- the type of the binary data oformat
sm data (when the
- clues for the layout of the structured
structure is flexible/dynamic) a
- data size, offset or sequence information
- type of the data block: last / intermediary
(c
)
Da
n
Co
13
sm
a
 (c
)D
an
Control
C Messagesos
m
a
(c
• Control the dialogue between the parties
)
•
Da confirmation, retry requests)
Address various communication
- coordination (e.g. receipt
aspects:

n
- cancellation or interruption
- availability checks Co
- ... sm
a

(c
)
Da
n
Co
14
s m
a
 (c
)D
an
Message
C Structure
os
m
• Header: a
contains structured fields
describing the actual data in the
message: (c
- message type )
- command Da Header
- body size n
- recipient information C
os
- sequence information
m
- retransmission count a
- etc. Body
• Body: the actual data to be
(c
transmitted:
)
- the command parameters
- the data payload
Da
n
Co
15
sm
a
 (c
)D
an
Message
C Structure
os
m
a
• The header structure must be well-
(c
known by the receiving party
)
cmd

D
• The header may contain clues Header
no-of-params
helping the recipient toaunderstand parameter-size
the rest of the message n
Cothe
and the
details regarding the data in
body (e.g. size, data format orsm
encryption, etc.) a
• Headers usually have a fixed size,
Body
while the body size may be
(c
variable (within limits)
)
Da
n
Co
16
sm
a
 (c
)D
an
Communication
C Rules
os
m
a
(c
• Along with the messages, this is the other essential part
of the protocol )
Da
• Describe the sequences nof commands, data and control
Costages in the
messages, at each and all the
sm
communication, for all parties in the system
• a
Should be clearly and thoroughly specified, through
detailed descriptions of each communication scenario
(for each possible case of peer interaction)
(c
)
Da
n
Co
17
sm
a
 (c
)D
an
Communication
C Rules
os
m
a
Client Server
(c
)
D
Sequence diagrams are CONNECT param1 param 2

more than useful... a

n RESPONSE param1

Co REQ param1 param2 param3

sm DATA data-body

a ACK data

END param1 param 2

OK
(c
)
Da
n
An imaginary diagram for a non-existent protocol

Co
18
sm
a
 (c
)D
an
Communication
C Rules
os
m
a
(c)
...but state diagrams
are almost mandatory Da the DATA command:

n
Co
+---+ DATA +---+ 1,2 +---+
| B |---------->| W |-------------------->| E |
"success"(S), "failure" (F), and "error" (E). +---+ +---+ ------------>+---+

sm
3| |4,5 |
1,3 +---+ | | |
----------->| E | -------------- ----- |

a
| +---+ | | | +---+
| | ---------- -------->| S |
+---+ cmd +---+ 2 +---+ | | | | +---+
| B |---------->| W |---------->| S | | | ------------
+---+ +---+ +---+ | | | |
| V 1,3| |2 |

(c
| 4,5 +---+ +---+ data +---+ --------------->+---+
----------->| F | | |---------->| W | | F |

)
+---+ +---+ +---+-------------------->+---+

State diagrams from the SMTP specification (1982)

Da
n
[source: RFC 821]

Co
19
s m
a
 (c
)D
an
Documenting
C the Design
os
m
a
(c
• The protocol specification must be available for all interested
)
parties, as a specific document
Da
• The specification must be
n
- clear, easy to understand
- comprehensive (complete) Co
- non-ambiguous sm
a
- maintainable (for versioning and such)

By only having the specification, parties must be able to

(c
thoroughly implement the software components involved in
communication
)
Da
n
Co
20
s m
a
 (c
)D
an
Specification
C Content
os
m
•
a
Introduction
- purpose of the protocol, domain, environment, prerequisites
(c
• The communication model
)
Da
- parties involved, relations, roles, general description of the dialogue
flow between components, etc.
n
• Communication steps or procedures
Co or aspect of communication
- description of each stage, procedure
sm
a (commands, headers,
• Message description
- syntax and semantics for all types of messages
codes, etc.)

(c
• Sequence of commands and replies

)
- the detailed description of the communication rules, including state

Da
diagrams, sequence diagrams, and comprehensive explanations for
the procedures
n
Co
21
s m
a