John Smith writes:
> >- We'd need to enhace the definition of a netgraph address
> > to include, say, an IP address, eg.:
> >
> > $ ngctl msg 192.168.1.12:foo: blah blah
>
> Well, I was thinking about this. I would like to share
> this pre-idea and to receive your opinions.
> I have one question here. Why should it be limited
> to UDP... (or whatever protocol)? Are we going to
> loose something, if we, say, create special node
> for 'netgraph tunneling' (so that it may ot may not
> be included into a running kernel) then connect
> this node to another one, which will be used for
> 'transport' layer. Such a node could possibly be
> used to encode/decode the inter-netgraph messages.
> Other nodes' names then should include
> the transport layer address. This way I think we
> won't get limited to one protcol...
Your idea of being protocol agnostic is more general.. however,
there is a slightly larger problem I didn't mention before.
Address syntax is parsed by the base code (ng_base.c). The
syntax of an address is not something an individual node gets
to decide.. so there are two possibilities..
You could do multi-host netgraph using a "private" addressing
scheme, simply by defining a control message that contained inside
it an IP address (or whatever), a netgraph address on the remote
machine, and a payload control message. Then write a node that
knows how to (de)encapsulate these control messages and send/recv
them over the network. But then you have something like this:
$ ngctl msg relaynode: { ip=192.168.1.12 addr="foo:" ... }
instead of this:
$ ngctl msg 192.168.1.12:foo: blah blah
To get the "cooler" case #2 behavior, there would need to be
"global" knowledge of the addressing scheme, which is of course
tied into the delivery protocol because the generalized netgraph
address must contain a protocol address (IP address or whatever).
Now.. we do have a syntax for describing a struct sockaddr of any
type (eg, ng_ksocket(4) node). So the protocol address could just
be an ASCII struct sockaddr and that would be as general as it gets.
-Archie
__________________________________________________________________________
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
