Re: [dtn-interest] Comments on DTNRG documents from BBN SPINDLE project

Keith Scott wrote:
>>Except that an application never is a bundle agent, by
>>definition. An application (or, in my mind, an "instance" of
>>an application) uses the services of a bundle agent. The
>>bundle agent might be a separate executable (with the
>>application client and the bundle agent interacting via some
>>sort of interprocess communication), or the bundle agent
>>might be something more nebulous like a state representation
>>in a database (with the application client and the bundle
>>agent "interacting" via direct API function calls), but
>>that's just a matter of implementation. Architecturally they
>>are quite distinct.

> 
> 
> "They" being the application and the bundle agent... (right?)

Yes.

>>The application instance or client uses some mechanism (RPC

> 
> 
> I would say that there must be some function of the admin part that
> identifies a particular application.  If the admin part is simply the PGP
> key of an application, and routing in the region is set up to deal with
> that, then once the bundle reaches the destination bundle agent, that agent
> will need to look at the whole admin part and make a decision about which
> application gets the data.

Right, in the case where we're routing on the PGP key of an application, that key has to be used both for routing to the destination bundle agent and for demuxing to the destination application instance. In that case the two functions are inextricably entangled, unfortunately. Remind me why we would want to do this?

>>Good point about the report-to: you probably do want to
>>specify a client demux token along with the endpoint ID for
>>report-to, otherwise the status report can never go any
>>further than the bundle agent itself.
>>
>>On the other hand, for some environments (such as
>>interplanetary internet) it is really important to minimize
>>header size; also it's very convenient to have the primary
>>header be of fixed length, so I'm reluctant to add anything
>>more to it.
>>
>>Would we be willing to constrain these mux/demux tokens to
>>numeric values rather than ASCII strings? This doesn't cost
>>us any latitude for experimentation with routing schemes,
>>because these things aren't in the endpoint IDs that we use
>>for routing. If they were always numeric then each one could
>>be a self-defining numeric value (as in LTP) that could be

> 
> 
> Do we really want to constrain implementations in resource-rich environments
> to conform to the naming conventions for resource-constrained environments?

Yeah, if this is an issue and we absolutely have to carry ASCII strings to enable demuxing to application clients then I guess we just have to.

> Wouldn't it make sense to have a pretty flexible naming scheme and for the > resource-constrained environment to use compression,

Do you need help?
In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related mailman.dtnrg.org Links dtn-interest Request more information about Pantek

No. An environment that is constrained on bandwidth is fairly likely to be computationally constrained as well. Don't count on the magic of lossless compression to compensate for this kind of design decision.

  or a lookup table

Sure, but lookup on what? If we carry a number then in a resource-rich environment we can use the number to look up a lengthy string. If we carry the string then we've got the string.

Scott