Network Applications

Creating a network app

write programs that:

• run on (different) end systems
• communicate over network
• e.g., web server software communicates with browser software

no need to write software for network-core devices

• network-core devices do not run user applications
• applications on end systems allows for rapid app development, propagation

Client-Server Paradigm

server:

• always-on host
• permanent IP address
• often in data centers, for scaling

clients:

• contact, communicate with server
• may be intermittently connected
• may have dynamic IP addresses
• do not communicate directly with each other
• examples: HTTP, IMAP, FTP

Peer-peer Architecture

• no always-on server
• arbitrary end systems directly communicate
• peers request service from other peers, provide service in return to other peers
  • self scalability – new peers bring new service capacity, as well as new service demands
• peers are intermittently connected and change IP addresses
  • complex management
• example: P2P file sharing

Processes Communicating

Process: program running within a host

• within same host, two processes communicate using inter-process communication (defined by OS)
• processes in different hosts communicate by exchanging messages

Note

Applications with P2P architectures have client processes & server processes

Sockets

• process sends/receives messages to/from its socket
• socket analogous to door
  • sending process shoves message out door
  • sending process relies on transport infrastructure on other side of door to deliver message to socket at receiving process
  • two sockets involved: one on each side

Addressing processes

• to receive messages, process must have identifier
• host device has unique 32-bit IP address

Does IP address of host on which process runs suffice for identifying the process?

No, many processes can be running on same host.

• identifier includes both IP address and port numbers associated with process on host
• Example port numbers:
  • HTTP server: 80
  • mail server: 25
• to send HTTP message to gaia.cs.umass.edu web server:
  • IP address: 128.119.245.12
  • port number: 80
• more shortly…

An application-layer protocol defines:

• types of messages exchanged,
  • e.g., request, response
• message syntax: - what fields in messages & how fields are delineated
• message semantics - meaning of information in fields
• rules for when and how processes send & respond to messages
• open protocols:
  • defined in RFCs, everyone has access to protocol definition
  • allos for interoperability
  • e.g., HTTP, SMTP
• proprietary protocols:
  • e.g., Skype, Zoom

What transport service does an app need?

data integrity

• some apps require 100% reliable data transfer
• other apps (e.g., audio) can tolerate some loss

timing

• some apps (e.g., Internet telephony, interactive games) require low delay to be “effective”

throughput

• some apps (e.g., multimedia) require minimum amount of throughput to be “effective”
• other apps (“elastic apps”) make use of whatever throughput they get

security

• encryption, data integrity

Internet transport protocols services

TCP service:

• reliable transport between sending and receiving process
• flow control: sender won’t overwhelm receiver
• congestion control: throttle sender when network overloaded
• connection-oriented: setup required between client and server processes
• does not provide: timing, minimum throughput guarantee, security

UDP service:

• unreliable data transfer between sending and receiving process
• does not provide: reliability, flow control, congestion control, timing, throughput guarantee, security, or connection setup.

Why bother? Why is there a UDP?