OSDev.org

I had finished my simple os. It currently support floppy driver only with fat12 file system.

I like to start programming for network support to learn more.

I dont know where to start.

I have a raw idea, but i don't know whether my idea is right!
I think first I want to write a driver for rs-232 (serial port controller).

I don't know what this driver is going to do?

I'm confused with these term's (rs232, modem, ethernet card) when combined
I have lot's of doubts with these three things.

Let me tell what I know about these three. And then I raise my doubt's

rs232,
- a programmable controller for serial port in mother board.
modem,
- used to connect with the internet.
ethernet card.
- used to connect a computer with the LAN.


My doubts:
1. Can both modem and ethernet card can present in the same system.

2. cpu --> rs232 --> modem(or)ethernet-card is this the way of connection.

3. Should I write a single driver for both rs232, modem and ethernet card or separately.

Please make me clear bcoz this is my academic project.
please answer or help me with some links.

thanks in advance!

Hi,

Prabu wrote:I think first I want to write a driver for rs-232 (serial port controller).

I don't know what this driver is going to do?

Serial ports are a good way to start - well documented, etc. Start by writing code to detect them, then add more code so that other software can initialize them (set baud rate, number of bits, etc). After that write code to send a byte and receive a byte. Then (to test if it's all working right) write yourself a simple dumb terminal and connect 2 computers together (so what's typed in one is displayed on the other), or alternatively you could do a serial mouse driver.

Prabu wrote:Let me tell what I know about these three. And then I raise my doubt's

rs232,
- a programmable controller for serial port in mother board.
modem,
- used to connect with the internet.
ethernet card.
- used to connect a computer with the LAN.

Close, but not quite. RS232 is one of the many electrical standards used to transfer data over a serial cable - it goes into what voltages are interpretted as 1 and 0, synchonizing (start and stop bits), timing, what each pin on the connectors are used for, etc. You don't really have to worry about any of that (the serial controller chip handles it all for you).

The term "modem" is short for "MODulator/DEModulator". Because normal phone lines aren't designed to handle DC voltages (like ones and zeros) the modem converts the digital signals into audio tones that are suitable for normal phone lines. This is called modulating the signal (the demodulating part is the reverse). This is just an example though - the same technique is used (at higher frequencies) for a lot of things. A normal phone line type modem does this for data being sent/received, but it also has additional control sequences for dialing phone numbers, hanging up, etc.

An ethernet card is a bit different (AFAIK it uses multiple modulator/demulators at different frequencies to handle much more data at once). An ethernet card doesn't deal with normal phone lines (it's used to connect local computers together) so it doesn't need all the phone dialing & hanging up stuff. Because it can handle much more data it doesn't send/receive data one byte at a time (like the serial/modem) - instead it sends and receives complete packets of data which saves a fair bit of overhead. Also most ethernet networks connect multiple computers together (rather than just 2 like serial), so there's additional things at the start of a packet to determine who is meant to receive the packet.

Prabu wrote:My doubts:
1. Can both modem and ethernet card can present in the same system.

2. cpu --> rs232 --> modem(or)ethernet-card is this the way of connection.

3. Should I write a single driver for both rs232, modem and ethernet card or separately.

I've got a server next to me that's got 3 ethernet cards and 2 serial ports that I can plug modems into (just about all computers have one or 2 serial ports). Back 10 years ago internet service providers used banks of modems for people to dial into (e.g. 24 modems on a single computer). Often this computer was connected to other computers via ethernet (e.g. a router which was connected to an ISDN modem). There's no fixed limit to the number of serial ports and ethernet cards you can have in your computer (other than the number of PCI and/or ISA slots you've got).

Serial ports and ethernet cards are completely seperate, connections could look like:

CPU <-> bus <-> serial port <-> bus <-> CPU

CPU <-> bus <-> serial port <-> mouse

CPU <-> bus <-> serial port <-> modem <-> phone line <-> modem <-> serial port <-> bus <-> CPU

CPU <-> bus <-> ethernet card <-> ethernet card <-> bus <-> CPU

CPU <-> bus <-> ethernet card <-> hub/switch (with many computers attached)

I'd write one driver for all common serial port controllers (there's some minor variations, mostly with FIFO buffers). Ethernet cards aren't standardized, so you'd need around 20 different drivers if you want to support most of them. For modems figure out how they work first (I'd use a seperate driver, but I'm like that - it depends on what you want your OS to do).

Once you've got drivers working you'd need to look into common protocols - IP, TCP, UDP, PPP, etc. For e.g. a modem connected to the internet usually uses PPP, but there's IP on top of the PPP, and TCP & UDP on top of the IP. Then there's higher level protocols like FTP, HTTP, Telnet, NNTP, SMTP, POP3, etc than run on top of TCP and UDP.


Cheers,

Brendan

Brendan, that was a well written explanation .

Dex4u.

Thanks Brendan,

I have some more queries to be cleared,

I want to write and test the "network" related things in my college lab.

There we have around hundered computers connected as LAN.
Every system has an ethernet card (I think) and connected with hub. Windows NT is running. If I want to test in this environment. What to do? I can get two system's to test.

At the end using these two system's I want to send a character from one and recieve it from other.

1. Does each system have an unique ID? If so how could I know those ID's.

2. If I want' to send a character from one system and collect it from the other one. How could I start my work in this complex(for me) network.

3. What is the next thing that I want to do?

I think I want to know the type of the ethernet card and write a driver for it!

please help me!
I love to learn more like u people in this forum!

Brendan wrote: An ethernet card is a bit different (AFAIK it uses multiple modulator/demulators at different frequencies to handle much more data at once).

Not quite. The Ethernet card actually sends digital signals along the line. E.G. a "1" is often encoded as a -5V/+5V transition and a 0 as a "+5V/-5V" transition (for instance). A serial controller just allows you to transmit characters from one system to another while the network card transmits frames (blocks of bytes) to a Local Area Network that will have the responsibility of delivering that packet to the machine that matches the frame's destination MAC address (not the same as the IP address!)

Imho, writing a driver for a PPP/SLIP over a modem connection or for an Ethernet card is a quite different challenge, and designing a TCP/IP stack should rather rely on an Ethernet card than on a serial driver (simply because in order to do TCP/IP through a serial modem, you need first to emulate the behaviour of a network card on that modem ;P )

Hi,

Prabu wrote:I want to write and test the "network" related things in my college lab.

There we have around hundered computers connected as LAN.
Every system has an ethernet card (I think) and connected with hub. Windows NT is running. If I want to test in this environment. What to do? I can get two system's to test.

At the end using these two system's I want to send a character from one and recieve it from other.

1. Does each system have an unique ID? If so how could I know those ID's.

Each ethernet card has it's own unique 6 byte ID that's built into the card itself. At the start of every packet there's a destination address and source address. The destination address can be set to "broadcast" so that it goes to everyone. Usually when networking is being started a computer will send a broadcast packet saying "I'm here" and any computer running software that understands it will respond with a packet saying "Good, so am I". From these packets each computer builds a table of valid destination addresses. The format of the packets depends on which protocol/s the software is using.

Prabu wrote:2. If I want' to send a character from one system and collect it from the other one. How could I start my work in this complex(for me) network.

First, you can't send a single byte - you have to send a variable sized packet that is at least 46 bytes long (and no longer than 1500 bytes). The actual format of this packet will be determined by which protocol you're using. Common protocols are IP and IPX. In general at the start of each packet (after the source and destination addresses) there's a "type", where each type specifies the protocol used for that packet. This allows different protocols to be used over the same network.

I'd forget about protocols for now and just write a "packet sniffer". The idea would be to display the data from any received packets. IMHO this is a good easy way to make sure your ethernet card driver is receiving packets but it can also be a useful tool for debugging when you start transmitting packets.

For the ethernet driver there's 3 basic functions - initialize it, receive packets and send packets. Specifics depend on the ethernet card, but most use a pair of "ring buffers" (one for sending and another for receiving) which are used with DMA. When the ethernet card is sending data it reads the data from the current position in the transmit ring buffer directly from memory. When it's receiving a packet it writes the data to the current position in the receive ring buffer.

[MESSAGE TOO LONG - CONTINUED IN NEXT MESSAGE]

[CONTINUED]

Prabu wrote:3. What is the next thing that I want to do?

After writing the packet sniffer you'd probably want to implement one of the protocols (IP most likely) to run on top of it. Once you've got IP implemented you'd move on to TCP and UDP (which goes on top of IP). Often the code for TCP and UDP is built into code that does IP (for better performance). Then you can implement more protocols on top of TCP and UDP (for e.g. telnet).

Prabu wrote:I think I want to know the type of the ethernet card and write a driver for it!

The first thing you'd need to do is find the type of the ethernet card - if you've got windows this should be fairly easy (use device manager). That's not really the way things should be done though. Generally you should write software to scan the PCI bus to find out which PCI devices are present, and then use this to load any device drivers (including the ethernet card's device driver if it's present). For e.g. my OS scans the PCI bus and builds a tree of devices. Each PCI device has a Vendor ID and a Device ID which is combined to form the file name of the device driver - "drv/pci/8086-100E.drv" would be an Intel "82544XT Gigabit Ethernet Controller" device driver, and "drv/pci/100B-0001.drv" is for a National Semiconductor "DP8310 10/100 Mhz Ethernet Controller". If the driver is found the resources it will use are configured by the OS (via PCI configuration space) and the driver is started and told which resources (IO ports, IRQs, etc) to use.

In general, writing decent code to handle PCI and one or more ethernet card drivers, then the packet sniffer, IP, TCP & UDP, etc would probably take an average programmer a few years (depending on how much the OS already supports, the quality of the code, how much experience and free time the programmer has, etc).

AFAIK without writing code to handle the PCI buses first you'll be screwed as most PCI devices (except video and hard drive controllers) are disabled when the computer boots (and even then they're often setup in "legacy" mode). One way around this is to find a pair of ISA NE2000 ethernet cards (and a couple computers that are old enough to have ISA slots to plug them into). Then you could skip the PCI stuff and probe the IO ports that are commonly used by NE2000 ethernet cards. NE2000 is a common ethernet card - you'd be able to find programming information for them on the internet without much trouble.

Also you could possibly skip IP and invent your own protocol designed specifically to send and receive a single byte. If there's no bridges or routers between the computers it should work, as long as you select an ethernet packet type that doesn't interfere with existing packet types. This protocol would need to handle "discovery" - finding the ethernet addresses of other computers that understand the protocol (those "I'm here" broadcast packets). This would be much faster to implement if the only thing you ever want to do is send and receive single bytes.


Cheers,

Brendan

Thanks Brendan !