TCP/IP, OSI and LAN

1.0 TCP/IP > top of page

1.1 ISO/OSI 7 layer model > top of page

1.1.1 OSI 7 generic > top of page

The OSI layer model (Open Systems Interconnection) is some kind of norm for communication platforms. It is important to know that OSI is more a proposal rather than a classic norm. The OSI model has been designed in the 1970's by the International Standards Organisation.

The classic model describes the theoretical structure of communication systems from hardware to software level. There are seven layers:

• 1. physical layer
• 2. data link layer
• 3. network layer
• 4. transport layer
• 5. session layer
• 6. presentation layer
• 7. application layer

1.1.1.1 physical layer: The medium used to physically transmit data (ethernet cable, fiber, wireless etc.).

1.1.1.2 data link layer: Performs basic transmission verification, error correction and addressing using MAC (Media Access Control).

picture 1a: generic OSI 7 layer model

1.1.1.3 network layer: Responsible for logical data forwarding and address translation (e.g. MAC->ARP/RARP<-IP).

1.1.1.4 transport layer: Creates packets from streams, numbers them, and on receive builds a stream respecting the original order.

1.1.1.5 session layer: Handles virtual point-to-point sessions (keep-alive).

1.1.1.6 presentation layer: Prepares data streams for the next level (e.g. byte reordering). Provides send and receive functions for applications.

1.1.1.7 application layer: The final layer that interacts with the user and holds the data logic.

1.1.2 OSI TCP/IP (specific) > top of page

Taking TCP and IP as an example, we reduce the seven-layered model to five steps:

• 1. physical layer (e.g. NIC, wires or WLAN)
• 2. network layer: ARP/RARP, MAC, IP, ICMP
• 3. transport + session layer: TCP or UDP
• 4. presentation layer: Berkeley Socket API
• 5. application layer: ssh/telnet, FTP, POP3, SMTP, HTTP, NFS, IMAP, NNTP...

picture 1b: OSI model for TCP/IP (5 layers)

1.1.2.3 transport & session layer: TCP and UDP share: packaging of streams into packets; reordering packets to a stream. TCP additionally handles: holding connections (keep alive), ACK, CRC checksums, retransmission of defect packets.

1.1.2.4 presentation layer: Provides an API for applications. The most prominent is the Berkeley Socket API.

1.1.2.5 application layer: Applications implementing HTTP, NNTP, sunRPC, POP3, SMTP, IMAP etcetera.

1.2 low level services > top of page

1.2.1 MAC > top of page

In an ethernet LAN, each communication point is called a node. Every node owns a MAC address consisting of 48 bits (6 bytes), hardwired and worldwide unique. The first 24 bits identify the manufacturer, the second 24 bits are assigned by the manufacturer. The IEEE-SA assigns the manufacturer ID.

1.2.2 ARP/RARP > top of page

On a logical level, IP addressing is used. IP addresses consist of 32 bits / four bytes (e.g. 192.168.1.1). ARP (Address Resolution Protocol) resolves IP to MAC: station A broadcasts a package containing own MAC, own IP, empty receiver MAC, and receiver IP. The matching station fills in its MAC and replies.

Pic 1c: address resolution, step 1 (click to enlarge)

Pic 1d: address resolution, step 2 (click to enlarge)

Each node holds an ARP table. RARP (reverse) helps diskless stations determine their assigned IP.

1.2.3 ICMP > top of page

The ICMP (Internet Control Message Protocol) is used for diagnosing: errors in TCP stack, IP, MAC and ARP, (un-)reachable nodes, routing errors. The ping command abuses ICMP for host echos.

1.2.4 Internet Protocol (IP) > top of page

IP handles logical addressing. IPv4 uses 32 bit (e.g. 192.168.1.9), allowing two to four billion addresses. IPv6 uses 128 bit, theoretically allowing approx. 30,000 IP addresses per square meter of earth's surface (e.g. fe80:d0:b783:a813).

1.2.5 Domain Name Service (DNS) > top of page

DNS resolves URLs/URIs into IP addresses and vice versa. A complete URL consists of: protocol (http://), subserver, server name, TLD (.net), path (/cgi-bin/), query delimiter (?), program (login.pl).

1.3 packager > top of page

While ARP and IP handle addressing, a powerful instance for error correction and stream (dis-)assembly is needed. These are the tasks of TCP or UDP.

1.3.1 Transmission Control Protocol (TCP) > top of page

Large data chunks are split into small packages sent step by step. Each package gets a serial number since packages may travel different routes and arrive out of order. The receiver's TCP stack reorders them. Key features: splitting data, checksums, serial numbers, sorting, stream recreation, requesting resubmissions, confirming received data.

1.3.2 User Datagram Protocol (UDP) > top of page

TCP is too complex for some tasks. UDP comes in place for services not requiring receive confirmation, e.g. DNS queries.

2.0 Berkeley Socket API > top of page

The standard API for basic network development is the Berkeley Socket API, originating from BSD. It handles addressing and raw data transmissions, not higher level protocols like HTTP or POP3.

2.1 the filehandle concept > top of page

Files are mapped to numeric handles (commonly 32bit integers). Sockets work like abstract files.

open(FILE, './neveprise.dat');
foreach my $line(<FILE>) {
   print(STDERR, $line);
}
close(FILE);

int   myFile = 0;
int   bytesWritten = 0;
char  msg = '';
myFile = open('/var/log/messages', 0);
if (myFile != -1) {
   msg = 'this is a message from neveprise.net';
   bytesWritten = printf(myFile, msg, strlen(msg));
   close(myFile);
} else {
   fprintf("Oops! error  %d on open() by hellomsg.c\n", errno);
}

2.2 sockets (abstract) > top of page

A socket is one of at least two communication endpoints with: a protocol type, an address, a port number or service alias.

2.2.1 ports > top of page

A server may provide multiple services simultaneously via specific "channels" (ports). Default ports are only used for initial requests; further communication uses ports above 1024. A system has up to about 64,000 ports. For more, RPC (remote procedure call) can expand this via the sunrpc daemon.

2.2.2 services > top of page

Some ports are assigned to specific services (see port table in section 1.2.5). On Linux, see /etc/services; on Windows, \windows\services.

2.3 socket functions and structures > top of page

int socket(): Creates a communication endpoint and returns a socket handle.

int socket(int domain, int type, int protocol);

if ((s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP)) == SOCKET_ERROR) {
   printf("Doh! An error occurred on socket(), code %d", errno);
   exit;
}

struct sockaddr: Sets socket options. Client socket sets target address; server socket uses INADDR_ANY.

// client socket
mysockaddr.sin_family = AF_INET;
mysockaddr.sin_port   = 80;
mysockaddr->sin_addr = *(struct in_addr *) hostinfo->h_addr;

// server socket
mysockaddr.sin_family = AF_INET;
mysockaddr.sin_port   = 80;
mysockaddr.sin_addr.s_addr = htons(INADDR_ANY);

int bind(): Assigns local system information to the socket.

int connect(): Establishes connection with a server socket.

int listen(): Sets a server socket to active listen mode.

int accept(): Creates a new socket for conversation when a connection request arrives, freeing the server socket for further listening.

newsock = accept(s, (struct sockaddr *) clientsockaddr, &size);

send()/print(): Sends data. send() is specifically designed for socket context with more tolerant timeout implementations.

int bytewritten;
char *msg = new char[255];
msg = "hello world!";
bytewritten = send( s, msg, strlen(msg) +1, 0);
if (bytewritten == SOCKET_ERROR) {
   printf("Doh! Error on send(), cause %d.", errno);
}

recv()/scan(): Receives data from a socket.

int bytesread, maxlen = 255;
char buf = new char[maxlen];
bytesread = recv( newsock, buf, maxlen, 0);
if (bytesread > 0) {
   printf("output from client: %s\n", buf);
}

select() events: Registers file listen handlers that notify the process when data arrives, avoiding CPU-wasting polling loops. select() blocks until data is available on any monitored socket. Extended information on sockets can be found in the RFCs 129 and 147.