Scribd
Upload
1 views9 pages

Protocol Design

Uploaded by

osarienjoseph
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
1 views9 pages

Protocol Design

Uploaded by

osarienjoseph
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

PROTOCOL DESIGN

The Internet Protocol (IP) is a collection of rules that allow data packets to be
routed and addressed to pass through networks and reach the correct destinations.
Modern internet runs on effectively on IP.
The following steps can be used to design a protocol;
1. Choose the patterns of communication and data transmission
2. Establish the design goals
3. Choose the message format “philosophy”
4. Design the message structure: format, fields, types of messages, etc.
5. Design the communication rules (sequences)
Steps 4 and 5 go together

Stage 1a: Patterns of Communication


Client - server
One party initiates the communication, the other responds.

Peer-to-peer
Any party may initiate the communication (Figure A).

Hierarchical communication
many parties, organized in a hierarchy, and communicate only via the branches of
the tree (Figure B).

Figure B
Figure A
Stage 1b: Patterns of transmissions
• One-to-one
Only two parties involved in communication at a time.
• Multicast
One or more parties may transmit data to multiple parties at a time
• Broadcast
One or more parties may transmit data to all parties at the same time

Each or all of these patterns may be used at different stages in the communication

Stage 2: Design Goals


• Define the framework for communication
- Should the communication be fast?
- Do we need reliable exchanges? (E.g. confirmations and such)
- How important is the authentication of parties?
- Is the transferred data confidential? What degree of authorization is needed?
- How many types of parties are involved? Can they all communicate to each
other?
- 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?

Also, a communication protocol should be:


- simple
~ don’t make easy tasks hard to do
~ don’t provide two ways for doing the same thing
- scalable
~ estimate the number of clients per server (or peers communicating)
~ design the protocol so that it balances the responsibilities (e.g. shifts the
communication balance to the clients, to free the servers which are already full of
responsibilities)
- efficient
~ minimize the command overhead
~ minimize the data traffic
- extensible
~ make room for further extensions
~ don’t overdo it, though

Stage 3: Message formats


There are two approaches:
- Text-oriented protocols
- Protocols using binary messages

Text-Oriented
All messages are readable character strings
Advantages
- human readable, easy to understand and monitor
- flexible, easy to extend (if properly designed)
- easy to test, even with ‘‘standard’’ clients (telnet?)
Disadvantages
- human readable, easy to read by unauthorized persons
(without encryption)
- may become complex, harder to parse in code
- may make the messages unjustifiably large

Binary messages
Messages are blocks of structured binary data
Advantages
- Better ways of structuring the data
- Suitable for large or complex data transfers
- Messages are as small as possible
Disadvantages
- Hard to read, debug or test
- Need to consider the data representation conventions on hosts and network (e.g.
the “endianness”: little-endian vs. big-endian)

Stage 4: Designing the Message


• A very important aspect in protocol design
• Influences all the characteristics of the communication: scalability, efficiency,
simplicity, extensibility
• The design involves two aspects:
a) types of messages
b) message structure

Types of Messages
• One message type for each distinct aspect of the
communication
• Three categories of messages:
- commands
- data transfer
- control
Each category may include several message types;

Command Messages
• Define the stages of the dialogue between the parties
• Address various communication aspects:
- communication initiation or ending
- describe the communication stage (e.g. authentication, status request, data
transfer)
- status changes (e.g. requests for switching to the data transfer mode)
- resource changes (e.g. requests for new communication channels)

Data transfer
• Messages that carry data over the network
• They are usually sent as a responses to specific commands
• Data is usually fragmented in multiple messages
• Besides the actual data, may describe:
- the type of the binary data format
- clues for the layout of the structured data (when the structure is flexible/dynamic)
- data size, offset or sequence information
- type of the data block: last / intermediary

Control Messages
• Control the dialogue between the parties
• Address various communication aspects:
- coordination (e.g. receipt confirmation, retry requests)
- cancellation or interruption
- availability checks

Message Structure
• Header: contains structured fields describing the actual data in the message:
- message type
- command
- body size
- recipient information
- sequence information
- retransmission count etc.
• Body: the actual data to be transmitted:
- the command parameters
- the data payload

Note:
• The header structure must be well-known by the receiving party
• The header may contain clues helping the recipient to understand the rest of the
message and the details regarding the data in the body (e.g. size, data format or
encryption, etc.)
• Headers usually have a fixed size, while the body size may be variable (within
limits)

Stage 5: Communication Rules


• Along with the messages, this is the other essential part of the protocol
• Describe the sequences of commands, data and control messages, at each and all
the stages in the communication, for all parties in the system
• Should be clearly and thoroughly specified, through detailed descriptions of each
communication scenario (for each possible case of peer interaction)

Final Stage: Documenting the Design


• The protocol specification must be available for all interested parties, as a
specific document
• The specification must be
- clear, easy to understand
- comprehensive (complete)
- non-ambiguous
- maintainable (for versioning and such)
By only having the specification, parties must be able to thoroughly implement the
software components involved in communication

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy