Internet Content, RPC, SNMP
- FTP
- NFS
- URLs
- HTML
- CGI
- Applets
- Remote Procedure Calls
- Simple Network Management Protocol
File Transfer Protocol
- runs over TCP
- server listens on port 21, client establishes a connection
for exchanging commands (and login information): the control connection
- to exchange a file, server establishes a connection to the client,
and data is transferred over this data connection:
- data is out-of-band
- file size marked by closing the connection
- the client's port number must be specified in the transfer command
- numeric codes for success and failure
- TFTP (Trivial FTP) for transfers over UDP (slowly and
insecurely, but reliably)
Network File System
- an NFS server exports a directory as a network file system
- an NFS client mounts an exported network file system as one
of its file systems (others can be on disk or in memory)
- NFS clients send commands and data in UDP datagrams, expect responses
and will retransmit if the response is not received
- NFS server does not keep track of connected clients: the server is
stateless, and each request must be self-contained
- NFS usually transfers one block at a time, AFS (Andrew File System)
usually one file at a time, Coda allows caching and disconnected operation
Uniform Resource Locators
- protocol://dns:port/document_name, e.g.
http://www2.ics.Hawaii.Edu:80/~esb
- the domain name is case-independent, the document name may
be case-sensitive
- GET operation: all information is in the URL
- POST operation: like GET, but the information is in the body
- also PUT, DELETE
- HTTP/1.1 (and some versions of HTTP/1.0): a single connection
can be used to GET multiple web pages
HTTP Browser Architecture
- inputs from keyboard/mouse/window system, outputs to display
- HTTP client uses network connection to load pages, may
cache pages (pages are often stable)
- non-HTTP clients may do other things, e.g. load and save FTP files
- HTML interpreter parses HTML, decides how to display it
- non-HTML interpreter must display other types, e.g. GIF images
- non-HTML interpreters could do other things, such as interpret
Java programs (applets)
HTTP Server Architecture
- an HTTP server must listen for incoming connections (usually on
port 80), and respond appropriately
- a normal GET requires the server to read a file, create a header,
and return the header and the contents of the file
- a server is free to cache the contents of specific paths
- a server could also respond to requests for specific paths by
generating the contents dynamically
Common Gateway Interface
- dynamic document generation, often database lookup or insertion:
maps, purchases, registration, customized content
- specific (configurable) path tells server to execute programs
rather than deliver them as web pages
- arguments in URL or POST are input to program
- program outputs web page (and part of the HTTP header, e.g. content type)
- ASP, PHP are similar standards
- the server executes Java Servlets
CGI data
- long-term state is stored in files and databases on the server machine
- shorter-term state can be remembered in URLs given to the client
- a server interprets everything following a ? in a URL
as an argument to the CGI script
- for example, in URL http://x/cgi/z?99.3, the argument to
script z is 99.3
- in a form, each field has an item name: the browser appends the
names of the items and the values to the URL when the link is selected
- for example, URL http://x/cgi/z?a=3&b=xxx&c=no
Applets
- interaction across a network can be slow, uncertain
- applets let the browser execute code locally
- browser loads "binary" (bytecode) applet, provides
runtime environment and the class libraries
- the execution environment must provide a sandbox: the
applet should not be able to read or modify local files, break the
browser, or do other inadvertent or malicious damage
RPC
- Remote Procedure Call
- a procedure call resembles a client-server interaction: the client
is the caller, the server the callee
- ideally a remote procedure call should be as easy, convenient, and
predictable as a local procedure call or method invocation
- one advantage of a remote procedure call is the server can access
the environment (files, etc) of the remote system
- another advantage is the server runs in a separate address space,
so this can be a way for multiple processes to communicate and share
information (e.g. an RPC to the print daemon)
RPC Implementation
- if my code would call a local function int f(int a, char *b);,
if f is remote my code should pass the same arguments
and get the same type of result back
- we replace f with another function f_stub which:
- connects to the remote system
- sends the arguments in a standard (machine-independent) format
- waits for a response from the peer
- returns the resulting value or takes appropriate action (e.g. throw
an exception)
- to the caller, this is indistinguishable from calling the local
function
Stubs
- sending the parameters/results in a machine-independent format may
require more information than is available in the programming language
- for example, in C, char *b could be a string (null terminated)
or a binary buffer (length is known somewhere else)
- once this information is available, the client stub can be generated
automatically
- the server-side stub takes the external representations and calls the
function, then marshals the result and sends it back
External Data Representation
- stubs can be generated automatically given a description of
the types (at a level slightly higher than C's)
- the description of the function call and types is called an
External Data Description or an Interface Description Language
- different data description languages exist:
- XDR (eXternal Data Representation), C-like, with automatic
stub generator -- mostly for Sun RPC
- ASN.1, very bit efficient, very general (variable length fields, etc),
very standard
Specific RPC Systems
- Sun RPC (Open Network Computing RPC):
- XDR for the external data representation and for marshaling
and unmarshaling
- remote procedure identified by IP, package (library, program) number,
procedure number, and version
- DCE RPC (Distributed Computing Environment RPC)
- MSRPC (Microsoft RPC), versions 1 and 2
- COM (Common Object Broker) and DCOM (Distributed)
- CORBA (Common Object Request Broker Architecture): object-oriented
RPC allows remote method calls, has "object stubs"
Network Management
- distributed problem: often the fault is remote
- catastrophic faults (e.g. network partition) are often relatively
easy to locate
- subtler faults can be harder to identify, locate, fix
- routing failures consume resources, may indicate misconfiguration
- components that fail intermittently may just be starting to fail
- we can use the network to monitor the components of the network
- a server on each host will respond to queries from centralized clients
SNMP
- Simple Network Management Protocol
- commands are used to either fetch or store values in
a Management Information Base (MIB), which
describes the values available on the system
- each value is identified by its unique position in a tree
that includes organizations, model numbers, protocols,
and values within a device (variable-length identifiers)
- an SNMP management station (client) must be configured with the
MIBs of the protocols of interest and of the devices of interest
SNMP operation
- collections (e.g. routing table entries) are conceptually part
of the tree
- the next command can be used to access the next entry in the tree
- an SNMP client can request that traps (alarms) be sent for specific
conditions
- like monitoring a nuclear power plant: most of the time, nothing
happens, just keep track of traffic, statistics
- if the statistics start going bad, or if a catastrophe happens,
use the monitoring station to try and find the problem