A few layers of OSI protocol...

Physical Layer protocols
	- mechanical (what the connector looks like, etc.)
	- electrical (or optical) (voltage levels, signaling standards)
	- ignores question of reliability -- left to higher layer
	- how are the bytes encoded?  which bit goes first? etc...
	- how does network controller send/receive data?
	- what happens if two hosts try to send at once (contention)?
	- e.g. RS-232C (not really a network protocol since it's rarely
		        used for network communication)
	- e.g. Ethernet 
		- base T or base 2 physical connector specification
		- voltage levels, bit-timing, start/stop signals, etc.

Data Link Layer protocols
	- organize the "physical" raw bit streams to ensure reliable
	  communication across one specified physical link
	- responsible for error-free movement of data between network nodes
	- involves:
		- framing (putting many bytes together)
		- signaling (how to activate/maintain/deactivate the link)
		- error detection/correction mechanisms

	- data is not sent in individual bytes, but as FRAMES of large data
	  blocks (varies from a few bytes through 1500 bytes for Ethernet 
          or 4096 bytes for most Frame Relay systems)
	- each frame typically consists of:
		header: destination, sender, type of frame, num data bytes
		data block: actual information to be communicated
		trailer: checksum

	- must ensure that data passed up to next layer conforms to specs
		- data is received exactly as transmitted: error control
		- no data is lost: flow control
		- data is in correct order: flow control
	- error control:
		- compares transmitted checksum with computed version
		- if they differ, pretend frame didn't arrive
	- flow control:
		- data should be transmitted only as fast as 
		  receiver can receive it (e.g. "stop-and-wait", 
						"sliding-window")
		- sequence numbers used to number the frames
		- why would this be needed??? (think internetwork)

	- e.g. Ethernet 
		- CSMA/CD signalling specification
		- frame size: 1500 bytes

	- e.g. ISO HDLC (high level data link control)
		flag: special bit pattern indicating start of frame
		address: typically 1 byte to identify sender or receiver
		control: multi-byte, indicates whether frame is 'data' or 
			'supervisory' (performs link control function) and
			may contain a sequence counter
		data: the frame payload 
		error detecting info (e.g. CRC)

Network Protocols
	- previous two layers rely on continuous physical connection
	- what if one host wishes to send data to host on another network?
	- communication across a network is inherently unreliable
	- point-to-point: no need of network layer
	- circuit-switching: goes through one network
	- packet-switching: goes through one network
	- across various networks

Transport Layer Protocols
- TCP/UDP (not really OSI but that's what we use)
- in Unix, SOCKETS are the basic building blocks for communication
- they are communication endpoints amenable to be BOUND to a NAME
- they have a TYPE and are associated with one or more processe;
  the association is the same as the one among processes and files
  (i.e. through descriptors)

- sockets exist within COMMUNICATION DOMAINS, which can be seen as
	- aggregates of common properites of the processes 
	  communicating through sockets
	- name/address spaces used to identify the communicating endpoints
		- Unix domain: AF_UNIX
		- Inet domain: AF_INET
		- XSIS domain: AF_NS

- socket types define the socket's communication properties visible
  to a user application
- communication usually (but not required to) takes place among 
  same-type sockets
	- stream: bidirectional, reliable, sequenced, unduplicated data flow
	- datagram: bidirectional, connectionless, unreliable, small msg len
	- raw: access directly to protocols, normally datagram oriented, 
		only for super-user
	- sequenced packets: bidirectional, reliable, sequenced

Socket Creation

- system call: socket(2)
	int socket (int domain, int type, int protocol);

- domain can be AF_UNIX, AF_INET, AF_NS
- type can be SOCK_STREAM, SOCK_DGRAM, SOCK_RAW, SOCK_SEQPACKET
  (not all available under all domains)
- protocol can be 0 (default) or domain/type-dependent
- creates an entry in the FD table for the invoking process

Binding Sockets to Names

- what does it mean to name a socket?
- why would we want to name a socket?
- consider client-server applications

- struct sockaddr_un { short sun_family; 
			char sun_path[108];
		     }
- in AF_UNIX, sockets are bound to actual file names
  (however, no data is actually read from or written to the file)
- must remove (unlink) the file when done; otherwise...?

- struct sockaddr_in { short sin_family;
			u_short sin_port; 
			struct in_addr sin_addr;  /* u_long sin_addr.s_addr */
			char sin_zero[8];
		     }
- in AF_INET, socket names are bound to protocol-specific
  addresses called PORT NUMBERS
- to identify an AF_INET socket, the sender must specify
  

- network system calls: 
	int bind (int sock, struct sockaddr *name, int namelen);
	int getsockname (int sock, struct sockaddr *name, int namelen);
	int listen (int sock, int backlog);
	int connect (int sock, struct sockaddr *name, int namelen);
	int accept (int sock, struct sockaddr *addr, int *addrlen);

- C library system calls:
	struct hostent *gethostbyname (char *hostname);

	struct hostent {
               char *h_name;  	/* official name of host */
               char **h_aliases;   /* alias list */
               int  h_addrtype;    /* host address type */
               int  h_length; 	/* length of address */
               char **h_addr_list; /* h_addr == h_addr_list[0] */
          };


Putting it together: Bi-directional TCP communication

Client Side		Server Side
-----------		-----------
socket()		socket()
			bind()
			listen()
connect() ----------->	accept()  [ select() ]

write() ------------->	read()
read() -------------->	write()

close()			close()