we should clearly define if we want to build a router or a host system. Even if linux kernel offers both, i don't think a hobby os should address routing packets. If your host(desktop/server/whatever) OS makes it to a point it start routing packets, it's no longer a hobby OS, imho.
btw, if a non-multicast router receives a request for a multicast join/prune IGMP message, that message is simply dropped (or at best, the emitter receives a ICMP error message). Same occurs for a router that receives a multicast packet: the packet is dropped or leads to a "no route to host" because the router has no table entry about that destination.
what do you exactly call "the fields of Multicast" ?? afaik, the only thing that distinguish a multicast packet from an 'ordinary' packet is that its destination address belongs to the multicast addresses range (must be class E or something)
http://www.networksorcery.com/enp/protocol/ip.htm
TCP/IP
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:TCP/IP
Ok, didn't know you could be that rude to them. In that case, just be able to detect what addresses are not around and dump them.Pype.Clicker wrote: btw, if a non-multicast router receives a request for a multicast join/prune IGMP message, that message is simply dropped (or at best, the emitter receives a ICMP error message). Same occurs for a router that receives a multicast packet: the packet is dropped or leads to a "no route to host" because the router has no table entry about that destination.
class D to be precise, or in modern terminology, 224.0.0.0/4. And the fields I'm referring to are indeed source and dest. Sorry about the confusion.what do you exactly call "the fields of Multicast" ?? afaik, the only thing that distinguish a multicast packet from an 'ordinary' packet is that its destination address belongs to the multicast addresses range (must be class E or something)
http://www.networksorcery.com/enp/protocol/ip.htm
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:TCP/IP
No. I wouldn't advise that. For sure i hope we'll all use IPv6 some day, but IPv4 is still there for a couple of decades. Trying to support both from the start would only lead to code confusion and hard-to-test systems (unless you can come with a full IPv6 testbed at home: routers, servers, clients etc.)DennisCGc wrote: Anyway, if you're going to implent TCP/IP, be sure you're going to implent IPv6 also.
It hasn't to be done immediatly, but it is advised to do it
Keep it for ToDoDreams. Really. Or pick up a kernel that exists and offer it IPv6 if that's what you wish.
Re:TCP/IP
I should mention ( :-[ ) that it's pretty difficult to implent, since I read the RFC.
I advise to do that, for those people that wants that their OS runs on companies, and that.
And I should mention too, that is not neccesary for now, but for in the future.
IPv4 runs for a couple of years, I think, but migration should be neccesary then ::)
I advise to do that, for those people that wants that their OS runs on companies, and that.
And I should mention too, that is not neccesary for now, but for in the future.
IPv4 runs for a couple of years, I think, but migration should be neccesary then ::)
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:TCP/IP
just found my favourite book about TCP and networking avl. online.
http://www.cs.arizona.edu/llp/book/book.html
http://www.cs.arizona.edu/llp/book/book.html