Communication software and architecture

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

• 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

• 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

• Modern communication system consists of several tasks
  • e.g. web browsing requires among other things: routing, name to address conversion, channel securing etc.
  • To ease the creation of communication application, different functions required for efficient communication are separated
  • Each service should be defined in it's own protocol specification
• Communication architecture defines the interoperability and relation of two or more protocols

• Lets think what are the needs for fetching webpage from webserver
  • Rules to define the file we want to get
  • Rules for defining the server we want the file from
    • Routing the message through network to correct server
  • Rules for de/encoding of the bits to electromagnetic waves.
  • Detection and correction of transmission errors

• Hard to accomplish with a single protocol
  • All the CPOs participating in communication should follow the protocol.
    • Why would application in router care how the file can be found from webserver?
    • Why should web browser developer care about Internet routing issues?
  • Use of multiple protocols to handle specific problems is needed
    • Multiple protocols are commonly put in layered architecture

• Different communication tasks are separated on their own layers
  • Protocol stack
• Each layer has its own tasks and own protocol
  • Entities at same layer (layer N) are called peer entities
  • Connection between peer entities is peer connection following peer protocol
  • Implementation of entity is CPO (communicating protocol object)
• Lower layer provides a service to higher layer
  • IP provides routing service to TCP that provides reliable communication channel to application
  • Implementation details of lower layer do not affect on higher layer implementation

• OSI model is just a reference model
  • The entire protocol stack based on OSI is not in use
  • On discussions protocols are commonly located within OSI reference model e.g. TCP is in Transport layer and IP in Network layer
• Different solutions have their own layered architectures
  • TCP/IP, Bluetooth, IRDA …

from http://www.linux.org/docs/ldp/howto/Infrared-HOWTO/images/irda_stack.jpg

From http://developers.sun.com/mobility/midp/articles/bluetooth1/fig2.gif

• Horizontal communication (protocol)
  • Communication of peer entities. Peer entities form virtual channel between each other
  • Communication between peer entities are conducted with Protocol Data Units (PDU's)

• Vertical communication
  • Messages are called primitives
  • Layer N produces service to layer n+1 and uses the service of layer n-1
  • Service is accessed via service access point (SAP)
  • PDU is enveloped and given to lower layer

• Layer N entity passes IDU to layer N-1 via N-1 SAP
  • SDU : Service data unit (protocol data)
  • PCI : Protocol control information (protocol header)
  • PDU : protocol data unit (N PDU is usually N-1 SDU)
  • ICI : Interface control information
  • IDU : Interface data unit

• Confirmed service
  • primitives: request → indication → response→confirmation
• Unconfirmed service
  • no handshake
  • request → indication
• Provider initiated
  • indication to both sides from lower layer
  • e.g. lost connection