--- Niels Möller <[EMAIL PROTECTED]> wrote: > Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> > writes: > > The interface for reading raw ethernet frames should > primarily filter > on ethernet type code and ethernet addresses. If > there are several > processes (say, two completely independent > ip-stacks) that want to use > the same ethernet hardware and the same ethernet > address, then the > simplest way is to have the ethernet driver deliver > each received > frames to *both* processes.
With two in-dependent ip-stacks you'll probably need to do more work on the socket interface, as each would act on every call to any function of the socket API. Besides, a stack started after another wouldn't know about the currently exsisting connections and would probably tear-down connections with RST or FIN packets (assuming TCP) to the sending host, while it shouldn't have, the case of having two seperate stacks implementing the same L3 protocol on the same NIC doesn't seem feasible to me, nor usefull. > Or you can do something more clever with filters > that look into packet > contents (I've heard that some network cards even > has some hardware > support for that), but if you do that I think you > want a nice general > interface, and not code knowledge about the inside > of ip packets into > the ethernet driver. Well, smart NICs support hardware classification, and you could implement the hardware-type/mac-address registration in either software or hardware thru the same interface assuming device drivers will have some logic (well, they will anyway, atleast to support multiple protocol-stacks they'll need to do some basic early demultiplexing). One nice (patented) apparoach taken by Solidum[1] is to give their NIC a packet description in a high-level language to tell it what you're interested in. The patent prevents you from using *their* language to do it, but it doesn't mean you can't do it in another form, infact Cisco sells PDLM modules for their high-end routers nowadays. > > But that is why they register their IPs with L2, > isn't it? You need the > > same for an ordinary ip packet. > > They layer 4 code will register the ip addresses > it's interested in, > in some way or the other, with the layer 3 code. Doubt that, it'd be nicer if they just register themselves by providing a function that'd be called whenever the number they're interested in appears in the IP-protocol field. I don't see why a L4 transaltor would want to view/ignore any specific packet. > But > I don't think the > layer three code should need to know about port > numbers (just like I > don't think the ethernet driver should need to know > about ip > addresses). In both cases a general interface for > matching packet > contents would be nice, but it shouldn't be added > unless it's really > needed. It could be done, but its use would be optional to every translator (and the one below it). One previous ULN used a function that took a packet anda description as arguments, it returned a parse tree of the packet's contents, this -as stated in the project's presentation- reduced protocol development time while having acceptable performance, the main point was that TCP/IP wasn't complicated (and thus never needed such an apparoach) but other protocols are and such an apparaoch would save protocol developer's trouble with offsets, alignment, bit-shifting etc.. People are weird. Anyway, it seems weird to discuss any implementation wories now without having a basic design for the buffer pool manager, the packet format (anyone recall all those flame-fests about mbufs vs. skbs?), reducing the amount of context switches (going back and forth between the stack and device driver) assoctiated with routing in ULNs? etc.. [2] We shouldn't argue how L4 translators(or modules for that matter) would interact with L3 when we don't even have a decent interface for buffer handling. Just my opinion, kotry [1] http://www.alternic.org/drafts/drafts-n-o/draft-nossik-pax-pdl-00.html [2]http://www.zib.de/hupfeld/Diplomarbeit.pdf > 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. > > Regards, > /Niels > > > _______________________________________________ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
