FTP, NFS, 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 (connection for sending data is different from connection for control data)
- the file size is 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: slow (stop-and-wait) and insecurely (no logins), but reliably (retransmit until received)

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 (multiple local file systems can be on disk or in memory)
NFS clients send commands and data in UDP datagrams, expect responses, and will retransmit if no response is received
the NFS server does not keep track of connected clients: the server is stateless, and each request must be self-contained
NFS requests are designed to be idempotent, so they can be repeated multiple times, e.g. so they must have the position of the file being read or written
NFS usually transfers one block at a time, AFS (Andrew File System) usually one file at a time, Coda allows caching and disconnected operation

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)

suppose my code calls 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 from other information)
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
many versions of SNMP (at least 3), and only version 1 is really simple

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