le ven 25-10-2002 ŕ 11:16, Stephan Trebels a écrit : > BTW: the Plan9 approach to this separation is pretty similar: > [...] I didn't know it, it is an interessant way of implementing things.
> Personally I'd make one translator responsible for the ANY-IP > translation for a physical or virtual device, including ANY-specific > address-resolution handling (e.g. ARP on EtherNet or some ATM > flavours) if needed. This is very different for CLIP, bridged/routed > 1483 ATM, Ethernet, PPP.... ANY-IP needs to provide interfaces for > both IPv4 and IPv6, IMO. I cannot imagine a clean separation there, > and the translator graph should be a tree. I.e. I would not do > something like This might be a good approach. But I don't think the icmp issue is so important. It can be used by itself (ping), in this case there is no problem of too many rpc calls. When running a layer 4 protocol, icmp is not used very often IMHO. And when we need icmp, if it is integrated in the ip translator, it will not increase the rpc stuff, because the reply will come from the icmp part of the ip translator, instead of coming from the ip part of the ip translator. > as this would create unnecessary locking problems. I don't think so. For tcp, when establishing a new session, we open a new port to the ip translator, which remains open while the session is alive. For tcp, we can create one port while udp and ip translators are running (it is open when the first datagram is sent/received), if there is a connection context, udp will not know it, it is the program's job. > On top of the IPv? abstraction I'd put protocol abstractions, that > provide groups of protocols where similar protocols should be grouped > together. You cannot separate TCP, UDP, ICMP IMHO without sacrificing > speed. As long as the total call/RPC overhead is limited (no stack of > 10 translators until you send a frame) and not too much inter-protocol > communication needs to happen (GRE for VPNs, ...), protocol groups can > be in separate translators. Here is a big problem. Do we want speed, or do we want features (replacement of network protocols by users in a per-protocol basis). I prefer the second point of view. But you also can run a translator, with all protocols grouped, which will implement all needed interfaces. > Just an outside view of things, Stephan This is very nice, thanks. This kind of information is very usefull. "Inside views" are sometime partial... :) olivier _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
