I had seen the answer but maybe I am not sure to correctly understand the 
concept.

 

Could you explain a little bit more the "domain connection manager"?

 

My understanding is that there will be 2 instance of OpenHPI running on 2 
different blades.  One of the instances will be connected to a domain and the 
second instance will have a peer connection to the same domain (same hardware). 
 Right?  Where will be the "RAM" data storing all the information.   II am not 
sure to fully understand how this will work but really interested in more 
discussions.

 

We might be interested in contributing to OpenHPI to add this functionality.  
Is it something OpenHPI might be interested.  Do you think that OpenHPI 
developers might help doing and supporting it.

 

By the way, do you have any other documentation than the HPI manual.

 

Thanks again!

 

Jean-Michel Audet

 

 

________________________________

De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Renier Morales
Envoyé : Wednesday, September 12, 2007 12:13 PM
À : [email protected]
Objet : Re: [Openhpi-devel] Daemon Sync

 


[EMAIL PROTECTED] wrote on 09/12/2007 11:28:22 AM:

> Hi, 
>             I would like to come back on the Daemon Sync thread that
> has already been discussed.   
>   
> I would like to know if you think that it might be possible to add 
> redundancy of the OpenHpi daemon.  An external SMS would be able to 
> switch from an active hpi daemon to another without loosing session 
> and configuration.  Data will be kept in SYNC.  I know that OpenHPI 
> have not been done with this concept in mind but what kind of effort
> do you think it is necessary to add this enhancement.  Does it make 
> sense?  Do you see any technical or conceptual problems? 
>   

Yes, it makes sense and this is possible to do. As I said in an email on 8/3 
for that thread: 

"I just wanted to add what I think it is needed in OpenHPI as an enhancement to 
facilitate your situation.

What you need is a better use of the peer domain concept, which is part of the 
spec, as a mechanism for redundancy in the HPI model. The problem is that 
domains live in the same instance space in OpenHPI, so it doesn't buy you much 
redundancy in its current implementation besides the way that those peer 
domains may be connecting to the hardware.

An idea is, and hopefully something that can see the light of day next year, to 
break domains into their own process spaces. The domain connection manager 
would be in the client side, which could connect to mulitple domains. Then, you 
could have peer domains running in separate systems. Now you have better HPI 
data redundancy." 

        --Renier

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

Reply via email to