bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Networking design proposal


From: Michal 'hramrach' Suchanek
Subject: Re: Networking design proposal
Date: Tue, 12 Nov 2002 16:00:49 +0100
User-agent: Mutt/1.4i

On Tue, Nov 12, 2002 at 01:12:08PM +0100, Niels M?ller wrote:
> Michal 'hramrach' Suchanek <hramrach_l@centrum.cz> writes:
> 
> > On Wed, Nov 06, 2002 at 02:52:25PM +0100, Niels M?ller wrote:
> > > Olivier P?ningault <peningault@free.fr> writes:
> > This will be needed for routing. But for packets that are used by
> > connections to/from local machine you are usually not interested in protocol
> > specific details. But it may be easier to cope with them than designing
> > a protocol independent abstraction ;)
> 
> I'm not sure I understand this point. For local communication, one
> usually either use AF_INET socket and connect to localhost/127.0.0.1,
> thus exercising all of the ip-stack except the ethernet card, or use
> AF_UNIX sockets.
I mean connections that have one end on the local machine that is
a connection to or from the local machine. Connections over the loopback
interface do not need all the levels.
> 
> > I do not completely agree with this. Ip address is just a few numbers, port
> > is another number. You may choose to interpret som numbers in one layer and
> > other numbers elsewhere. But I do not see any reason for this as the numbers
> > are all available at the same level.
> 
> All the packet data is available to the ethernet driver, sure. The
> problem is not the raw data, but the knowledge (including code) needed
> interpret the data. If possible, knowledge of different parts of the
> chain should be isolated to separate processes.
At the level where ip address is registered ip port can be registered as well.
The ip header has to be analyzed to determine ip address and that makes it
easy to check the port at the same time.
> 
> > As for generating icmp packets: It is not very consistent if some program
> > generates host-unreachable and other connection-refused. But with your 
> > separation of ip:s from ports the knowledge about ip and port is divided 
> > unneccessarily.
> 
> I don't see that as a problem. In fact I would expect the generation
> of host-unreachable and connection-refused to usually happen at
> different *machines* (the destination of my packets, and some router
> on the (broken) path across the network, respectively). So having them
> sometimes be generated by different processes on the same machine
> doesn't seem odd to me at all.
If it has other reason than that it is the usual unix behavior I have
no problem with that :)

-- 
Michal Suchanek
hramrach@centrum.cz




reply via email to

[Prev in Thread] Current Thread [Next in Thread]