Internet Content, RPC, SNMP

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)

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

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

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)

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

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

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

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

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)

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

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

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

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"

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

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

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