Olivier Péningault <[EMAIL PROTECTED]> writes: > le ven 25-10-2002 ā 10:25, Niels Möller a écrit : > > Sure, but do you really want them to run fully separately? It's common > > (although not required by any standard, afaik), that an ipv6 socket > > bound to the ipv6 wildcard interface should be able to accept ipv4 > > connections. > ... Then, it is the responsability of human to decide on which > interface(s) the program will bind.
I suspect your missing my point. An applications wants to bind the ipv6 wildcard address, and have that automagically include the ipv4 wildcard address. When a ipv4 connections arrives, the accept() on the ipv6 should return the ipv4 connection, with addresses represented as ipv6 "mapped" addresses. What component will do this mangling? Probably pfinet/hurd-net is the right place (unless you do all the work of bind in the user process). > I don't agree. According to RFCs, arp is a generic protocol wich allows > many layer 3 protocols to find data link addresses. It is not limited to > ethernet/ip. Which media, besides (the several flavours of) ethernet use arp? In any case, I think the natural way to share arp code is to put it into a library, no extra translators needed. To replace the arp code, the user of course will have to replace the server that links to the arp library, but I don't think that's a problem. > arp has to know each layer 2 interface (maybe they will have a way to > register themselves) Why? All interfaces should have an associated network address and netmask, so given an ip address you want to reach, you always know on which interface to send an arp request. The exception being multiple interfaces to the same link, I'll have to think some more about that case. THe point is that I think of arp as a purely link-local thing. > > But in > > order to do tcp, tcp, ip and icmp are used together. I'm all for code > > separation, but I'm afraid that putting the implementations into > > separate *processes* will just add unnecessary complexity to the > > system, for no real gain. > This is a complex problem. We can offer nice features, but where do we > stop ? Which feature are more important than efficiency, and when must > we privilege efficiency against features ? Start *simple*. Don't implement the complexity until the day you're going to implement the particular feature that depends on it. (I admit I've read one or two xp books ;-) > I know that hurd-net has issues, this idea is a way to hide the fact > that hurd-net is not replaceable. My gut feeling is that what you call "hurd-net" should replace pfinet, and that it should be as hard or easy to replace as pfinet. I don't understand why you can't run several networking stacks in parallell. > I thought about these problems, and that's why I proposed to have a > "central" translator to solve this... It doesn't have to be central to solve these problems. Each instance of pfinet will have it's own ip-addresses, and manage ports for those addresses. The allocation of ip-adresses is a netadm problem, how do you prevent two different machines to try to use the same ip address? It can't be pfinet's responsibility. And if yu bind the wildcard address, you will naturally end up listening on all interfaces managed by your chosen pfinet (or do some hacking to access several pfinets in parallell). > I will think a lot about it this week end, I will read code and books, > and maybe I'll can propose an updated version of my point of view about > network re-implementation I'll try to get the time to sketch out what I think the interfaces should look like, in a separate mail. /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
