Menu
▾
▴
tipc-discussion
|
From: Ling, X. <xia...@in...> - 2004-04-16 02:54:45
|
Guo and me are debuging now, currently our local copy can work for =
replication transfer and simple broadcast,
we are still working on broadcast restransmit. =20
Mark,=20
Has your patch worked for broadcast? I mean when node>8?=20
> -----Original Message-----
> From: tip...@li...=20
> [mailto:tip...@li...] On=20
> Behalf Of Jon Maloy
> Sent: 2004=C4=EA4=D4=C216=C8=D5 3:20
> To: Mark Haverkamp
> Cc: tipc
> Subject: [Tipc-discussion] Re: tipc multicast patch
>=20
>=20
> It looks ok to me, but I think we should let Guo and Ling=20
> have a say first.
>=20
> The only thing I hesitate about is the test for (!index) in=20
> "ref_lock_deref".
> This is one of the most time-critical functions in TIPC.
> Is it _really_ necessary to do this test, except for pure=20
> debugging purposes ? An index of zero should yield the right=20
> return value, -zero, and is hence no different from other=20
> invalid indexes, which also return zero. =3D> I would prefer=20
> that this test is omitted.
>=20
> /Jon
>=20
> Mark Haverkamp wrote:
>=20
> >Daniel McNeil and I were playing with multicast in the unstable view=20
> >and found that it wasn't working for us. We spent some time=20
> debugging=20
> >and got it working (at least in our simple tests). I have=20
> enclosed the=20
> >patch that we came up with for review. We have run the=20
> client/server=20
> >test and it continues to function so I don't think that we broke=20
> >anything with the change. Please take a look and let us=20
> know what you=20
> >think.
> >
> >Thanks,
> >Mark and Daniel.
> >
> >
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/bcast.h=09
> 2004-03-30 07:11:38.000000000 -0800
> >+++ bcast.h 2004-04-14 14:56:08.000000000 -0700
> >@@ -123,7 +123,7 @@
> > int tipc_bsend_buf(struct sk_buff *buf, struct list_head=20
> *mc_head); =20
> >int tipc_send_buf2nameseq(tipc_ref_t ref,struct tipc_name_seq=20
> >*dest,void *buf, uint size); int=20
> tipc_forward_buf2nameseq(tipc_ref_t ref,struct tipc_name_seq *name,
> >- void *buf,struct tipc_portid=20
> const *orig,uint size,
> >+ struct sk_buff *buf,struct=20
> tipc_portid const=20
> >+ *orig,uint size,
> > uint importance,struct list_head=20
> *mc_head);
> >=20
> >=20
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/reg.h=09
> 2004-02-16 15:00:02.000000000 -0800
> >+++ reg.h 2004-04-15 10:08:28.000000000 -0700
> >@@ -91,8 +91,19 @@
> > static inline void *
> > ref_lock_deref(uint ref)
> > {
> >- uint index =3D ref & ref_table.index_mask;
> >- struct reference *r =3D &ref_table.entries[index];
> >+ uint index;
> >+ struct reference *r;
> >+
> >+ index =3D ref & ref_table.index_mask;
> >+
> >+ /*
> >+ * Zero is not a valid index
> >+ */
> >+ if (!index) {
> >+ printk("tipc ref_lock_deref: ref is zero\n");
> >+ return 0;
> >+ }
> >+ r =3D &ref_table.entries[index];
> > spin_lock_bh(&r->lock);
> > if (likely(r->data.reference =3D=3D ref))
> > return r->object;
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/send
> bcast.c 2004-03-24 08:58:32.000000000 -0800
> >+++ sendbcast.c 2004-04-15 10:22:54.000000000 -0700
> >@@ -140,7 +140,7 @@
> > */
> > int tipc_forward_buf2nameseq(tipc_ref_t ref,
> > struct tipc_name_seq *name,
> >- void *buf,
> >+ struct sk_buff *buf,
> > struct tipc_portid const *orig,
> > uint size,
> > uint importance,struct list_head=20
> *mc_head)=20
> >@@ -156,19 +156,19 @@
> > m =3D &this->publ.phdr;
> > if (importance <=3D 3)
> > msg_set_importance(m,importance);
> >-=09
> >+ prev_destnode =3D 0;
> > list_for_each(pos,mc_head) {
> >- prev_destnode =3D 0;
> > mid =3D list_entry(pos,struct mc_identity,list);=20
> > if (mid !=3D NULL && (prev_destnode !=3D mid->node)){
> > prev_destnode =3D mid->node;
> >- copybuf =3D buf_acquire(msg_size(m));
> >- memcpy(copybuf,buf,msg_size(m));
> >+ copybuf =3D buf_clone(buf);
> > msg_set_destnode(buf_msg(copybuf), mid ->node);
> >- if (likely(mid ->node !=3D tipc_own_addr))
> >+ if (likely(mid ->node !=3D tipc_own_addr)) {
> > res =3D=20
> tipc_send_buf_fast(copybuf,mid->node);
> >- else
> >+ }
> >+ else {
> > res =3D bcast_port_recv(copybuf);
> >+ }
> > }
> > }
> > return res;
> >@@ -242,6 +242,7 @@
> > =09
> > if (!this)=20
> > return TIPC_FAILURE;
> >+
> > INIT_LIST_HEAD(&mc_head);=09
> > nametbl_mc_translate(&mc_head,=20
> seq->type,seq->lower,seq->upper);=20
> > tipc_ownidentity(ref,&orig);
> >@@ -255,7 +256,6 @@
> > res =3D msg_build(hdr,msg,scnt,TIPC_MAX_MSG_SIZE,&b);
> > if (!b)
> > return TIPC_FAILURE;
> >-=09
> > count =3D count_mc_member(&mc_head);=09
> > =09
> > if (count <=3D REPLICA_NODES){
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/bcast.c=09
> 2004-03-30 07:11:38.000000000 -0800
> >+++ bcast.c 2004-04-15 10:24:09.000000000 -0700
> >@@ -383,8 +383,8 @@
> > int i =3D 0,prev_destnode;=09
> > struct mc_identity* mid;
> > =09
> >+ prev_destnode =3D 0;
> > list_for_each(pos,mc_head) {
> >- prev_destnode =3D 0;
> > mid =3D list_entry(pos,struct mc_identity,list);
> > if (mid !=3D NULL && (prev_destnode !=3D mid->node)){
> > prev_destnode =3D mid->node;
> >@@ -433,6 +433,7 @@
> > if (mc_list =3D=3D NULL)
> > return false;
> > =09
> >+ INIT_LIST_HEAD(&mc_list->list);
> > mc_list->port =3D destport;
> > mc_list->node =3D destnode;=09
> > list_add_tail(&mc_list->list,list_head);
> >@@ -492,15 +493,14 @@
> > void free_mclist(struct list_head *list_head)
> > {
> > struct mc_identity* mid;
> >- struct list_head *pos;=09
> >+ struct list_head *pos, *n;=09
> > =09
> >- list_for_each(pos,list_head) {
> >+ list_for_each_safe(pos, n, list_head) {
> > mid =3D list_entry(pos, struct mc_identity, list);
> > list_del(&mid->list);
> > kfree(mid);
> > =09
> > }
> >- list_del(list_head);
> > }
> >=20
> > static struct list_head point =3D LIST_HEAD_INIT(point);
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/link.c=09
> 2004-03-11 07:32:51.000000000 -0800
> >+++ link.c 2004-04-15 10:24:34.000000000 -0700
> >@@ -1609,7 +1609,11 @@
> > if=20
> (likely(msg_is_dest(msg,tipc_own_addr))){
> > if (likely(msg_isdata(msg))) {
> > =20
> spin_unlock_bh(&this->owner->lock);
> >- port_recv_msg(buf);
> >+ if=20
> (msg_type(msg) =3D=3D TIPC_MCAST_MSG) {
> >+ =09
> bcast_port_recv(buf);
> >+ } else {
> >+ =09
> port_recv_msg(buf);
> >+ }
> > continue;
> > }
> > =09
> link_recv_non_data_msg(this, buf);
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/cfg.c=09
> 2004-02-16 15:00:01.000000000 -0800
> >+++ cfg.c 2004-04-15 10:27:00.000000000 -0700
> >@@ -393,7 +393,9 @@
> >=20
> > void cfg_link_event(tipc_net_addr_t addr,char* name,int up)
> > {
> >+#ifdef INTER_CLUSTER_COMM
> > struct _zone* z =3D zone_find(addr);
> >+#endif
> >=20
> > if (in_own_cluster(addr))
> > return;
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/recv
> bcast.c 2004-03-30 07:11:39.000000000 -0800
> >+++ recvbcast.c 2004-04-15 10:31:18.000000000 -0700
> >@@ -326,10 +326,10 @@
> > =09
> > struct list_head *pos;
> > struct mc_identity *mid;
> >- int res;
> >+ int res =3D TIPC_OK;
> > =09
> > list_for_each(pos,mc_head) {
> >- mid =3D list_entry(pos, struct=20
> mc_identity, list); =09
> >+ mid =3D list_entry(pos, struct mc_identity, list);
> > if(mid && mid ->node =3D=3D tipc_own_addr) {
> > struct port* port =3D(struct=20
> port*) ref_deref(mid ->port);
> > struct sk_buff *copymsg =3D=20
> buf_clone(buf);
> >---=20
> /home/markh/views/tipc/cvs/source/unstable/net/tipc/name_
> table.c 2004-03-30 07:11:39.000000000 -0800
> >+++ name_table.c 2004-04-15 10:32:13.000000000 -0700
> >@@ -299,7 +299,7 @@
> > /* Insert a publication: */
> >=20
> > publ =3D publ_create(type, lower, upper, port, node, scope, key);
> >- dbg("inserting publ %x, node =3D %x publ->node =3D %x,=20
> subscr->node\n",
> >+ dbg("inserting publ %x, node =3D %x publ->node =3D %x,=20
> >+ subscr->node %x\n",
> > publ,node,publ->node,publ->subscr.node);
> > if (!sseq->zone_list)=20
> > sseq->zone_list =3D publ->zone_list.next =3D publ; =
@@=20
> >-309,10 +309,11 @@
> > }
> >=20
> > if (in_own_cluster(node)){
> >- if (!sseq->cluster_list)=20
> >+ if (!sseq->cluster_list) {
> > sseq->cluster_list =3D=20
> publ->cluster_list.next =3D publ;
> >- else{
> >- publ->cluster_list.next =3D=20
> sseq->cluster_list->cluster_list.next; =20
> >+ } else{
> >+ publ->cluster_list.next =3D=20
> >+ =09
> sseq->cluster_list->cluster_list.next; =20
> > =20
> sseq->cluster_list->cluster_list.next =3D publ;
> > }
> > }
> >@@ -465,7 +466,7 @@
> > struct sub_seq *sseq =3D this->sseqs;
> > if (!sseq)
> > return 0;
> >- dbg("nameseq_av: ff =3D %u, sseq =3D %x,=20
> &&this->sseqs[this->first_free =3D %x\n",
> >+ dbg("nameseq_av: ff =3D %u, sseq =3D %x,=20
> >+ &this->sseqs[this]->first_free =3D %x\n",
> > this->first_free,sseq,&this->sseqs[this->first_free]);
> > for (;sseq !=3D &this->sseqs[this->first_free];sseq++) {
> > if ((sseq->lower >=3D lower) && (sseq->lower <=3D upper))
> >@@ -707,10 +708,14 @@
> > =20
> > if (high_seq < low_seq)
> > goto not_found;
> >+
> >+ if (high_seq >=3D seq->first_free)
> >+ high_seq =3D seq->first_free - 1;
> > =20
> > spin_lock_bh(&seq->lock);
> >=20
> > i =3D low_seq;
> >+
> > =20
> > for (i =3D low_seq ; i <=3D high_seq; i++)
> > {
> >@@ -732,14 +737,15 @@
> > =09
> > if (destport)
> > {
> >- if ( false =3D=3D=20
> mc_identity_create(mc_head,destport,destnode))
> >+ if ( false =3D=3D=20
> mc_identity_create(mc_head,destport,destnode)) {
> > goto found; =09
> >+ }
> > } =09
> > }=09
> > if (list_empty(mc_head))
> > {
> >- spin_unlock_bh(&seq->lock);
> >- goto not_found;
> >+ spin_unlock_bh(&seq->lock);
> >+ goto not_found;
> > }
> > found:
> > spin_unlock_bh(&seq->lock);
> >@@ -783,16 +789,18 @@
> > if (high_seq < low_seq)
> > goto not_found;
> > =20
> >+ if (high_seq >=3D seq->first_free)
> >+ high_seq =3D seq->first_free - 1;
> >+
> > spin_lock_bh(&seq->lock);
> >=20
> > i =3D low_seq;
> >- =20
> >+
> > for (i =3D low_seq ; i <=3D high_seq; i++)
> > {
> > publ =3D seq->sseqs[i].node_list;
> > if(!publ) {
> >- spin_unlock_bh(&seq->lock);
> >- goto not_found; =09
> >+ continue;
> > }
> > destnode =3D publ->node;=20
> > destport =3D publ->ref;
> >@@ -804,9 +812,10 @@
> > }
> > } =09
> > }=09
> >- if (list_empty(mc_head))
> >+ if (list_empty(mc_head)) {
> > spin_unlock_bh(&seq->lock);
> > goto not_found;
> >+ }
> > spin_unlock_bh(&seq->lock);
> > read_unlock_bh(&nametbl_lock);=20
> > return true;
> >
> > =20
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> TIPC-discussion mailing list TIP...@li...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>=20
|
|
From: Mark H. <ma...@os...> - 2004-04-16 16:16:33
|
On Thu, 2004-04-15 at 21:08, Guo, Min wrote: > Hi, Jon > > I checked the our updated code into CVS, The basic > transmission(recv/send) of both blink and replication can work > correctly now.But for retransmission,we are still on debugging. I > marked the before-revision code as T04416 , and after-revision code as > Ttx_rx_bcast. I compiled the new code but couldn't load the tipc module: tipc: Unknown symbol bnode_outqueue_release Error inserting '/root/tipc.ko': -1 Unknown symbol in module bnode_outqueue_release is declared static in recvbcast.c but is called from tipc_bcast_sop in bcast.c. removing the static allows the module to be loaded. Mark. > > Thanks > Guo Min -- Mark Haverkamp <ma...@os...> |
|
From: Ling, X. <xia...@in...> - 2004-04-17 17:38:59
|
Thanks for your good suggestion. some comments below. > -----Original Message----- > From: Daniel McNeil [mailto:da...@os...]=20 > Sent: 2004=C4=EA4=D4=C216=C8=D5 23:14 > To: Ling, Xiaofeng; Guo, Min > Cc: Jon Maloy; Mark Haverkamp; tipc > Subject: RE: [Tipc-discussion] Re: tipc multicast patch >=20 >=20 > Hi, >=20 >=20 > We have not tested > 8 nodes, yet. We could test that code > by changing the check (we currently have 4 nodes) to a lower=20 > number. Do you want us to do this? >=20 > How/why was the number '8' chosen for broadcast? 8 is just a suggested number in the RFC, maybe the more feasible way is = to make=20 it configurable module parameter. Or a dynamic number adjustable with = the total nodes in the cluster. That could be TODO itme. > Also, Mark and I notice some interesting behavior of the mulicast: >=20 > If 2 processes on the same node publish the same port name=20 > sequence, a multicast only goes 1 process on the local node=20 > (we have not tried remote yet). Is this the intended=20 > behavior? Should all processes on all nodes get it? (I do=20 > not know if your latest check-in affects this behavior) In TIPCv1, what I understand is 2 processes on one node can not open the = same port name sequence, on two or more node, only one node will get the a message sent to this = port name, that can be treated as a load balance. As for multicast, maybe this rule can also be applying. Of = cause,this also depends on application mode. > Thanks, >=20 > Daniel >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 |
|
From: Mark H. <ma...@os...> - 2004-04-19 14:32:05
|
On Sat, 2004-04-17 at 10:38, Ling, Xiaofeng wrote: > Thanks for your good suggestion. > some comments below. > > -----Original Message----- > > From: Daniel McNeil [mailto:da...@os...]=20 > > Sent: 2004=E5=B9=B44=E6=9C=8816=E6=97=A5 23:14 > > To: Ling, Xiaofeng; Guo, Min > > Cc: Jon Maloy; Mark Haverkamp; tipc > > Subject: RE: [Tipc-discussion] Re: tipc multicast patch > >=20 > >=20 > > Hi, > >=20 > >=20 > > We have not tested > 8 nodes, yet. We could test that code > > by changing the check (we currently have 4 nodes) to a lower=20 > > number. Do you want us to do this? > >=20 > > How/why was the number '8' chosen for broadcast? >=20 > 8 is just a suggested number in the RFC, maybe the more feasible way i= s to make=20 > it configurable module parameter. Or a dynamic number adjustable with t= he total nodes in the cluster. > That could be TODO itme. >=20 > > Also, Mark and I notice some interesting behavior of the mulicast: > >=20 > > If 2 processes on the same node publish the same port name=20 > > sequence, a multicast only goes 1 process on the local node=20 > > (we have not tried remote yet). Is this the intended=20 > > behavior? Should all processes on all nodes get it? (I do=20 > > not know if your latest check-in affects this behavior) > In TIPCv1, what I understand is 2 processes on one node can not open th= e same port name sequence, > on two or more node, only one node will get the a message sent to this = port name, that can be treated as a load > balance. As for multicast, maybe this rule can also be applying. Of cau= se,this also depends on application mode. >=20 I tried this out with your updated mcast code and it seems to work OK.=20 I published the same port name sequence from two processes on a node and was able to receive a multicast message to each process. This seems to me like the right thing to do. Jon, I looked at your RFC and didn't see this kind of behavior specified one way or the other. What do you think is the right thing to do? Thanks, Mark. >=20 >=20 >=20 > > Thanks, > >=20 > > Daniel > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 --=20 Mark Haverkamp <ma...@os...> |
|
From: Jon M. <jon...@er...> - 2004-04-21 17:14:54
|
Hi Mark,
It is actually specified, in chapter 2.2.6, page 21.=20
Anyway, your interpretation is correct: all sockets bound
to an overlapping sequence should have exactly one copy of the
message. This also means that if a socket is bound to more than=20
one sequence overlapping with the multicast address it should still
only receive one copy. So you have to look for found entries pointing=20
to the same port, and filter out duplicates, before actually delivering=20
the message.
/Jon
Mark Haverkamp wrote:
On Sat, 2004-04-17 at 10:38, Ling, Xiaofeng wrote:
=20
Thanks for your good suggestion.
some comments below.
=20
-----Original Message-----
From: Daniel McNeil [ mailto:da...@os... <mailto:da...@os...> ]=20
Sent: 2004=E5=B9=B44=E6=9C=8816=E6=97=A5 23:14
To: Ling, Xiaofeng; Guo, Min
Cc: Jon Maloy; Mark Haverkamp; tipc
Subject: RE: [Tipc-discussion] Re: tipc multicast patch
Hi,
We have not tested > 8 nodes, yet. We could test that code
by changing the check (we currently have 4 nodes) to a lower=20
number. Do you want us to do this?
How/why was the number '8' chosen for broadcast?
=20
8 is just a suggested number in the RFC, maybe the more feasible way is
to make=20
it configurable module parameter. Or a dynamic number adjustable with
the total nodes in the cluster.
That could be TODO itme.
=20
Also, Mark and I notice some interesting behavior of the mulicast:
If 2 processes on the same node publish the same port name=20
sequence, a multicast only goes 1 process on the local node=20
(we have not tried remote yet). Is this the intended=20
behavior? Should all processes on all nodes get it? (I do=20
not know if your latest check-in affects this behavior)
=20
In TIPCv1, what I understand is 2 processes on one node can not open the
same port name sequence,
on two or more node, only one node will get the a message sent to this
port name, that can be treated as a load
balance. As for multicast, maybe this rule can also be applying. Of
cause,this also depends on application mode.
=20
I tried this out with your updated mcast code and it seems to work OK.=20
I published the same port name sequence from two processes on a node and
was able to receive a multicast message to each process. This seems to
me like the right thing to do.
Jon,
I looked at your RFC and didn't see this kind of behavior specified one
way or the other. What do you think is the right thing to do?
Thanks,
Mark.
=20
=20
Thanks,
Daniel
=20
|
|
From: Jon M. <jon...@er...> - 2004-04-19 17:09:44
|
My comments below.
/jon
Ling, Xiaofeng wrote:
Thanks for your good suggestion.
some comments below.
=20
-----Original Message-----
From: Daniel McNeil [ mailto:da...@os... <mailto:da...@os...> ]=20
Sent: 2004=C4=EA4=D4=C216=C8=D5 23:14
To: Ling, Xiaofeng; Guo, Min
Cc: Jon Maloy; Mark Haverkamp; tipc
Subject: RE: [Tipc-discussion] Re: tipc multicast patch
Hi,
We have not tested > 8 nodes, yet. We could test that code
by changing the check (we currently have 4 nodes) to a lower=20
number. Do you want us to do this?
How/why was the number '8' chosen for broadcast?
More or less by random. I think that it is at the order of 10 nodes
where the use of broadcast
starts to be beneficial. Below that, it adds no significicant bandwith
usage.=20
The use of broadcast has some drawbacks that should be avoided when
possible:
1: All nodes in the cluster will receive a copy of the packets, in many
cases just for
throwing it away.
2: Multicast implies higher packet loss rate than unicast, and hence
more retranmissions.
=20
8 is just a suggested number in the RFC, maybe the more feasible way is
to make=20
it configurable module parameter. Or a dynamic number adjustable with
the total nodes in the cluster.
That could be TODO itme.
If anything, the number should be increased. But let us not complicate
things.
If a hard-coded value works, let us stick to that.
=20
Also, Mark and I notice some interesting behavior of the mulicast:
If 2 processes on the same node publish the same port name=20
sequence, a multicast only goes 1 process on the local node=20
(we have not tried remote yet). Is this the intended=20
behavior? Should all processes on all nodes get it? (I do=20
not know if your latest check-in affects this behavior)
_All_ sockets overlapping with the send sequence, no matter on which
node, should receive
exactly one copy of the message. The entities joining a TIPC "multicast
group" (if that
is what we prefer to call it) is sockets, not nodes.
This is the only consistent behaviour: a process moving from one node to
another must=20
expect the same behaviour with regard to which messages he receives.
=20
In TIPCv1, what I understand is 2 processes on one node can not open the
same port name sequence,
This has changed in TIPCv2. Now you can bind more than one socket to the
same=20
sequence even on the same node. This may be useful if we want "weighted"
load sharing,=20
e.g. we may have 1 binding on one node, and 2 bindings on a second,
leading the=20
second node to take twice the load of the first one for this particular
function.
on two or more node, only one node will get the a message sent to this
port name, that can be treated as a load
balance. As for multicast, maybe this rule can also be applying. Of
cause,this also depends on application mode.
No. The semantics of multicast behaviour must be absolute and
predictable. Statictical=20
load sharing applies to unicast only.
=20
Thanks,
Daniel
=20
=20
|
|
From: Mark H. <ma...@os...> - 2004-04-16 15:05:34
|
On Thu, 2004-04-15 at 21:08, Guo, Min wrote: > Hi, Jon > > I checked the our updated code into CVS, The basic > transmission(recv/send) of both blink and replication can work > correctly now.But for retransmission,we are still on debugging. I > marked the before-revision code as T04416 , and after-revision code as > Ttx_rx_bcast. > > Thanks > Guo Min Hi, Some of your check in changes reversed some of my recent fixes in areas un-related to multicast/bcast. manager.c: reversed broken memset. And there were no other changes other than to back out my fix, media.c: reversed a return code fix. Again there were no other changes other than to reverse the fix. msg.c: Nothing reversed but no code was changed. Only a log message. node.c: reversed fix in node_get_nodes. port.c: reversed fix in port_dispatcher_sigh setting published flag. No other changes. Please make sure that no one else has checked in a change before checking in your changes. You may need to merge with current cvs files before checking in. I'll re-check in the removed fixes. Thanks, Mark. -- Mark Haverkamp <ma...@os...> |
|
From: Ling, X. <xia...@in...> - 2004-04-20 00:40:32
|
-----Original Message----- From: Jon Maloy [mailto:jon...@er...]=20 Sent: 2004=C4=EA4=D4=C220=C8=D5 1:09 To: Ling, Xiaofeng Cc: Daniel McNeil; Guo, Min; Mark Haverkamp; tipc Subject: Re: [Tipc-discussion] Re: tipc multicast patch My comments below. /jon =20 >>In TIPCv1, what I understand is 2 processes on one node can not open = the same port name sequence, >>This has changed in TIPCv2. Now you can bind more than one socket to = the same=20 >>sequence even on the same node. This may be useful if we want = "weighted" load sharing,=20 >>e.g. we may have 1 binding on one node, and 2 bindings on a second, = leading the=20 >>second node to take twice the load of the first one for this = particular function. >>on two or more node, only one node will get the a message sent to this = port name, that can be treated as a load >>balance. As for multicast, maybe this rule can also be applying. Of = cause,this also depends on application mode. >No. The semantics of multicast behaviour must be absolute and = predictable. Statictical=20 >load sharing applies to unicast only. So, in TIPCv2, any process binding to the same instance can take the = multicast receiver role? For example, on node 1 A, bind(17777, 20) B, bind(17777, 20) no node 2 C, bind(17777, 20) D, bind(17777, 20) if sendto name (17777, 20, 0),=20 only one process will receive the message. if sendto nameseq (17777, 20, 20),=20 all the processes will received the message. Is this description correct? =20 =20 |
|
From: Jon M. <jon...@er...> - 2004-04-20 01:20:59
|
See below.
Regards /jon
Ling, Xiaofeng wrote:
-----Original Message-----
From: Jon Maloy [ mailto:jon...@er...
<mailto:jon...@er...> ]=20
Sent: 2004=C4=EA4=D4=C220=C8=D5 1:09
To: Ling, Xiaofeng
Cc: Daniel McNeil; Guo, Min; Mark Haverkamp; tipc
Subject: Re: [Tipc-discussion] Re: tipc multicast patch
My comments below.
/jon
=20
=20
In TIPCv1, what I understand is 2 processes on one node can not open the
same port name sequence,
This has changed in TIPCv2. Now you can bind more than one socket to the
same=20
sequence even on the same node. This may be useful if we want "weighted"
load sharing,=20
e.g. we may have 1 binding on one node, and 2 bindings on a second,
leading the=20
second node to take twice the load of the first one for this particular
function.
on two or more node, only one node will get the a message sent to this
port name, that can be treated as a load
balance. As for multicast, maybe this rule can also be applying. Of
cause,this also depends on application mode.
=20
=20
No. The semantics of multicast behaviour must be absolute and
predictable. Statictical=20
load sharing applies to unicast only.
=20
So, in TIPCv2, any process binding to the same instance can take the
multicast receiver role?
For example,
on node 1
A, bind(17777, 20)
B, bind(17777, 20)
no node 2
C, bind(17777, 20)
D, bind(17777, 20)
if sendto name (17777, 20, 0),=20
only one process will receive the message.
Exactly so. And if you with the third argument mean 'domain =3D 0' you
will know that each of the four sockets will receive the same number of
calls,=20
following a round-robin schedule.
if sendto nameseq (17777, 20, 20),=20
all the processes will received the message.
Is this description correct?
Yes.
=20
=20
=20
|
|
From: Daniel M. <da...@os...> - 2004-04-16 15:14:31
|
Hi, Mark told me you checked-in your code changes. Just a few good open source development process suggestions: Could you please send email to the tipc list when code check-in's are done so all of us know? Patches should be reviewed on the list before check in. The check-in log messages should describe what actually was fixed. Patch early and patch often. (Mark and I debugged code which you already had fixes for :( ) Send out patches incrementally as you find and fix bugs. We have not tested > 8 nodes, yet. We could test that code by changing the check (we currently have 4 nodes) to a lower number. Do you want us to do this? How/why was the number '8' chosen for broadcast? Also, Mark and I notice some interesting behavior of the mulicast: If 2 processes on the same node publish the same port name sequence, a multicast only goes 1 process on the local node (we have not tried remote yet). Is this the intended behavior? Should all processes on all nodes get it? (I do not know if your latest check-in affects this behavior) Thanks, Daniel |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X