Subject: Multiple CEs talking to the same FE

From: Robert Haas <[email-masked]>
Date: Wed, 12 Jan 2005 17:25:37 +0100

Here are some considerations around many CEs talking to the same FE, 
based on early implementation experience:

Associations: Multiple CEs may access the same FE, for instance to 
accomplish different tasks, such as routing, security, QoS. These CEs 
may each run in a separate machine, or they may share the same machine. 
So there is an association for each (CE-FE) pair. Or do we consider 
associations to include more than two members ? Note that multiple 
associations may share the same TCP/SCTP/... connection.

Demultiplexing: Note that in the case where multiple CEs run on the same 
machine, the CE ID can be viewed as a demultiplexor. The ForCES protocol 
does not otherwise include correlators that would enable callbacks to 
the appropriate CE on the response to a ForCES command (or reception of 
an event).

Access conflicts: The framework draft specifies that CE synchronization 
is beyond the scope of ForCES. This means that, for instance, two CEs 
changing the same LFB attribute value, is not viewed at the ForCES level 
as a conflict. But if two CEs try to perform interleaved 2-phase commit 
operations on the same attribute, then ForCES should of course prevent 
it and report it.

Event reporting: If multiple CEs subscribe to different events in an 
LFB, then the LFB must somehow know to which CE(s) events must be fired. 
I propose that a list of interested CE IDs is associated with each event 
attribute in the LFB.

Regards,

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Jan 2005 12:13:37 -0500

I thought we had agreed that for now we would focus on a single active CE 
per FE>  An FE that wants to be managed by several CEs is (I thought) to 
pretend it is several FEs, probably with distinct resources.

The multi-manager problem is very very messy.

The demultiplexing is a valid issue anyway.  I think that the answer is 
probably that one should use different ports if one is going to run several 
CEs (or FEs) on the same machine / interface.  I am not sure we can / 
should introduce an extra demux layer for the "native ethernet transport" case.

Yours,
Joel

At 11:25 AM 1/12/2005, Robert Haas wrote:
>Here are some considerations around many CEs talking to the same FE, based 
>on early implementation experience:
>
>accomplish different tasks, such as routing, security, QoS. These CEs may 
>each run in a separate machine, or they may share the same machine. So 
>there is an association for each (CE-FE) pair. Or do we consider 
>does not otherwise include correlators that would enable callbacks to the 
>appropriate CE on the response to a ForCES command (or reception of an event).
>
>Access conflicts: The framework draft specifies that CE synchronization is 
>beyond the scope of ForCES. This means that, for instance, two CEs 
>operations on the same attribute, then ForCES should of course prevent it 
>and report it.
>
>Event reporting: If multiple CEs subscribe to different events in an LFB, 
>then the LFB must somehow know to which CE(s) events must be fired. I 
>propose that a list of interested CE IDs is associated with each event 
>attribute in the LFB.
>
>Regards,
>
>--
>Dr. Robert R. Haas