[cgl_discussion] linux-ha as a PoC for CCM.1 Cluster Communication Service

Zhu, Yi yi.zhu at intel.com
Mon Jul 7 02:29:48 PDT 2003


Hi,

I found the CGL 2.0 requirement CCM.1 Cluster Communication Service was
written with TIPC in mind. This induces linux-ha (http://linux-ha.org), as another
PoC, can rarely provide any of the requirements. In the following, I'd like to 
discuss the gaps between linux-ha and current CGL 2.0 spec. CCM.1 Cluster
Communication Service requirement priority 1 features one by one.

[ In the following discussion, lines with a index is CGL requirement; "Yes" means
  linux-ha can provide the feature CGL spec. required, "No" means cannot. ]

Cluster Communication Service - Logical Addressing

1. socket-based interface

   No. (linux-ha provides APIs like sendclustermsg(), sendnodemsg(), rcvmsg() 
   and readmsg() for cluster communication service but they are not socket-  
   based)

2. provides point-to-point and multipoint communication 
   
   Yes. (linux-ha provides point-to-point, multipoint (multicase and boardcast)
   communication within the cluster)

3. The communication service must hide the cluster's physical topology from 
   application programs with a logical addressing scheme.
   
   No. (except sending broadcast message to all nodes in the cluster, the sender 
   needs to know the physical topology (the real IP) of the receiver node)

4. Mapping between logical and physical addresses must be performed 
   transparently.

   No. (linux-ha doesn't support this kind of mapping)

5. There must be no user-level distinction between inter- and intra- node 
   communication.
   
   Yes.
   
6. There must be no distinction between user-space and kernel-space 
   messages.

   No. (linux-ha currently doesn't support kernel-space messaging)
   
7. Connection and connectionless modes must be supported.

   No. (linux-ha only provides connectionless communication with 
   following characteristics: multicast-aware; guaranteed packet delivery;
   packet ordering is not guaranteed; flow or congestion control is not 
   provided)


Cluster Communication Service - Fault Handling

1. reliable communication service that detects connection failures, aborts the 
   connection, and reports connection failures.
   
   No. (linux-ha doesn't support connection communication. However, it supports 
   a reliable connectionless communication that can detect communication 
   failures)
   
2. An established connection must react to and report a problem to the 
   application immediately upon any kind of service failure, such as a process 
   or node crash.
   
   No. (still because linux-ha doesn't provide a connection communication. 
   However, the connectionless communication provided by linux-ha supports
   notification through an API called set_nstatus_callback())
   
3. Failure events are published by the communication service and applications 
   that subscribe to these events are notified when an IPC event occurs.
   
   Yes. (This requirement is removed in the final draft, however linux-ha does
   well in this area :))


* There is also some good features for cluster communication supported by
  linux-ha, like supporting simultaneous communication through multiple medias,
  like:
  - Ethernet - shared, dedicated broadcast, multicasting
  - Serial Ports (in a ring or "neighbor" topology) 
  - IrDA
  - SCSI target mode (SCSI<->SCSI communication)
  This increases the communication reliability from the physical level (thinking
  of the ethernet cable is disconnected by chance).


Thanks,
-- 
------------------------------------------------------------------------------
Opinions expressed are those of the author and do not represent Intel Corp.

Zhu Yi (Chuyee)
Intel China Software Lab (ICSL)
22nd Floor, ShanghaiMart Tower No. 2299 Yan'an Road(West) Shanghai 200336, PRC
Tel: 8621-52574545-1261 Fax: 8621-62366119

GnuPG v1.0.6 (GNU/Linux)
http://cn.geocities.com/chewie_chuyee/gpg.txt
$ gpg --keyserver wwwkeys.pgp.net --recv-keys 71C34820
1024D/71C34820 C939 2B0B FBCE 1D51 109A  55E5 8650 DB90 71C3 4820




More information about the cgl_discussion mailing list