09.12.2012 Views

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Internet Society, a nonprofit organization that coordinates <strong>the</strong> development of <strong>the</strong><br />

Internet.<br />

TCP/IP and UNIX<br />

In <strong>the</strong> early days of computing, operating systems were something <strong>the</strong> user built.<br />

Early computer systems came with a limited set of <strong>to</strong>ols, which provided <strong>the</strong><br />

capability <strong>to</strong> load, compile program routines, and perform basic I/O tasks. The<br />

"operating system" was developed by <strong>the</strong> programmer/users because everything<br />

was written in <strong>the</strong> assembler language specific <strong>to</strong> that computer (<strong>the</strong>re was no Plug<br />

and Play in <strong>the</strong> early days). In <strong>the</strong> late 1960s, two fellows at Bell Labs, Dennis<br />

Ritchie and Ken Thompson, started working on a different approach <strong>to</strong> computer<br />

operating systems, known as UNIX. The goal was <strong>to</strong> develop a core operating<br />

system (<strong>the</strong> kernel) <strong>to</strong> manage <strong>the</strong> various hardware elements of <strong>the</strong> computer<br />

(CPU processing, memory management, s<strong>to</strong>rage I/O, and so on), plus an extensive<br />

set of <strong>to</strong>ols that were easily ported <strong>to</strong> any hardware platform.<br />

Although UNIX was <strong>the</strong> property of Bell Labs, it was made available <strong>to</strong> universities<br />

and research facilities for noncommercial use with no support. As a result of its wide<br />

distribution, a lab project became an operating system that was improved by a large<br />

community of academic programmers who saw its potential. The notion that "<strong>the</strong><br />

documentation is <strong>the</strong> code" and that "programs should be small, and do one thing<br />

and do it well" came out of this giant collaborative effort. In 1974, some of <strong>the</strong><br />

people involved with <strong>the</strong> development of ARPAnet and TCP/IP saw a similar synergy<br />

between UNIX and TCP/IP. Along with <strong>the</strong> integration of TCP/IP pro<strong>to</strong>cols in<strong>to</strong><br />

ARPAnet, an effort was started at <strong>the</strong> University of California at Berkeley <strong>to</strong><br />

integrate TCP/IP in<strong>to</strong> <strong>the</strong> UNIX implementation. This beta (experimental) TCP/IP<br />

stack was introduced in 1981 as <strong>the</strong> Berkeley Software Distribution (BSD) 4.1a<br />

release, and <strong>the</strong> production stack was BSD 4.2. The result of this integration<br />

enabled <strong>the</strong> majority of ARPAnet sites <strong>to</strong> connect through TCP/IP. Along with its<br />

status as a government standard, TCP/IP's wide use in <strong>the</strong> UNIX operating system<br />

ensured its place as <strong>the</strong> de fac<strong>to</strong> <strong>network</strong>ing standard.<br />

Layer 3: IP Pro<strong>to</strong>col<br />

The IP pro<strong>to</strong>col is responsible for <strong>the</strong> delivery of datagrams. A datagram is a block<br />

of data, "packaged" by <strong>the</strong> upper layer pro<strong>to</strong>cols for transmission. This data is<br />

"packaged" by <strong>the</strong> Upper Layer Pro<strong>to</strong>col (ULP). The contents of this data can be TCP<br />

or UDP transport data or <strong>the</strong> transport layer data of a different <strong>network</strong>ing pro<strong>to</strong>col,<br />

such as AppleTalk or IPX. IP is uninterested in <strong>the</strong> type of data it is providing<br />

delivery for and can accommodate any Layer 2 packet size limitation, which it<br />

handles by fragmenting <strong>the</strong> datagram in<strong>to</strong> <strong>the</strong> supported Layer 2 frame size. The<br />

datagram fragments are <strong>the</strong>n transmitted <strong>to</strong> <strong>the</strong> destination host where <strong>the</strong>y are

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!