View page as slide show

CT30A6000 - COMMUNICATIONS SOFTWARE, PROTOCOLS AND ARCHITECTURE

Protocol

  • Protocol defines for datatransfer
    • rules
    • format
  • Protocol is designed for certain purpose
    • File transfer, Video transfer, email
  • The target area of protocol gives the requirements for protocol
    • reliability, efficiency, security …

General Protocol requirements

  • Protocol consists of several steps.
    • There is beginning and end for protocol
  • Protocol has to be unambiguous
    • Each step in protocol has to be defined
  • Protocol has to be complete
    • There has to be specific action for all possible situations.
  • All communicating participants has to know the protocol and follow it.

Protocol functions

Message handling

  • Segmentation and reassembly
    • dividing data to proper size for transmission
  • Encapsulation / framing
    • Creating the boundaries of message
  • Encoding/decoding
    • Combining data and metadata

reliable data transfer

  • connection control
    • connection-oriented communication: establishment, data transfer, termination
  • ordered delivery
    • maintaining PDU order
  • flow control
    • limiting the transmission to fit for receiver
  • Prioritizing
  • Error control

Governance and routing

  • Synchronization
  • Addressing
  • Routing
  • Multiplexing and demultiplexing
  • switching and forwarding

Special services

  • Security
  • application specific services

Asynchronous and synchronous communication

  • Synchronous communication
    • The processes involved in communication are required to participate at the point of communication simultaneously
    • If Process A attempts to send a message and Process B is not ready to receive it process A must wait until Process B is ready.
  • Asynchronous communication
    • the processes involved in communication are not required to participate at the point of communication simultaneously.
    • If Process A attempts to send a message and Process B is not ready to receive it sends it anyway.
    • Asynchronous communication requires the use of buffers to store messages
    • FIFO (First in first out) model used normally for message handling
  • This course focuses on asynchronous model

Connectionless protocols

  • Each message is handled individually and there is no relationship between messages
    • no states required
    • e.g. dropping letter to mailbox
  • Sender do not validate whether recipient is ready to accept messages
    • e.g. email, UDP or HTTP

Example protocol: HTTP 0.9

  • Messages from browser to server: GET
  • Messages from server to Browser: file
  • Messages from User to Browser: webpage_request
  • MSC

plain HTTP With user

  • Transition table for Server
input\state idle
GET send file
idle
  • Transition table for Browser
    • States idle, wf_rsp (Wait for response)
    • What would go to question marks?
input\state idle wf_rsp
webpage_request GET
wf_rsp
?
file ? show file
idle

Connection-oriented protocols

  • Recipient availability is validated prior sending data
    • e.g. phone call, your friend has to answer before you can start to talk to him
  • Messages are treated in the current context of connection rather than individually.
  • Requires rules for creation of connection and disconnection.
  • Requires connection identifier
  • Allows more complex systems
    • TCP or TLS

Client-Server communications

  • One of the communication partners act as client and one as server
    • Implementations and logic differ
  • Client application requests sources (e.g. Web browser or FTP client) from server application (web server or ftp server)
    • Data can be PULLed or PUSHed
  • Client initiates connection

Simple connection oriented data transfer

  • Lets have simple protocol where client connects to server and then sends data to it.
    • connection forming and closing is done in TCP style
  • MSC for data transfer
    • Three-way-handshake
    • free data transfer
    • Acknowledged connection closing
  • Messages:
    • SYN to create connection,
    • SYN+ACK and ACK for confirmation
    • DATA for data trasnfer
    • FIN for closing connection
  • Lets model the server FSM
    • Inputs: SYN, ACK, DATA, FIN
    • Outputs: SYN+ACK, ACK, FIN
  • If we look at the MSC we notice we have 4 different states. We can name them as follows
    • Idle: when we wait for someone to connect us
    • wf_ack: when we wait for acknowledgement for conenction creation
    • connected: when we wait data from client
    • wf_FINack: when we wait acknowledgement for our finished message
  • From MSC we can first draw MSC diagram and then create following transition table
input\state idle wf_ack connected wf_FINack
SYN SYN+ACK
wf_ack
? ? ?
ACK ? -
connected
? -
idle
DATA ? ? use DATA
connected
use DATA
wf_FINack
FIN ? ? ACK , FIN
wf_FINack
?
  • Lot of question marks in the transition table
    • Single MSC shows just shows one possible scenario of protocol behaviour
  • Since we have to have rule for every event, so we need to add behaviour in place of question marks.
  • We can state at this point that in case of question mark the incoming message is created due the error in client or network.
    • So we write error log and remain in the state
  • Our transition table would then look like:
input\state idle wf_ack connected wf_FINack
SYN SYN+ACK
wf_ack
log error
wf_ack
log error
connected
log error
wf_FINack
ACK log error
idle
-
connected
log error
connected
-
idle
DATA log error
idle
log error
wf_ack
use DATA
connected
use DATA
wf_FINack
FIN log error
idle
log error
wf_ack
ACK , FIN
wf_FINack
log error
wf_FINack
  • Or we can just say that our default behavior is log the message and remain in the given state
    • default behaviours can be defined globally or specifically for each state
input\state idle wf_ack connected wf_FINack
SYN SYN+ACK
wf_ack
default default default
ACK default -
connected
default -
idle
DATA default default use DATA
connected
use DATA
wf_FINack
FIN default default ACK , FIN
wf_FINack
default

Several connections

  • What if someone else wants to connect the server for data transfer while the previous connection is not closed?
    • According to the previous transition table, the SYN message would be just put in error log.
  • Forcing the second client to wait until first has finished solves the problem, but has problems
    • How do we know how long the first client will be connected?
    • What if first client forgets to close the connection?
    • What about applications where the clients actually interact with each other via server?
  • There is a need for a connection Manager and router

  • Manager creates new connection objects to handle each connection individually
  • Router looks at the incoming messages and decides which connection should handle it
    • Messages that are not belonging to any existing connection will be given to manager.
  • In previous case manager creates new connection object when SYN message arrives
  • Connection object uses the previously defined FSM
    • When connection is closed, connection object gets destroyed.
  • FSM for manager
    • Here we use default to define behaviour for all other messages than SYN
input\state idle
SYN Create new connection and give it SYN message
idle
default log error
idle

Client-Server based communication models

  • Request-reply (aka request-response)
    • Client requests data and server provides requested data
      • PULL technology (Client pulls data from server)
    • The most common model
    • Latency affects heavily
  • Publish-Subscribe
    • Client request subscription to server
    • Whenever there is new data, the server pushes it to subscribers
      • Server PUSH technology
    • Instant messaging, multicast
  • Broadcasting
    • Server sends data to clients without requests
      • Server PUSH
    • Can be intrusive and waste network resources

Peer-to-Peer communications

  • Same entity can act as client and server
    • Communicating partners are equal (may have same implementation)
    • Any entity can initiate the connection
  • No set roles for requests and replies
    • Anyone can request and provide data
Last modified: 2013/07/01 14:42