[bind10-dev] milestones for shared memory support

[JINMEI Tatuya / 神明達哉]

At Tue, 23 Apr 2013 08:58:29 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> > ? #2922 msgq extension: subscriber info handling
> 
> The command for listing sessions and groups should be easy, there's place to add
> commands (I believe this may be on the higher level, like any other command
> between applications).
> 
> However, I think we will not have the empty groups (there would be either
> subscription to notification of all the changes, or by subscribing to some
> special group).

Then how would memmgr get changes of subscribers of the
"MemorySegmentReaders" group? (the group name is tentative, referring
to http://bind10.isc.org/wiki/SharedMemoryIPC)

Do you mean memmgr would subscribe to a "special"
"FollowersOfMemorySegmentReaders" group?  But then how can msgq know
this "followers" group is about the interest in the
"MemorySegmentReaders" group?  I thought group names are opaque to
msgq, just some unique names for sets of session IDs.

> and we are missing a dependency here. We don't support notifications, there will
> be some work to allow them. We'll have to create a function to create a
> notification (as we have createCommand and createAnswer, so we would have
> createNotification). Receiving end will be little more work, because we need to
> register callbacks.

If you think we need another ticket or include some existing one to
the list for the milestones, please do so.

> > ? #2923 IPC user extension: getting subscriber info, way to unicast specific
> >   subscriber (identified by the session ID)
> 
> This is actually a null ticket. If the get_sessions is command like the others,
> we can already call it (let's say by rpcCall).

Okay, but looking at the interface again, I think the current
rpc_call() would look a bit awkward because it takes a parameter of
"group"; when we send a message to a particular session ID, I guess
we'd rather not to bother specifying the group name.  So, maybe we can
rename the current rpc_call to, e.g., rpc_call_group, and revise the
interface of rpc_call as follows:

    def rpc_call(self, command, to, params=None):
        """
        to: the recipient session ID
        ...
        """
(this version also removes the "instance" parameter, as it's actually
not used for any purpose today)

> All the groupSendMsg and friends support sending based on lname instead of group
> name.
> 
> We may want to have some kind of rpcCallMulti.

I'm not sure what this one is supposed to do.  Send the same command
to multiple session IDs (as separate messages)?  If so, I suspect
we'll face the same problem as the semantics of "answer from a group",
i.e., what if a subset of the answers indicate a success and rest
indicate failure, etc.  I thought the semantics can be only determined
by the application (user), not at the API level.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.