OSDev.org

I have done a very superficial search about how I can implement tcp/ip networking stuff into kernel and I very sadly realized that writing tcp/ip thingz can take lots and lots of time (lots of details unveiled in rfcs, lots of time critical details in networking, also I am still kinda lack of info on networking ) so I checked what other people do and I saw that people tend to use ready to use implementations, well I have downloaded OpenTCP and I think I can give it a try. Well did anybody try to use some other sources about networking? I am not very used to using these, did anybody use opentcp or other libraries? Any link, resource is highly appreciated. Also I could not do a search in mega tokyo-Im very short in time :-[ right now- but as far as I am concerned with this forum, tcp networking was not discussed here in depth. Any ideas, no matter what, are appreciated. Thanx in advance.

Hmm, I thought about it, and I'm not going to do that.
I get all my information from the rfcs, and I use Ethereal a lot to analyse the network traffic what the computer gets and sends.

Well, its ok to use the rfcs but tcp is divided between some rfcs and total of these rfcs exceeds my reading capabilities. About analysing network traffic, I dont know how ethereal works but I think it wont work becuase it is really hard to get what is going on in actual network channel I mean lost or delayed packets, taking care of acks, timeouts, ... , it can be done but it'll really be very very hard. I am also on side of writing tcp from scratch but I dont know a tool to simulate it. Bochs does not support networking, does it?

DennisCGc wrote: The question is already there, the answer has to be found aka the meaning of our lives.

The answer is 42. You just don't know what the correct question is

Douglas Adams - Hitchhikers guide to the galaxy

Note that you probably won't even get a connection with your ISP if all your TCP/IP stack can do is what's defined in the RFC's.

TCP/IP is probably among the most "polluted" protocols in existance. Different vendors introduced different extensions, which became mainstream without ever making it into any RFC.

I can't be more specific; it's a tidbit I noted down in a discussion regarding Miami, the then-most-popular TCP/IP stack for AmigaOS.

Well, one of my main concern is creating a client which means getting an ip from your isp. There are several ways that one can be connected to internet so it is really hard to handle all cases -most of which are really apart from tcp networking subject-, this is why I will try to go in this ready to use implemented ways and only supply modem driver, if it is necessary.

The networking stack is certainly a task as huge as the kernel itself... fortunately enough, as it's subdivided into chunks that can be implemented quite independently from each other ... For instance, your IP module doesn't mind whether TCP Reno, TCP Tahoe, UDP or SomethingElse is running atop of it ... it just send and receives IP packets and deliver them to the proper instance of the upper layer.

And DHCP (which is the stuff that gives you an IP address automagically when you connect) almost doesn't need IP packets iirc .

For those that want to delve in the dark deepness of network implementation, i suggest the reading of "Computer Networks -- A System Approach", which really focus at what a designer should take care of. It doesn't address the latest refinements of the TCP/IP protocol suite, but at least it does offer a comprehensive view of things that need to be done ... a kind of large-scale roadmap for further RFCs ...

Ozgunh82 wrote: Well, one of my main concern is creating a client which means getting an ip from your isp. There are several ways that one can be connected to internet so it is really hard to handle all cases -most of which are really apart from tcp networking subject-, this is why I will try to go in this ready to use implemented ways and only supply modem driver, if it is necessary.

The short summary of the protocols you need at least, for just about all providers:

IP
TCP
UDP
DHCP
ARP
RARP - not sure whether required but very nice to have anyway
ICMP - for testing it's always useful, and for nice IP implementations too

Implementing all of these should take you a year or two, give or take a few. That is, if you're reasonably fast at programming, and are educated in the minor idiocracies in the protocols. Note though, that TCP doesn't specify whether it's Reno, Tahoe, or SomethingCompletelyDifferent?.

The optional protocols you may or may not need:

PPPoE
PPP at all, for modems
Modem driver
Winmodem driver - this is tough
serial port driver
network card driver
ethernet driver
QoS - some providers might require it

Note to DF or somebody who can - being able to link to the wiki easily from the forum would be a very big plus, it'd allow proper linkage. Also, making forum threads more integrated in the wiki would be a nice idea, it'd avoid double work.

For a 'demonstration' implementation, i suggest one starts with a 'local LAN' implementation first ... Try to send bare Ethernet then ICMP or UDP packets (atop of IP, of course) to an existing stack (which you have sources of and which is able so sniff packets that come and go) on a regular twisted pair

I don't know much about 'ordinary' modems and i discourage anybody to try to use winmodems (you will *not* succeed. There's no information about them. Your only chance is to reverse-engineer the window-driver :-/)

I also discourage attemps to implement PPPoverEthernet (cable modems require it) or PPPoverATM (ADSL requires it). Try to get one of those gateways that you can plug between your machines and your xModem so that all appears as if you were simply using IP on good old Ethernet ...

TCP should be kept for the final cherry Make sure you understand it *perfectly* before you try to write its code. I'm talking about RTT estimations, slow start and all those stuff ...

Well, it seems that I will use the OpenTCP or something similar that is already implemented. I am very interested in tcp becuase of the fact that tcp leaves the control of flow to client side, that is you can try to push your network to the extent you want, problem is that it is left to operating system and in fact you cannot change it in windows... Anyway but I think I can trace the implementations and try to change the slow start, fast recovery algorithm implementation (tahoe, reno, vegas...) in the way I want so that I can try to create congestion ;D in my isp's routers... Well this is just an idea for now, but I am very keen on trying it.

Most ISP will have some "traffic policer" at their first router, checking that you don't go above your Maximum Sustainable Traffic Rate and randomly drop/queue some of your packets if you do so

I'm not sure at all breaking TCP rules will offer you improved service, and one single flow is unlikely to make any congestion on an uncongested network ... If you need a 'support my rate and drop packets if you feel so but don't delay me with retransmissions', UDP/RTP is the thing you'll prefer. Most realtime multimedia streams use this, afaik.

Note that you probably won't even get a connection with your ISP if all your TCP/IP stack can do is what's defined in the RFC's.

TCP/IP is probably among the most "polluted" protocols in existance. Different vendors introduced different extensions, which became mainstream without ever making it into any RFC.

Yeah ?
Really ?
I don't think so, because an OS couldn't connect to the internet then.
To get the relevant information you should use the RFCs and a sniffing program like Ethereal.

UDP/RTP is the thing you'll prefer. Most realtime multimedia streams use this

I agree with that.
The first I'm going to implent is IP/UDP, since it's easier to implent

DennisCGc wrote:

TCP/IP is probably among the most "polluted" protocols in existance. Different vendors introduced different extensions, which became mainstream without ever making it into any RFC.

Yeah ?
Really ?
I don't think so, because an OS couldn't connect to the internet then.

Yes, really, and at least one person who has implemented a full-blown TCP/IP stack will tell you so out of personal experience (Holger Kruse of Miami fame). (Well, he told me... don't try to contact him, though, he was last seen pretty busy at REBOL Inc..)

There are many broken implementations out there that are widely used. You may comply to every RFC there is, but "compliant" doesn't equate to "functional". Think SAMBA - another protocol that's based on "this is how it works" instead of "this is how it's specified".

Of course the RFC's are the point to start, just don't expect the work to end there.

Solar wrote:

DennisCGc wrote:

TCP/IP is probably among the most "polluted" protocols in existance. Different vendors introduced different extensions, which became mainstream without ever making it into any RFC.

Yeah ?
Really ?
I don't think so, because an OS couldn't connect to the internet then.

Yes, really, and at least one person who has implemented a full-blown TCP/IP stack will tell you so out of personal experience (Holger Kruse of Miami fame). (Well, he told me... don't try to contact him, though, he was last seen pretty busy at REBOL Inc..)

If I use a sniffing program, the format of the package is the same as described in the rfcs.

There are many broken implementations out there that are widely used. You may comply to every RFC there is, but "compliant" doesn't equate to "functional". Think SAMBA - another protocol that's based on "this is how it works" instead of "this is how it's specified".

Where is it used ?
How could the OS work with it ?
(And no, don't say: a program is involved to do this (or something alike))

i think we should make a clear distinction among TCP, IP, EveryThingAboveTCP (where many software vendors disagree) and EveryThingBelowOrAsideIP (like security/performances improvements, where many hardware manufacturers disagree).

I haven't find proofs of pollution within TCP nor within IP so far: the base protocols (that the OS designer must take care of) were quite clean and as someone working in networks, i'd be pleased if someone had evidences of this.