Ethereal-dev: Re: [ethereal-dev] Dissector dispatching

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Tue, 9 Nov 1999 21:32:15 -0800 (PST)
> I've been thinking about how to handle dynamic dissector "handoffs"
> or "dispatches". There are sometimes that one wishes to have the
> called protocol register itself with the caller, as in a UDP or TCP
> protocol registering itself with a UDP or TCP dispatcher.  This is
> what I described in my e-mail that Guy copied to this list. This would
> be ideal for loadable modules
> 
> But like Laurent mentioned in his e-mail from a few weeks ago,
> there are times in which you want the calling protocol to do all the
> work of registering callee protocols. For example, dissect_ip is
> called from ethertype.c (llc, ethernet), ppp, raw, and X.25. It would
> seem to me that we want each of those protocols to register the fact
> that it can call IP, and not have IP have to worry about registering
> itself with all of these.

If the callee is to register itself, unless it's a "heuristic" dissector
such as GIOP or ONC RPC, which wants to get handed the payload of *all*
frames that aren't matched by a non-heuristic dissector, and return an
indication of whether the payload is its type of packet or not,
presumably it needs to know what field its caller would look at in order
to determine whether it's that type of packet or not; would that imply
that it needs to know inside which protocols it can be encapsulated?

If so, that suggests that the distinction between "callee registers" and
"caller registers" is a distinction between that can only be
encapsulated inside particular protocols (e.g., a protocol that can only
fit inside UDP, or inside TCP), and protocols that can fit inside an
expandable set of protocols (e.g., IP).

However, I could imagine a loadable dissector for a protocol that fits
inside, say, Ethernet or SNAP-encoded protocols, in which case that
protocol would have to register itself with "ethertype()" - so
"ethertype()" would, in addition to registering IP as something it
calls, have to allow other protocols to register themselves as something
it calls.

I.e., either a dissector is responsible for registering itself with its
callers, or relies on its caller to do so - but it's not necessarily the
case that either a dissector is reponsible for registering its *callees*
or relies on its *callees* to do so.

(Note that this wouldn't work if a protocol registered itself by
specifying a display filter expression - that dissector would have to
know to register an expression that checked "eth.type" and "llc.type"
and "vlan.etype" and so on.)