Subject: [Rserpool] Intra-Pool State Sharing

From: "Jose Luis Jimenez Ramirez ECE/TL/NB ID-000 Tlf.4061" <[email-masked]>
Date: Fri, 27 Jul 2001 14:32:01 +0200 (MEST)

Hi All,

The more I study the drafts,the more doubts arise :-).

Well, in the Architecture for Reliable Server Pooling draft, it is said:

	3.1.1.  The RSerPool Aware Client
		...............
		...............

	     (4)  If during the file transfer conversation, PE(1,B) fails,
        	  assuming the PE's were sharing state of file transfer, 
        	  a failover to PE(1,A) could be initiated. PE(1,A) 
        	  would continue the transfer until complete.
        	...............
		...............

--------------------------------------------------------------------------------
----
        	  
a) Should be assumed that all PE's in a Pool are sharing the states of all the
client/server dialogs, to be able for any other PE handle correctly any failure, 
and
continue giving service to the PU?

b) How could be done the sharing of the state of file transfer?
   Could be suposed that the PE is acting as a PU with the others PE's of the 
POOL,
   i.e. there's a connection (SCTP) between PE's reporting about the state of 
this
   file transfer.
   If this correct, and there's 25 PE's in a POOL, it could be needed :
   	1 SCTP assoc between PU<----->PE1 (File transfer).
   	24 SCTP assoc between   PE1<-----PE2
   				PE1<-----PE3
   			        ............
   			        ............
     				PE1<-----PE25 File Transfer State Sharing.

Maybe I'm supposing a lot of things, but can anybody explain how 
Intra-Pool State Sharing can be done without overloading the system.

                   - -
Regards            º º
Jose      --oOOo---()--oOOo--

_______________________________________________
rserpool mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/rserpool

---

From: Randall Stewart <[email-masked]>
Date: Fri, 27 Jul 2001 10:50:18 -0500

Jose:

First and formost... STATE SHARING IS OUTSIDE THE SCOPE OF RSERPOOL.

I want to be very very clear on this point... now to answer your
question :)

There are many ways applications may choose to share state. One of
these is as you mention.. i.e. the PE becoming a PU of its peer
Pool Elements and transfering the state. This may become
impractical in a larger application.. say  you had 10 hosts
each with 10 servers answering user queries. You would end up
with 100 members in the pool all being inter-connencted. One of the
ways we did this (and we do hope to bring a demo on laptop for offline
viewing.. not sure if we will be able to though...) is to create on
each of the 10 hosts a Bulliten board server. These form a pool of there
own and each owns a block of shared memory. PE's attached to this shared
memory and then allocate and use blocks of the memory. When a PE
is ready to "share" the information it does a commit by informing its
local BB server. This BB server pool then transfers and synchronizes
the state information with its 9 peer BB servers.

This is just ONE method of doing this. One could also invision 
reflective memory or OTHER mechanisms to accomplish the same task.

Now since it is OUTSIDE the scope of RSERPOOL we will NOT standardize
this.. we may standardize HOOKS in rserpool to assist folks in
creating this... the "SEND_TO_ALL" is such a hook. So a PE, knowing
its own name would do a send of a state update and apply this flag
to get a copy of a message sent to multiple peers...  But no
explicit stadardization of state sharing will be done :)

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)