Right. So this looks old. Who on earth is using DOS and or would be trying DOS networking in this day and age. Either there's Windows : click Next - Next -Next - Finish and your connection is configured. To use it, click on the icon. Or you're a Linux fan - why mess with DOS if you can have Linux ?.
You're right. It's just that ... I want to understand what happens behind the screens when Windows connects me to the internet or to a network. Messing with DOS and DOS networks proved very helpful in that regard. And DOS is easy to play with. It's limitations keep a beginner from getting lost. And I hope (in fact, I'm quite sure) that getting (DOS) experience with command prompts and text files for configurations etc. will also prove helpful when I'm ready to tackle Linux.
I'll start with the theory, so we're done with that and we can go the the interesting part where you actually get to do something. You kan skip this part and go to one of the subjects in the table of contents - you don't really need this theory. But it can help you to understand what you're doing.
When using a network, you'll be working at your own computer (usually called 'local'), but doing something on another computer (the 'remote' machine) : you'll want to open a file or run a program on the remote machine, copy something from the remote machine to your computer or vice versa, etc. In order to do so, the local machine and the remote machine need to communicate. Typical examples : You start a web browser on your machine to open a web page at e remote machine (the web server). Or you have Microsoft Excel on your desktop computer in the office where you work, and you use it to open, modify and save an Excel Worksheet on a 'file server' somewhere else in the building. You do that across the network - but how does the Microsoft Excel on your computer explain to the file server two floors down what WorkSheet needs to be opened / modified / saved /... ?
this is easily understood with this picture. Imagine two people, on separate locations, each speaking a language thet the other doesn't understand, exchanging information with each other through translators, secretaries and a fax.
Although the communication appears to be happening between the two managers (they are exchanging information with each other), the real communication goes down through different layers on one site, then through a physical connection (the fax line) to the other building, then up through all the levels of the other building to the manager. Who can then give a reply to the message he just received, which goes the through all that again.
Both the OSI and TCP/IP model are 'models that explain datacommunication between compyters in a similar manner ; communication goes through layers on the local machine, through a fysical connection to the remote machine, then up all the way throug a range of leveles again. Looking at networks and datacommunication with this 'layer' model in mind helps to understand what you're doing, and where things have gone wrong if you get an error message or an unexpected reply.
Apart from 'describing' a network in terms of layers or levels, the OSI model was also intendend to prescribe standards for equipment and software. It would prescribe in detail how a protocol (software) on level 1 (the secretary) should communicate with software on level 2 (the interpreter) - e.g. the the interpreter has to deliver his translated message to the secretary on a sheet of white paper, in black ink, and leave 1 inch (2.54 cm) at the top for a faxnumber. That did not work out completely well, as another model, the TCP/IP reference, appeared on the scene. However, as tools to understand networks, they are both very useful, and show remarkable similarities.
A remarkable, interesting aspect of these layers (levels), is that they seem to work independently from each other. E.g. Interpreter A in the picture knows that he has to translate the English from his master in to Dutch, and that he has to write it down (in black ink, etc), then give it to the secretary. He does not need to know (or worry about, or interfere with) the way secretary A gets the message to secretary B. She can fax it, send a courier, hand-deliver it herself or use pigeons, it does not matter at all. What matters is that it's on paper (so it can be carried in any of the formentioned ways), that it's written in black ink (so if the secretary chooses to fax it, it wel be legible), and that it is in Dutch - because that's a language interpreter B understands an can translate in to the French that his philosopher-chief speaks.
In Network terms, this is referred to as interfaces and protocols.
Protocols refer to the communication between peer processes : the interpretors all speak dutch, so they'll always understand eachother, no mather what way the message reaches them and no matter what languages they'll have to translate it into.
Interfaces describe how one layer communicates to another (white paper, black ink, room for a fax number)
To view a web page (a html document), you use a web browser. What happens is that the browser sends a HTTP (Hyper Text Transport Protocol) request to a web server. The webserver replies by sending the desired web page : a text file with html code. The browser receives the html code, reads it, and generates ("renders") on your monitor the web page as described by the html code. Browser and Web Server communicate using the HTTP protocol. The Browser doesn't know, and doesn't care, whether your connected to the internet through a modem, via ASDL or via a cable modem. You might even be watching a page on the intranet of the company where you work, so your connected to the server over a local area network. He does not mind at how many bits per second you're connected. He also does not care how the request (and the reply) travel from your computer to your Internet Provider's Server then on to the server where the web page is, and back again. All your browser does is send the HTTP request ("get me that page") and wait for the reply. All steps inbetween (make a connection, agree on a transmission speed, solve all these problems about addresses - how does the request get to the right server ? - and media -telefoonwire from your PC to your internet providers server, then maybe glass cable fiber or coax cable from that server to the actual server where the web page lives, etc), all that is handled on one or more of the underlying layers. .
0- The OSI model describes 7 levels in datacommunication. The actual, fysical connection (the wire, the infrared waves, or whatever other medium) is not included in the protocols.
The proyocols of the physical level describe how data is transferred over a medium : how is does the sending machine put bit on a telephone wire ? on a serial cable ? on an infrared light wave. And how does the receiving machine read them ? How many volts is a 1 ? How much time schould there be between two bits ? Think : modem protocols, serial ports, ethernet, Token Ring...
On the fysical level, the datacommunication is directly limited by the fysical properties of a wire. A a cupper wire can only take so many changes per second, so there's a fysical limit. Exceeding this limit will result in loss of data : The receiving machine will not be able to 'read' certain bits. Datalink protocols add error detection, error correction, and flow controll. The bits are sent per frame (a given number of bits). ACK (Acknowledgement frames) are sent back by the receiver to indicate that a frame has been received. Extra bits are added, such as parity (error detection) or error correction codes.
PPP (Point to Point Protocol) is one of the protocols that describe a datalink with an internet provider. This protocol is more or less the standard for transporting TCP/IP over serial lines, and thus often used to connect to an internet provider over a serial line (a modem connection) in stead of trough a network interface card. The standard includes a link control protocol, LCP, which negotiates parameters of the connection such as maximum packet size (MRU), security through PAP or CHAP, line quality monitoring, loop detection, and protocol header compression. It's also very useful to obtain an IP address for your computer when you use a modem to connect to the internet. (Have a look at PPP at work).
In addition to LCP, PPP includes one or more Network Control Protocols (NCP) to negotiate and transport network layer protocols over the link. IPCP is the NCP for the Internet Protocol (IP). Another NCP is IPXCP(RFC1552) which transports IPX, the Novell network layer protocol.
PPP specification : RFC 11661
Hides the technicalities of the datalink. Ensures a connection between machines (from one address to another), over a number machines in between if necessary
Ensures datatransport : if frames (packets) are taking different routes across the network, the transport layer checks if all frames have arrived, removes duplicates if necessary, and puts them in the right order.
On the session level, the dialoog between two processes or applications is being coordinated.
The presentation layer handles things like compression and encryption.
At the application level we find the application protocols that need to communicate with their counter parts at a remote machine. The user will mostly only see the 'front end'. E.g. HTTP is an "apllication protocol", the user will use a HTTP-client : a web browser.
Although OSI and TCP/IP are sometimes seen as competing standards (and TCP/IP won), they can also be regarded as different ways of looking at the same thing : networks. Both the TCP/IP model and the OSI model look at networks in layers. Each layer in the TCP/IP model corresponds to a level in the OSI model. The 2 most important differences are
1- The TCP/IP model is very Internet-oriented, although TCP/IP protocols are also used in Local Area Networks. The OSI model is a more general standard, applicable to any network.
2- The TCP/IP model 'skips' a few levesl. The most opvious is that TCP/IP starts at the 'IP'-level - which is similar to the 'network' level in the OSI model, thus skipping the fysical level and the datalink.. That means that TCP/IP does not really care how a machine gets connected to a network. It assumes that, one way or another, you' get on a network that's capable of carrying IP packets in a sufficienly error-free manner. How that is achieved is irrelevant in the TCP/IP model. If you can figure out a way to make carrier pigeans transport IP packets, you can use those. (This was actually tried succesfully ...see CPIP RFC).
Corresponds with the network layer in the OSI model. The Internet Protocol defines that packets (of a given size) travel across the network. Each packet carries its own origin and destination address, the IP layer (the network) needs to identify the hosts on the network (IP adresses) and send the packets in the right direction (routing).
Corresponds to the network layer in the OSI model. TCP describes how a bit stream from the sending applicaztion schould reach the receiving application. Identifies these applications by 'TCP port number'. Reassambles data deliverd in IP packets and puts them back in the right order.
An other protocol on the transport level is UDP -User Datagram protocol. Is used by applications hoe do not require the accuracy of TCP, either because the application itself takes care of the tasks TCP would perform, or they'TCP-like services are not needed (e.g. applications where speed is more important then accuracy : if a packet get's lost, its contenst will be obsolete before the lost data can be replaced and re-sent, so there's no need to send it again.)
SSL describes encrypted data transport between a "client" and a "server".
Protocols on this level use the network and transport functionality of TCP/IP to communicate with ther counter-parts (peer processes) on remote machines. Typical protocols : HTTP (Hyper Text Transfer Protocol), DNS (Domain Name Service), SMTP (simple mail transfer protocol), FTP (File Transfer Protocol) etc.
Often datacommunication follows a client-server model, where one application requests a service from another application. The requesting application is then called the client, the application that provides a service is called a server. So we'll have mail serveers and mail clients, both implementations of SMTP, FTP clients and FTP servers (a.k.a. FTP daemons), HTTP clien applications (web browsers) and HTTP server applications (Web servers), etc.
Opposite to client-server, there's "Peer-to-Peer", where the communicating processes/applications both serve and benefit from the relation.
Combining the concept of layers with what we now know about packet headers, it is easy to understand that, in the local machine, headers and trailers are added at every level. The resulting bitstring (frame, packet) is then sent to the remote machine. On the remote machine, at each level the information in the header is read and used for whatever it's purpose is, then the header (and trailer) is stripped from the packet and the packet is passed on to the next level, where the same thing happens again, until the receiving application or service receives the data that were originally sent by the sending application.
On the following pages, We'll discuss setting up datacommunication / networks between DOS and Windows machines, and talk about internet connections and applications that can be run over a network. This theory about layers, protocols, interfaces and packet headers will help you understand why you have to do what the manual/howto telss you to do.