> >Hmm, you could do it that way. How about a simple system where by each > >module simply adds itself to a list of protocols it can speak, and what = > the > >function call is? They all take the same parameters, so it's not a biggi= > e. > > But you have to have a rule somewhere in order to know what protocol you = > have > just decapsulated so you know what module you want to talk to. > So in that case, either the rules would be something separate (e.g. some = > kind > of recognition library), or it would be in the lower layer. > In that case, if you want to add IPv6 for example, you have to update the= > > ethernet layer or the recognition library (with the new rule) *and* add = > an > IPv6 module. While if you have a GimmeYourRule function you can call, you= > can > only add an IPv6 module and you don't have to update the ethernet module.= Well, for instance in ethernet packets you look at the type field and decide where to send it. I mean there's no reason not to preload the ethernet module with every type of protocol to look for. If the net server hasn't got a suitable module it just silently discards the packet, or sends a suitable response. > As for taking the same parameters, well I am all for this whatever scheme= > we > choose. In my previous example we can have HereIsYourData (datastruct &) = > with > datastruct holding the guessed protocol identifier, the data itself, and > whatever useful information we may want. > We can then either directly call the concerned module or have a generic > net_input function read the guessed protocol identifier and call the modu= > le. Calling direct would be quicker but assumes a degree of knowledge of it's surrounding that it probablt won't/can't have. I mean an ethernet module shouldn't really need to know anything beyond, it's from xx:xx:xx:xx:xx:xx and was sent to me (or a broad/multi-cast) and it's of type XXXX. That's all it needs to do it's job. > > That's only ideas but they are quite important so please let's debate the= > hell > out of it :o) OK. david