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()