Networking and Communications

Networking and Communications
October 22, 2002

Computer Networks Computer Networks Types of Networks
"interconnected collection of autonomous computers" [Tanenbaum 1996] Types of Networks Local Area Networks (LANs) high-speed communication on proprietary grounds (on-campus) most typical solution: Ethernet with 100 Mbps

Computer Networks Types of Networks (cont.) Metropolitan Area Networks
high-speed communication for nodes distributed over medium-range distances, usually belonging to one organization providing "back-bone" to interconnect LAN's technology often based on ATM, FDDI or DSL

Computer Networks Types of Networks (cont.) Wide Area Networks
communication over long distances covers computers of different organizations high degree of heterogeneity of underlying computing infrastructure involves routers speeds up to a few Mbps possible, but around Kbps more typical most prominent example: the Internet

Computer Networks Types of Networks (cont.) Wireless Networks
end user equipment accesses network through short or mid range radio or infrared signal transmission Wireless WANs GSM (up to about 20 Kbps) UMTS (up to Mbps) PCS Wireless LANs/MANs WaveLAN (2-11 Mbps, radio up to 150 meters) Wireless Personal Area Networks bluetooth (up to 2 Mbps on low power radio signal, < 10 m distance)

Computer Networks Network Type Performance Characteristics Range
Bandwidth (Mbps) Latency (ms) LAN 1-2 kms 1-10 WAN worldwide MAN 2-50 kms 1-150 10 Wireless LAN km 2-11 5-20 Wireless WAN worldwide Internet worldwide

Protocols Agreement between two communicating parties how the communication is to proceed syntax message formats data representation semantics: when to send which message appropriate responses how to detect and handle failures

Services provide functions to invoker of service
use other services while providing abstraction from the particulars of the used services

Message Formats header: sequence numbers, synchronization patterns, message types, etc. data: user data trailer: end sequence, error check sum

OSI-BRM Open Systems Interconnection Basic Reference Model (OSI-BRM)

OSI-BRM

OSI-BRM Application Layer
Provide services that support the various types of distributed applications OSI protocols electronic mail (X.400, almost entirely extinct these days) name/directory services (X.500, some residual interest and some implementations)

OSI-BRM Application Layer Internet protocols
SMTP (simple mail transfer protocol) FTP (file transfer) telnet (remote login) http (hypertext transfer protocol)

OSI-BRM Presentation Layer
Problem: different computers represent data in different formats In the Internet: XDR (external data representation), fixed conventions for the representation of data all integers 4-byte big-endians floating point numbers in IEEE format texts in ASCII all fields aligned on 4-byte word boundaries

OSI-BRM Presentation Layer Problem: may require two conversions
XDR-to-C compiler exists

OSI-BRM Session Layer Support session oriented traffic (classical database applications, file transfer, etc.) Two main functions send token management synchronization/resynchronization after failures Non-existent in Internet RM functions are the responsibility of the application or the application layer protocols

OSI-BRM Transport Layer
Provide services for application message exchanges between peer application entities Interface with the underlying network if application messages are too big for network layer, segment them and reassemble at the receiving end multiple network connections for one application connection (if higher bandwidth needed than what one network connection can deliver) multiplex multiple application connections via one network connection, if possible, to efficiently use network bandwidth

Provide connection across network with well-defined qualities (QoS, quality of service) connection establishment delay connection establishment failure probability throughput transit delay residual error ratio protection priority

Provide connection-oriented as well as connection-less services connection-oriented: establish connection on a well-defined source service access point (or port) p and destination service access point p’ send messages to ports without providing target address

Provide connection-oriented as well as connection-less services connection-less: send messages providing target address for each message sent

OSI-BRM Transport Layer connection-less vs. connection-oriented
no overhead for connection setup and release potential bandwidth-loss due to complete address information no possibility to perform error-correction (pushed into application) connection-oriented overhead, but no bandwidth loss need to reserve network resources facilitates ensuring connection properties order preservation retransmission

OSI-BRM Transport Layer Ports
link an application process to a transport connection permit identifying a remote application process (or service) note: use of process id in target node would be unsuitable since pids are generated and destroyed dynamically in most operating systems The internet protocol architecture defines reserved port numbers, e.g. FTP: 21 (ftp connection establishment etc.) FTP-DATA: 20 (ftp data transfer) TELNET: 23 (terminal connection) SMTP: 25 (mail delivery) HTTP: 80 (http requests)

OSI-BRM Transport Layer UDP (User Datagram Protocol)
provides unreliable, connectionless transport service no guarantee of order preservation, delivery message duplications are possible facilitates multicast application areas: context-free protocols, simple client-server applications, i.e., one request - one reply Domain Name Server lookup SNMP requests NFS requests Multimedia protocols that do not require error correction

OSI-BRM Transport Layer UDP (User Datagram Protocol)
UDP header format:

OSI-BRM Transport Layer TCP (Transport Control Protocol)
provides connection-oriented transport service error-correcting order preserving segmentation of application-layer data stream duplex communication transport connection uniquely identified through network (IP) addresses of sender end receiver port addresses of sender and receiver protocol identifier for TCP (=6)

OSI-BRM TCP (header):

OSI-BRM TCP (pseudo-header):

OSI-BRM TCP despite complexity, allows for high data rates (experimentally up to 100 Mbit/s) useable in LAN/MAN/WAN environments typical applications (SMTP) file transfer (ftp) remote terminal (telnet) remote graphics terminal (X11 for X-Windows) http

OSI-BRM Network Layer Central questions:
addressing: how to identify the target computer routing: how to route the message most effectively through the network packet switching: will there be a new path for every packet, or will there be predescribed paths from source to destination connection setup and release end-to-end error detection, ensuring packet ordering, flow-control General functionality: network transparency for the transport layer provide for end-to-end transport connection independent of actual routing and switching decisions

OSI-BRM Network Layer Packet switching
virtual circuit: a fixed path for all packets of a connection will be determined at connection setup time facilitates order preservation route determination costs only once per connection inflexible to adapt to changing network loads and configurations datagram: routing decision for every packet in every node full address information in every packet less overhead for connection establishment, easier to implement more flexible for short-lived connections

OSI-BRM Network Layer Routing algorithms objectives
minimize average packet delay maximize total throughput efficient implementation conflicting, therefore often used: minimize number of hops (visited nodes) per packet reduces delay reduces needed bandwidth increases throughput

OSI-BRM Network Layer Routing algorithms
static (non-adaptive) algorithms determination of network routes for every pair of nodes at network setup time no consideration of current network status and load (average values used) no change of routes during network operation

OSI-BRM Network Layer Routing algorithms dynamic (adaptive) algorithms
determination of network routes based on measurement/estimation of current network load and configuration centralized: one central node makes routing decisions isolated: decision on routing based solely on local traffic and load information (backward learning, routing, delta-routing) distributed: nodes are exchanging routing information (distance vector routing)

OSI-BRM Data Link Layer error detection and correction
physical media are prone to signal distortions due to external impulses and material properties typical value for error probability of a 32 bit block over telephone wire:

OSI-BRM Data Link Layer error detection and correction
error detection: using check sum (e.g., parity bits) to detect e bit errors one needs code with Hamming distance of e+1 error correction: check sum plus exact information, which bit flipped to correct e bit errors, need 2e+1 Hamming distance often used: check sum generated through cyclic redundancy check detects all error burst with a length of up to 16, of all longer bursts

OSI-BRM Data Link Layer
frames: error-detecting and error-correcting codes need frame delimiters bit stuffing acknowledgement and retransmission of erroneous frames sequence numbers go-back-n

OSI-BRM Data Link Layer
flow control: nodes may receive more traffic than they can deliver to adjacent nodes, but have limited buffer capacity: buffer overflow sliding window protocol (of size n) sending node may race ahead a number of n unacknowledged messages if last acknowledged packet is k, and new acknowledgement l>k arrives, then sender may transmit up to sequence number k+n includes acknowledgement/retransmission functionality

OSI-BRM Physical Layer
defines the physical characteristics of the signal transmissions example: bit encoding mechanisms

Internet Protocol Architecture
Comparison OSI-BRM vs. Internet presentation and session layers not implemented in Internet architecture, will be implemented in application (e.g., XDR encoding) IP provides less functionality than network layer in OSI-BRM L2 and L1 not specified in Internet architecture

Addressing Addressing in the Internet Protocol
addresses used in source and destination fields of the Internet Protocol requirements define a unique address for any node in the Internet no two nodes on the Internet may have the same address

Addressing Addressing in the Internet Protocol requirements
define a sufficiently large address space IPv4 (1982): 32-bit addresses for 232 (appr. 4 billion) addresses insufficient due to unforeseen growth of internet inefficient use of address space IPv6 (1994): 128-bit addresses for 2128 (appr. 3x1038) addressable nodes max. 7x1023 IP addresses per m2 of entire earth surface if as inefficiently allocated as phone numbers: 103 per m2

Addressing Addressing in the Internet Protocol requirements
support a flexible routing scheme, but addresses themselves should not contain routing information

Addressing IP address class structure

Decimal representation of Internet addresses
octet 1 octet 2 octet 3 Range of addresses Network ID Host ID to Class A: 1 to 127 0 to 255 0 to 255 0 to 255 Network ID Host ID Class B: to 128 to 191 0 to 255 0 to 255 0 to 255 Network ID Host ID to Class C: 192 to 223 0 to 255 0 to 255 1 to 254 Multicast address Multicast address to Class D (multicast): 224 to 239 0 to 255 0 to 255 1 to 254 to Class E (reserved): 240 to 255 0 to 255 0 to 255 1 to 254

Addressing problems: network administrators cannot predict growth of their subnets tend to apply for class B network addresses, even though subnets then tend to be smaller than 255 nodes (i.e., class C would be sufficient) leads to inefficient use of address space

Routing Hosts Links or local networks A D E B C 1 2 5 4 3 6 Routers

Routing find cost optimal path from one node to another, i.e., paths with minimum number of hops e.g., from C to D: C-E-D has minimal cost of 2

Routing Routings from A Routings from B Routings from C To Link Cost
local A 1 1 A 2 2 B 1 1 B local B 2 1 C 1 2 C 2 1 C local D 3 1 D 1 2 D 5 2 E 1 2 E 4 1 E 5 1 Routings from D Routings from E To Link Cost To Link Cost A 3 1 A 4 2 B 3 2 B 4 1 C 6 2 C 5 1 D local D 6 1 E 6 1 E local

Routing cost column not used for routing decision, but for construction of routing table construction of routing tables: Routing Information Protocol (RIP) each node specifies single hop routing information use of a distributed algorithm, based on Ford-Fulkerson shortest path algorithm

Routing construction of RIP tables:
each node shares its local routing table information with all its direct neighbors: will send copy of local routing table to all adjacent nodes periodically, when a timer t expires (in internet typically t=30 sec.) when local routing table changes

Routing construction of RIP tables:
when receiving a routing table from a node R update table with new route or with existing route with better cost (compare local value with R’s value +1) when received on link n, and received table shows different value for some local route starting with n, then copy the value from received table (R is closer to destination and therefore it’s table is more authoritative)

RIP Algorithm Send: Each t seconds or when Tl changes, send Tl on each non-faulty outgoing link. Receive: Whenever a routing table Tr is received on link n: for all rows Rr in Tr { if (Rr.link | n) { Rr.cost = Rr.cost + 1; Rr.link = n; if (Rr.destination is not in Tl) add Rr to Tl; // add new destination to Tl else for all rows Rl in Tl { if (Rr.destination = Rl.destination and (Rr.cost < Rl.cost or Rl.link = n)) Rl = Rr; // Rr.cost < Rl.cost : remote node has better route // Rl.link = n : remote node is more authoritative }

Routing extensions: RIP-1 cost represents actual bandwidth
increased speed of convergence avoidance of loops

Internet Protocol (IP)
network protocol of the Internet protocol stack provides network service with the following characteristics no guarantee of delivery duplication possible unbounded delay no order preservation

Internet Protocol (IP)
address resolution IP addresses may need to be mapped to physical addresses (e.g., on Ethernet) use Address Resolution Protocol (ARP) either direct relation between IP and physical address, or mapping transport layer service provides data stream transmission service broken into network layer datagrams by transport layer IP: max length of datagram 64 Kbytes, usually 1500 bytes, if necessary by fragmenting and reassembling them further

IP version 6 (IPv6), 1994 enlarged address space
improved routing speed no checksum applied to body, only to header no datagram fragmentation occurs inside network (mechanism determining smallest datagram size along path before packet is transmitted)

IP version 6 (IPv6), 1994 improved routing speed
support for real-time traffic priority: preferred handling of high-priority packets flow labels: resource reservation for specific types of real-time traffic future evolution of protocol: next header may point to special header inside packet body (e.g., for router information) support for multicast, anycast, and security

MobileIP support for roaming of laptop computers, personal digital assistants (PDAs), wearable computing devices, etc. IP addresses are bound to subnet addresses, but roaming may leave subnet boundary

MobileIP Sender Subsequent IP packets tunnelled to FA Mobile host MH
Address of FA returned to sender First IP packet addressed to MH Internet Foreign agent FA Home First IP packet agent tunnelled to FA

MobileIP every IP address is assigned to “home” domain
home agent (HA) and foreign agent (FA) when devide is at home, will behave as local router when device leaves home area it informs HA HA behaves as proxy: will answer ARP requests for mobile device with own local network address

MobileIP every IP address is assigned to “home” domain
home agent (HA) and foreign agent (FA) when device arrives at a new side it informs FA FA assigns temporary, local address to mobile device FA then contacts HA and gives mobile device’s temporary and permanent address arriving packet for mobile device routed to HA tunneled to FA and delivered to mobile device subsequent packets from same source tunneled directly from sender to FA

Interprocess Communication
Distributed Systems rely on exchanging data and achieving synchronization amongst autonomous distributed processes Inter process communication (IPC) shared variables message passing message passing in concurrent programming languages language extensions API calls

Synchronization concurrent processes on different computers execute at different speeds need for one process to influence computation in another process specify constraints on the ordering of events in concurrent processes message passing

Message Passing Primitives send expression_list to destination_designator evaluates expression_list adds a new message instance to channel destination_designator receive variable_list from source_designator assigns received values to variables in variable_list destroys received message Central questions how are destination designators specified? how is communication synchronized?

Destination Designation direct naming: source and destination process names serve as designators (a pair of source and destination designators defines a channel) send cur_status to monitor or monitor!cur_status receive message from handler or handler?message easy to implement and use

Destination Designation allows a process easy control when to receive which message from which other process use to implement client/server applications well suited to implement client/server paradigm if there is one client and one server otherwise: server should be capable of accepting invocations from any client at any time, and a client should be allowed to invoke many services at a time if more than one server available

Destination Designation global names or mailboxes: process name-independent destination designator shared by many processes messages sent to a mailbox can be received by any process that executes a receive referring to that mailbox name to implement Client/Server applications clients send requests to mailbox, an available server picks them up

Destination Designation drawback: costly implementation message sent to mailbox relayed to all other sites that could potentially receive from that mailbox if one site decides to receive, inform all other sites that message is no longer available for receipt mutual exclusion for concurrent access

Destination Designation ports: mailbox, but only one process is permitted to receive from that mailbox easy to implement: receives can occur in only one process, no distribution and coordination necessary suitable for multiple clients / single server applications Message destinations in Internet programming hybrid direct naming/port scheme (Internet_address, port_number) port corresponds to many sender/one receiver concept

Channel Naming static (at compile time) impossible for a program to communicate along a channel not known at compile time inflexibility: if a process might ever need to communicate with a recipient, that channel must be available throughout the entire runtime of the sending program dynamic (at runtime) administrative overhead at runtime more flexible allocation of communication resources

Semantics of message passing primitives Blocking non-blocking: the execution will never delay the invoking process blocking: otherwise Synchronization asynchronous message passing: message passing using buffers with unbounded capacity sender may race ahead an unbounded number of steps sender never blocks receiver blocks on empty queue

Semantics of message passing primitives Synchronization synchronous message passing: no buffering between sender and receiver sender blocks until receiver ready to receive receiver blocks until sender ready to send buffered message passing: buffers with bounded, finite capacity sender may race ahead a finite, bounded number of steps sender blocks on full buffer receiver blocks on empty buffer

Non-blocking primitives for asynchronous or buffered message passing receive background variant: process continues, receives interrupt upon arrival overhead for implementation ignoring variant: program polls for availability send sending process waits for empty buffer or drops message to be sent

Distributed Applications availability of a set of pre-implemented application services, like , ftp, http, etc. what if you want to build your own, customized Internet application? access to Transport Layer services Services provided by Internet Transport Layer UDP: message passing (datagram) TCP: data stream

Sockets Internet IPC mechanism of Unix and other operating systems (BSD Unix, Solaris, Linux, Windows NT, Macintosh OS) processes in these OS can send and receive messages via a socket sockets are duplex sockets need to be bound to a port number and an internet address in order to be useable for sending and receiving messages each socket has a transport protocol attribute (TCP or UDP) messages sent to some internet address and port number can only be received by a process using a socket that is bound to this address and port number UDP socket can be connected to a remote IP address and port number processes cannot share ports (exception: TCP multicast)

IPC based on UDP datagrams UDP datagram properties: no guarantee of order preservation, message loss and duplications are possible necessary steps create socket bind socket to a port and local Internet address client: arbitrary free port server: server port

IPC based on UDP datagrams receive method: returns Internet address and port of sender, plus message message size: IP allows for messages of up to 216 bytes most implementations restrict this to around 8 Kbytes larger application messages: application’s responsibility to perform fragmentation/reassembling if arriving message is too big for array allocated to receive message content, truncation occurs

IPC based on UDP datagrams send: non-blocking blocks only until message given to UDP/IP upon arrival placed in per-port queue receive: blocking pre-emption by timeout possible if process wishes to continue while waiting for packet, use separate thread

Java API for UDP datagrams
Classes DatagramPacket constructor generating message for sending from array of bytes message content (byte array) length of message Internet address and port number (destination) similar constructor for receiving a message

Java API for UDP datagrams
Classes DatagramSocket class for sending and receiving of UDP datagrams one constructor with port number as argument, another without no-argument constructor to use free local port methods send and receive setSoTimeout connect for connecting a socket to a particular remote Internet address and port

import java.net.*; import java.io.*; public class UDPClient{ public static void main(String args[]){ // args give message contents and server hostname DatagramSocket aSocket = null; try { aSocket = new DatagramSocket(); byte [] m = args[0].getBytes(); InetAddress aHost = InetAddress.getByName(args[1]); int serverPort = 6789; DatagramPacket request = new DatagramPacket(m, args[0].length(), aHost, serverPort); aSocket.send(request); byte[] buffer = new byte[1000]; DatagramPacket reply = new DatagramPacket(buffer, buffer.length); aSocket.receive(reply); System.out.println("Reply: " + new String(reply.getData())); }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e){System.out.println("IO: " + e.getMessage()); }finally {if(aSocket != null) aSocket.close();} }

import java.net.*; import java.io.*; public class UDPServer{ public static void main(String args[]){ DatagramSocket aSocket = null; try{ aSocket = new DatagramSocket(6789); byte[] buffer = new byte[1000]; while(true){ DatagramPacket request = new DatagramPacket(buffer, buffer.length); aSocket.receive(request); DatagramPacket reply = new DatagramPacket(request.getData(), request.getLength(), request.getAddress(), request.getPort()); aSocket.send(reply); } }catch (SocketException e){System.out.println("Socket: " + e.getMessage()); }catch (IOException e) {System.out.println("IO: " + e.getMessage()); }finally {if(aSocket != null) aSocket.close();}

API for streams connection establishment using client/server approach, afterwards peer communication client: issue connect requests server: has listening port to receive connect request messages accept of a connection: create new stream socket for new connection

Java API for TCP streams
Classes ServerSocket class: create socket at server side to listen for connect requests Socket class: for processes with connections constructor to create a socket and connect it to remote host and port of a server methods for accessing input and output stream

import java.net.*; import java.io.*; public class TCPServer { public static void main (String args[]) { try{ int serverPort = 7896; ServerSocket listenSocket = new ServerSocket(serverPort); while(true) { Socket clientSocket = listenSocket.accept(); Connection c = new Connection(clientSocket); } } catch(IOException e) {System.out.println("Listen :“ +e.getMessage());}

class Connection extends Thread {. DataInputStream in;
class Connection extends Thread { DataInputStream in; DataOutputStream out; Socket clientSocket; public Connection (Socket aClientSocket) { try { clientSocket = aClientSocket; in = new DataInputStream( clientSocket.getInputStream()); out =new DataOutputStream( clientSocket.getOutputStream()); this.start(); } catch(IOException e) {System.out.println("Connection:"+e.getMessage());} } public void run(){ try { // an echo server String data = in.readUTF(); out.writeUTF(data); } catch(EOFException e) {System.out.println("EOF:"+e.getMessage()); } catch(IOException e) {System.out.println("IO:"+e.getMessage());} } finally{ try {clientSocket.close();} catch (IOException e){/*close failed*/} } } }

import java.net.*; import java.io.*; public class TCPClient { public static void main (String args[]) { // arguments supply message and hostname of destination Socket s = null; try{ int serverPort = 7896; s = new Socket(args[1], serverPort); DataInputStream in = new DataInputStream( s.getInputStream()); DataOutputStream out = new DataOutputStream( s.getOutputStream()); out.writeUTF(args[0]); // UTF is a string encoding see Sn 4.3 String data = in.readUTF(); System.out.println("Received: "+ data) ; }catch (UnknownHostException e){ System.out.println("Sock:"+e.getMessage()); }catch (EOFException e){ System.out.println("EOF:"+e.getMessage()); }catch (IOException e){System.out.println("IO:"+e.getMessage()); }finally {if(s!=null) try {s.close(); }catch (IOException e){ System.out.println("close:"+e.getMessage());}} }

Data Representation data representation problem
use agreed external representation, two conversions necessary use sender’s or receiver’s format and convert at the other end transmission of structured data types data types may not change during transmission usage of a commonly understood “flattened” transfer format (structured types are reduced to their primitive components)

Data Representation marshalling/unmarshalling
marshalling: assembling a collection of data items in a form suitable for transmission unmarshalling: disassembling and recovery of original data items usually performed automatically by middleware layer hand-programming error-prone use of compilers for programs working directly at transport API

Java Object Serialization
flattening an object into a linear form such that it can be stored in a file or transmitted in a message linear format must be such that deserialization routine is capable of recovering the complete object structure and state inclusion of handles (references to other objects) name of class that an object belongs to version number of class note: mark objects as non-serializable (“transient”) if they are not supposed to be serialized (e.g., socket references, files, etc.)

serialization: create instance of class ObjectOutputStream and invoke writeObject method, passing object to be serialized as argument deserialization: open ObjectInputStream on the serialized structure and use readObject method

reflection: enables serialization/deserialization in a generic manner query on properties of a class, names and types of instance variables methods (including constructors) classes can be created based on their names a constructor with given argument types can be created serialization use reflection to find out the class name and name, type and value of its instance variables deserialization use class name to create a class used to create a new constructor with argument types corresponding to those in the serialized form use new constructor to create a new object with instance variables that are identical in value and type to those at serialization time

Remote Object References
needed when a client invokes an object that is located on a remote server reference needed that is unique over space and time space: where is the object located time: correct version of an undeleted object

Remote Object References
extension object references that are location transparent Internet address port number time object number interface of remote object 32 bits

Client-Server Communication
often built over UDP datagrams client-server protocol consists of request/response pairs, hence no acknowledgements at transport layer are necessary avoidance of connection establishment overhead no need for flow control due to small amounts of data transferred generic protocol example (for RPC or RMI communication)

format of protocol messages message type (request/reply) request ID sending process identifier (e.g., IP address/port number) integer sequence number incremented by sender with every request object reference method ID and arguments

if implemented over UDP: failure recovery omission failures use timeout and resend request when timeout expires and reply hasn’t arrived server receives repeated request indempotent operations: same result obtained on every invokation non-indempotent operations: re-send result stored from previous request, requires maintenance of a history of replies loss of replies: request - reply - ack reply protocol message duplication: return request ID with reply

example: Hypertext Transfer Protocol (HTTP) lightweight request - reply protocol for the exchange of network resources between web clients and web servers protocol steps connection establishment between client and server (likely TCP, but any reliable transport protocol is acceptable) client sends request server sends reply connection closure

example: Hypertext Transfer Protocol (HTTP) inefficient scheme, therefore HTTP 1.1 allows “persistent transport connections” (remains open for successive request/reply pairs) Resources can have mime-type data types, e.g. text/plain text/html image/jpeg data is marshaled into ASCII transfer syntax

HTTP request GET // HTTP/ 1.1 URL or pathname method HTTP version headers message body GET: request of resource, identified by URL, may refer to data: server returns data program: server runs program and returns output data HEAD: request similar like GET, but only meta data on resource is returned (like date of last modification) POST: specifies resource (for instance, a server program) that can deal with the client data provided with previous request PUT: supplied data to be stored in given URL DELETE: delete an identified resource on server

HTTP reply HTTP/1.1 200 OK resource data HTTP version status code reason headers message body

Networking and Communications

Similar presentations

Presentation on theme: "Networking and Communications"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Networking and Communications

Similar presentations

Presentation on theme: "Networking and Communications"— Presentation transcript:

Similar presentations

About project

Feedback