Subject: Re: Topology

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Aug 1999 14:03:22 -0400

I'm okay with the first alternative (list per termination of what you
hear, list per termination of who you speak to).  How about something
along the lines of:
Topology=Senders{term1,term2,term3)
Topology=Receivers(term1,term2,term3)
We could concievably add more keywords for Topology=

Brian

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, August 24, 1999 1:44 PM
> To: Brian Rosen; [email-masked]
> Subject: Re: Topology
>
>
> At 01:33 PM 8/24/99 -0400, Brian Rosen wrote:
> >Lots of ideas on this thread.
> >
> >I personally don't like the complexity of the whole idea, but I don't
> >think fighting it is worthwhile.
>
> Neither do I.  We are going from a complexity of 0(N) (star with per
> termination mode) to 0(N^2) (arbitrary reception matrix), or
> maybe even
> worse. I don't see why we should impose such complexity to all
> configurations.  At a minimum, we ought to define an error
> code mentioning
> that the topology extension is not supported.
>
> >The simplest syntax is a topology descriptor legal in an
> Add/Move/Modify.
> >The "TerminationA" is the TerminationID in the command.  The
> descriptor has
> >the other TerminationID (TerminationB) and the topology keyword.
>
> I think we actually need two topology attributes:
>
> 1) a list of terminations that the command's termination listens to.
> Default is "all" in the star system; can be overriden by
> setting the mode
> to "receive only", in which case the termination will not
> hear anything.
>
> 2) a list of terminations that the command's termination
> sends to. Default
> is "all" in the star system; can be overriden by setting the
> mode to "send
> only", in which case the termination will not be heard by anyone.
>
> Another way would be to have just one list, and then an
> optional mode per
> termination in the list.
> Christian Huitema
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Aug 1999 14:58:30 +1000

I don't really like 1 or 2 for a few reasons:
- It scatters the knowledge topology across multiple terminations
causing each to maintain a list which takes extra memory.
- It means that a termination is aware of the 'other' terminations in
the system. With the star configuration and the 'context parameter'
method this information is hidden. (I suppose this is also a good thing
in legal intercept)
- If you leave a termination out of the list are they : isolated?
bothway? How many keywords do we need?
- Send and Receive are already on Streams, Local Descriptors, if we add
them to the termination as well I think that's pretty complex.
- I think that we get to the worse than 0(n^2) situation if each
termination has to start including information on other terminations
- We're still going to have to solve adding properties/parameters to
Contexts for mixing etc. so the work needs to be done. I don't think
skirting the issues to terminations solves that.

I would like to see John Seger's 3rd option of:
- Adding TopologyDescriptor to a Modify and making the TerminationID
optional.
  and keeping the syntax (T1,T2 oneway)

I believe this is the cleanest solution and would support further
context parameters such as mixing

Cheers, Christian