[prev in list] [next in list] [prev in thread] [next in thread] 

List:       osdlcluster
Subject:    RE: [Osdlcluster] A document about the packet protocol betweenevent
From:       "Zhang, Sonic" <sonic.zhang () intel ! com>
Date:       2004-02-04 6:01:22
Message-ID: 37FBBA5F3A361C41AB7CE44558C3448E5A30A6 () PDSMSX403 ! ccr ! corp ! intel ! com
[Download RAW message or body]

Hi Steven,

	See my answer bellow.

*********************************************
Sonic Zhang
Software Engineer
Intel China Software Lab
Tel: (086)021-52574545-1667
iNet: 752-1667
********************************************* 

-----Original Message-----
From: Steven Dake [mailto:scd@broked.org] 
Sent: 2004Äê2Ô 4ÈÕ 9:15
To: Zhang, Sonic
Cc: osdlcluster@osdl.org
Subject: Re: [Osdlcluster] A document about the packet protocol betweenevent service \
daemons

Sonic

Some comments

1.
I suggest dropping the union and defining two seperate structures.

Unions suck to work with, especially on something as fundamental as the
basic unit of information transmission.  (in a big way)

A: All right. I will remove the union.

2.
I think it is not necessary to transmit the filters to every node in the
cluster.  A simpler mechanism is to have every node in the cluster
maintain their own connection's filters, and filter when they receive an
event.  This way, the filtering is distributed between nodes and doesn't
require one major filter whenever publishing an event (ie: filtering at
reception vs filtering at publishing).

A: No filters are transmitted in the event packet. Each node maintains its own \
filters, while only the patterns of an event are transmitted to other nodes when the \
event is published. 

3.
event_pattern wont work for its current incarnation.

It should be something like:
typedef struct {
        unsigned int size;
        unsigned char value[0];
}event_pattern;

Then sendmsg or the like can be used to send an iovec of the header,
pattern, and values.

A: Yes, array is a better incarnation. I will change the definition. But, should it \
be value[1] instead of value[0]?


4.
I suggest using SaNameT for the channel type, as it is alot easier
transmitting known-sized strings, vs variable length strings.  So its a
few extra characters..  How often is someone likely to open or close a
connection?

A: The value of SA_MAX_NAME_LENGTH is 256. Maybe the fix-size string is acceptable.

5.
chl_stat_alive doesn't seem to make sense to me.  Shouldn't the cluster
membership feature be used to determine healthchecks between nodes?

A: Yes, you are right. I decide to change the way to maintain the channel table. The \
node doesn't need to multicast a channel when a new channel is created or closed. The \
node only updates its own channel table at that time. When a channel open request is \
received from an application, the node multicasts a channel inquiry packet and wait \
for the answer packet. If it doesn't receive the answer packet within a given time, \
the channel open operation failed. In this way, I replace the status variable with \
the operation variable. See my update document for details.


Good first step
Thanks
-steve


[prev in list] [next in list] [prev in thread] [next in thread]