futures (Re: [net2-wg] Packet interface)

[Rodrigo Fonseca]

I agree that the management of the entries should be global. This can
be separated from the allocation, which can still be local, but each
client 'delegates' its allocated entries in the begining of times to
"SP".

Then, when you want to send, you basically get one, and when it's
finished you don't worry about it. If you have an active entry and you
want to send more messages with the same properties, to the same dest,
it's perfectly fine to increase the futures, but I don't find it very
natural to place the burden of Gill's second decision to the
application. There would be a lot of logic duplicated in many clients
to basically do the same thing.

Then how SP manages the entries (who gets entries, limits on how many
you can get, etc) should be separated into mechanism (which is built
into SP), and policy (which can be externalized in a replaceable
manager).

Rodrigo

On 12/8/05, Gilman Tolle <gilman.tolle at gmail.com> wrote:
> > This is the point I think might generate confusion: if each client has
> > to allocate entries for each destination, this can be a hard decision
> > to make statically.
>
> If I were writing a multiple-destination protocol on top of a layer
> like this, I'd have to make two decisions:
> * how many send pool entries do I need? (static)
> * which entry do I use for a particular send? (dynamic)
>
> Like Rodrigo says, the first is a hard decision to make statically in
> the point-to-point case, so let's say that the client just picks
> "enough", balancing RAM requirements with communication multiplexing.
>
> I can think of two different ways to make the second decision:
> * pick any inactive entry for a new send
> * pick an entry that has a particular destination and increase its
> futures, for an additional send
>
> Both of these decisions require less coding on the client if, instead
> of allocating individual pool entries, the client allocates a pool
> with N entries, which is a portion of the overall global pool, and
> requests an entry before filling it in and sending it. The entry could
> be requested according to free-ness, or by destination.
>
> How else would you use this interface?
>
> Gil
>