tipc-discussion — User questions & problem reports, project news, developer discussion

Re: [Tipc-discussion] tipc-config is here

[Jon M. <jon...@er...>]

That is  a good summary. To the API changes should be added
that they reflect the changes in the address lookup algorithm,
such as they are described in the IETF-draft. This makes
it possible for a sender to control the lookup algorithm in a
more consistent and fine-granular way than earlier.

We still have crashes, but the list of problems is not long.
We have a commitment to present a stable version by July 1st,
and I think this is fully within reach.

/Jon

Randy Macleod wrote:

>   Hi,
>
>    I haven't been following the 1.3 dev stream until last week.
> I just got caught up on the mailing list archives.
>
> Is anything missing from the following summary of
> changes in the 1.3 stream?
>
> - api/tipc structures changed somewhat,
> - added conection flow control and 'unreliable mode'
> - linux coding style re-write,
> - many internal functions moved to native linux mechanisms
>    locks, lists, memory mgmt.
> - added finer grained locking
> - configurable zone/node/slave sizes
> - multicast support is progressing.
> - tipc-config app, eliminates ismod options...
>
>
> 1.3 seems to be unstable since the email list has crash reports...
> Are these crashes limited to multicast?
>
> When do you hope to stabilize the 1.3 development stream?
>
>
>> /Jon
>>
>>
>> hek...@ya... wrote:
>>
>>  >Hi Jon,
>>  >
>>  >That is so cool !
>>  >
>>  >I've been waiting for this for a long time. So now we can
>>  >simply "insmod tipc.o" and later on application can invoke
>>  >"tipc-config" (or some IOCTLs ?) to dynamically change
>>  >the node address ? Just want to make sure that after the
>>  >node address has been set by "tipc-config" it can still
>>  >be changed later by "tipc-config" for any time, right ?
>>  >
>>  >I'm thinking of a scenario where a cluster is formed
>>  >dynamically and the node address of an old node can be
>>  >changed to avoid conflict with a newly joined "node".
>>  >
>>  >A side issue is that I found latest CVS has only linux-2.6
>>  >support. Is linux-2.4 support planned to be dropped ?
>>  >Anyway I've ported it to linux-2.4 since I have to use 2.4
>>  >for a while.
>
>
>
> I also want to use tipc-1.3 on linux-2.4. Could these changes
> by  hek...@ya... be merged into the cvs tree?
>
>
> Keep up the good work,
>

Re: [Tipc-discussion] tipc-config is here

[Randy M. <mac...@no...>]

   Hi,

    I haven't been following the 1.3 dev stream until last week.
I just got caught up on the mailing list archives.

Is anything missing from the following summary of
changes in the 1.3 stream?

- api/tipc structures changed somewhat,
- added conection flow control and 'unreliable mode'
- linux coding style re-write,
- many internal functions moved to native linux mechanisms
    locks, lists, memory mgmt.
- added finer grained locking
- configurable zone/node/slave sizes
- multicast support is progressing.
- tipc-config app, eliminates ismod options...


1.3 seems to be unstable since the email list has crash reports...
Are these crashes limited to multicast?

When do you hope to stabilize the 1.3 development stream?


> /Jon
> 
> 
> hek...@ya... wrote:
> 
>  >Hi Jon,
>  >
>  >That is so cool !
>  >
>  >I've been waiting for this for a long time. So now we can
>  >simply "insmod tipc.o" and later on application can invoke
>  >"tipc-config" (or some IOCTLs ?) to dynamically change
>  >the node address ? Just want to make sure that after the
>  >node address has been set by "tipc-config" it can still
>  >be changed later by "tipc-config" for any time, right ?
>  >
>  >I'm thinking of a scenario where a cluster is formed
>  >dynamically and the node address of an old node can be
>  >changed to avoid conflict with a newly joined "node".
>  >
>  >A side issue is that I found latest CVS has only linux-2.6
>  >support. Is linux-2.4 support planned to be dropped ?
>  >Anyway I've ported it to linux-2.4 since I have to use 2.4
>  >for a while.


I also want to use tipc-1.3 on linux-2.4. Could these changes
by  hek...@ya... be merged into the cvs tree?


Keep up the good work,

-- 
// Randy MacLeod

Re: [Tipc-discussion] Problem with TIPC_SET_MAX_PORTS?

[Jon M. <jon...@er...>]

It works, but I never did it with running traffic. The prerequisite
is that all traffic is stopped before this can be done (this is the
only ioctl() that has that prerequisite).  It may be a good idea to
get hold of the user counter and check that it is zero before the
operation is permitted, though.  This was easy in 2.4, but I guess
there is a similar way to do it in 2.6 ?
 I will have a look at it.

/jon

all...@wi... <mailto:all...@wi...>
wrote:


Has anyone tried using the new ioctl() function TIPC_SET_MAX_PORTS to
see if it actually works?  I ask this because it doesn't seem like a
great idea to be calling stop_node() in the middle of a socket-oriented
routine, since stop_node() shuts down TIPC's socket API via sock_stop().
 
Just curious ...
 
-- Al Stephens

[Tipc-discussion] Problem with TIPC_SET_MAX_PORTS?

[<all...@wi...>]

Has anyone tried using the new ioctl() function TIPC_SET_MAX_PORTS to see if
it actually works?  I ask this because it doesn't seem like a great idea to
be calling stop_node() in the middle of a socket-oriented routine, since
stop_node() shuts down TIPC's socket API via sock_stop().
 
Just curious ...
 
-- Al Stephens

Re: [Tipc-discussion] kernel hang report, and also any way to dump tipc messages?

[Jon M. <jon...@er...>]

Try this instead. I had commented out the correction, to provoke
the error and ensure that the kernel does not crash any more.

/Jon

Chris Friesen wrote:

> Mark Haverkamp wrote:
>
>> If you have sysrq compiled in you can get a task list dump and a dump of
>> what the current processor is doing (assuming its not really dead).  It
>> may have some clues as to what is going on.
>
>
> Not compiled in currently, but I can add it and see if I can get more 
> info.
>
> Chris

Re: [Tipc-discussion] kernel hang report, and also any way to dump tipc messages?

[Jon M. <jon...@er...>]

Try these two. You had not set the "domain" value
in sockaddr-tipc, which embarassing enough led to a
kernel crash.  After one of my latest changes there
was a missing check for "wild" addresses in the
send code. It is now fixed and checked in.

/Jon

PS: If you try with SOCK_RDM instead of SOCK_DGRAM
you will see your message bounce back with error code
"TIPC_NO_NODE" at such types of user error, instead of just
seeing it disappearing.

Chris Friesen wrote:

> Mark Haverkamp wrote:
>
>> If you have sysrq compiled in you can get a task list dump and a dump of
>> what the current processor is doing (assuming its not really dead).  It
>> may have some clues as to what is going on.
>
>
> Not compiled in currently, but I can add it and see if I can get more 
> info.
>
> Chris

[Tipc-discussion] Re: multicast and large messages

[Jon M. <jon...@er...>]

The patch looks ok. I can not see right away what causes
the crash, but you can be pretty certain that it is a branch
of the code that is not executed under normal circumstances.

Is it possible that multicast fragments may arrive in disorder ?
They never do on single links, but I have not looked enough
into the bcast code to tell if it behaves the same way. If they
do, we should suspect the code that tries to re-arrange them,
as this is unexercised code.

In principle you are right about buf_safe_discard(), but it does not
really matter. Remember this is  a fifo-queue, and if a buffer
is still busy when we test it is highly likely that even the following
buffers are busy.  Just as the occurrence of busy buffers is
unlikely in general, I have rarely seen it during test.

/jon

Mark Haverkamp wrote:

>I started testing multicasting large messages.  Ones that need to be
>fragmented.  I noticed the they weren't being delivered.  I put some
>debug prints in the driver and found that the messages were being sent
>out OK.  The messages were also being received and reassembled.  The
>problem is with net_route_msg.  It ends up calling net_route_named_msg
>which just throws the message away.  Im not sure if this is the right
>place to put this, but I added code to net_route_msg (see attached
>patch) that helps. 
>
>--- net.c       9 Jun 2004 23:14:47 -0000       1.12
>+++ net.c       14 Jun 2004 21:42:29 -0000
>@@ -124,6 +124,7 @@
> #include "reg.h"
> #include "msg.h"
> #include "port.h"
>+#include "bcast.h"
>  
> /*
>  * The TIPC locking policy is designed to ensure a very fine locking
>@@ -321,7 +322,9 @@
>                if (msg_isdata(msg)) {
>                        if (msg_destport(msg))
>                                port_recv_msg(buf);
>-                       else
>+                       else if (msg_mcast(msg))
>+                               bcast_port_recv(buf);
>+                       else
>                                net_route_named_msg(buf);
>                        return;
>                }
>
>I generally get the messages on my other nodes.  The bad part is, that
>if I send 100 or so messages quickly, the machine panics with a NULL
>pointer dereference. (See attached trace).
>
>Unable to handle kernel NULL pointer dereference at virtual address 00000050
> printing eip:
>f8e29009
>*pde = 00000000
>Oops: 0000 [#1]
>SMP
>Modules linked in: tipc
>CPU:    0
>EIP:    0060:[<f8e29009>]    Not tainted
>EFLAGS: 00010206   (2.6.7-rc2)
>EIP is at link_recv_fragment+0xe9/0x760 [tipc]
>eax: 00000044   ebx: 00000001   ecx: 00000000   edx: 5940057c
>esi: d9736c7e   edi: d9736c7e   ebp: c050be30   esp: c050bdc8
>ds: 007b   es: 007b   ss: 0068
>Process swapper (pid: 0, threadinfo=c050a000 task=c046a1c0)
>Stack: d9f026bc dd2f1506 00000000 c050be04 00000000 c050be04 d958c01c 00000000
>       00000044 000088ca dd2f04e8 f7bc28cc dcfbc804 dd2f0530 00000198 d9f02430
>       d9736c7e 00000000 f2ab8e70 dd2f04e4 00000206 00000246 f5f481b0 00000001
>Call Trace:
> [<c010614f>] show_stack+0x7f/0xa0
> [<c01062fe>] show_registers+0x15e/0x1c0
> [<c01064aa>] die+0x9a/0x160
> [<c0118946>] do_page_fault+0x2e6/0x5b9
> [<c0105dcd>] error_code+0x2d/0x38
> [<f8e2642e>] tipc_recv_msg+0x57e/0x8d0 [tipc]
> [<f8e45402>] recv_msg+0x42/0x70 [tipc]
> [<c037dca2>] netif_receive_skb+0x172/0x1b0
> [<c037dd64>] process_backlog+0x84/0x120
> [<c037de80>] net_rx_action+0x80/0x120
> [<c0125ff8>] __do_softirq+0xb8/0xc0
> [<c0126035>] do_softirq+0x35/0x40
> [<c0107d45>] do_IRQ+0x175/0x230
> [<c0105cd0>] common_interrupt+0x18/0x20
> [<c0103106>] cpu_idle+0x46/0x50
> [<c050c984>] start_kernel+0x184/0x1d0
> [<c01001e0>] 0xc01001e0
>                         
>Code: 8b 58 0c 89 d7 8b 4e 10 0f c9 8b 43 08 c1 e9 10 81 e2 ff ff
> <0>Kernel panic: Fatal exception in interrupt
>In interrupt handler - not syncing
>
>One other thing.  buf_safe_discard exits its while loop on the first
>busy buffer.  Is it intended to not go through the whole list?
>
>Mark.
>
>  
>

Re: [Tipc-discussion] kernel hang report, and also any way to dump tipc messages?

[Chris F. <cfr...@no...>]

Mark Haverkamp wrote:

> If you have sysrq compiled in you can get a task list dump and a dump of
> what the current processor is doing (assuming its not really dead).  It
> may have some clues as to what is going on.

Not compiled in currently, but I can add it and see if I can get more info.

Chris

Re: [Tipc-discussion] kernel hang report, and also any way to dump tipc messages?

[Mark H. <ma...@os...>]

On Mon, 2004-06-14 at 15:06, Chris Friesen wrote:
> I'm running 2.6.5 on a dual Powermac G5, with tipc from CVS as of last week some 
> time.
> 
> 1) I tried testing modified versions of the connectionless client/server from 
> the pdf documentation. Code for these is below.  I ran the server first with no 
> problems.  When I ran the client, the system hung, no logs were dumped.  Any 
> ideas what's going on?

If you have sysrq compiled in you can get a task list dump and a dump of
what the current processor is doing (assuming its not really dead).  It
may have some clues as to what is going on.

Mark.


-- 
Mark Haverkamp <ma...@os...>

[Tipc-discussion] kernel hang report, and also any way to dump tipc messages?

[Chris F. <cfr...@no...>]

I'm running 2.6.5 on a dual Powermac G5, with tipc from CVS as of last week some 
time.

1) I tried testing modified versions of the connectionless client/server from 
the pdf documentation. Code for these is below.  I ran the server first with no 
problems.  When I ran the client, the system hung, no logs were dumped.  Any 
ideas what's going on?

2) Is there any way to eavesdrop on tipc messages?  Wildcard registration or 
anything like that?  I'm thinking of something that would be able to dump the 
contents of all tipc messages seen by a node whether they be inter- or intra- node.


Thanks,

Chris




source code:

//client
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/param.h>
#include <sys/poll.h>
#include <netdb.h>
#include <errno.h>
#include <fcntl.h>
#include <assert.h>
#include <tipc.h>

int client_sd;
//struct name_availability server_subscr = {17777,0,10000};
struct pollfd pfd;
char buf[64] = {'T','I','P','C',' ','R','U','L','E','S',0};


int main(int argc, char* argv[], char* dummy[])
{
	int i;
//	int tipc_fd = open ("/dev/tipc", O_RDWR);
//	assert(tipc_fd >= 0);
	printf("TIPC Client started,waiting for server...\n");
//	if(!ioctl(tipc_fd,WAIT_FOR_NAME,&server_subscr))
//		assert(!"Server not published");

         struct sockaddr_tipc server_addr;
         server_addr.family = AF_TIPC;
         server_addr.addrtype = TIPC_ADDR_NAME;
         server_addr.scope = TIPC_CLUSTER_SCOPE;
         server_addr.addr.name.name.type = 17777;
         server_addr.addr.name.name.instance = 0;

	client_sd = socket(AF_TIPC, SOCK_DGRAM,0);
	if (0 > sendto(client_sd,buf,strlen(buf)+1,0,(struct 
sockaddr*)&server_addr,sizeof(server_addr)))
		assert(!"Send Failed");
	printf("TIPC Client sent %i octets connectionless message: 
%s\n",strlen(buf)+1,buf);
	pfd.fd = client_sd;
	pfd.events = 0xffff;
	if ((poll(&pfd,1,2000000) <= 0) ||(pfd.revents > POLLIN)) {
		printf("%x\n", pfd.revents);
		assert(!"Unexpected poll event\n");
	}
	if ((strlen(buf)+1) != recv(client_sd,buf,64, 0))
		assert(!"Received wrong size\n");
	printf ("TIPC Client received connectionless response msg: %s \n\n",buf);
}



//server
#include <sys/types.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/param.h>
#include <sys/poll.h>
#include <netdb.h>
#include <errno.h>
#include <fcntl.h>
#include <assert.h>
#include <tipc.h>
char buf[64];
int server_sd;
struct sockaddr_tipc client_addr;
int msglen;
struct pollfd pfd;
int addrlen = {sizeof(client_addr)};
int main(int argc, char* argv[], char* dummy[])
{
         struct sockaddr_tipc server_addr;
         server_addr.family = AF_TIPC;
         server_addr.addrtype = TIPC_ADDR_NAME;
         server_addr.scope = TIPC_CLUSTER_SCOPE;
         server_addr.addr.name.name.type = 17777;
         server_addr.addr.name.name.instance = 0;

	printf("TIPC Server started\n");
	server_sd = socket (AF_TIPC, SOCK_DGRAM,0);
	if (bind (server_sd,(struct sockaddr*)&server_addr,addrlen))
		assert(!"Failed to bind\n");
	pfd.fd = server_sd;
	pfd.events = 0xffff;
	while (1) {
		if ((poll(&pfd,1,2000000) <= 0)||(pfd.revents > POLLIN))
			assert(!"Unexpected poll event\n");
		msglen = recvfrom(server_sd,buf,64,0,(struct sockaddr*)&client_addr,&addrlen);
		if (0 > sendto(server_sd,buf,msglen,0,(struct sockaddr*)&client_addr,addrlen))
			assert(!"Send Failed");
		printf ("TIPC Server received and responded to connectionless msg: %s\n\n",buf);
	}
}

[Tipc-discussion] multicast and large messages

[Mark H. <ma...@os...>]

I started testing multicasting large messages.  Ones that need to be
fragmented.  I noticed the they weren't being delivered.  I put some
debug prints in the driver and found that the messages were being sent
out OK.  The messages were also being received and reassembled.  The
problem is with net_route_msg.  It ends up calling net_route_named_msg
which just throws the message away.  Im not sure if this is the right
place to put this, but I added code to net_route_msg (see attached
patch) that helps. 

--- net.c       9 Jun 2004 23:14:47 -0000       1.12
+++ net.c       14 Jun 2004 21:42:29 -0000
@@ -124,6 +124,7 @@
 #include "reg.h"
 #include "msg.h"
 #include "port.h"
+#include "bcast.h"
  
 /*
  * The TIPC locking policy is designed to ensure a very fine locking
@@ -321,7 +322,9 @@
                if (msg_isdata(msg)) {
                        if (msg_destport(msg))
                                port_recv_msg(buf);
-                       else
+                       else if (msg_mcast(msg))
+                               bcast_port_recv(buf);
+                       else
                                net_route_named_msg(buf);
                        return;
                }

I generally get the messages on my other nodes.  The bad part is, that
if I send 100 or so messages quickly, the machine panics with a NULL
pointer dereference. (See attached trace).

Unable to handle kernel NULL pointer dereference at virtual address 00000050
 printing eip:
f8e29009
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: tipc
CPU:    0
EIP:    0060:[<f8e29009>]    Not tainted
EFLAGS: 00010206   (2.6.7-rc2)
EIP is at link_recv_fragment+0xe9/0x760 [tipc]
eax: 00000044   ebx: 00000001   ecx: 00000000   edx: 5940057c
esi: d9736c7e   edi: d9736c7e   ebp: c050be30   esp: c050bdc8
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c050a000 task=c046a1c0)
Stack: d9f026bc dd2f1506 00000000 c050be04 00000000 c050be04 d958c01c 00000000
       00000044 000088ca dd2f04e8 f7bc28cc dcfbc804 dd2f0530 00000198 d9f02430
       d9736c7e 00000000 f2ab8e70 dd2f04e4 00000206 00000246 f5f481b0 00000001
Call Trace:
 [<c010614f>] show_stack+0x7f/0xa0
 [<c01062fe>] show_registers+0x15e/0x1c0
 [<c01064aa>] die+0x9a/0x160
 [<c0118946>] do_page_fault+0x2e6/0x5b9
 [<c0105dcd>] error_code+0x2d/0x38
 [<f8e2642e>] tipc_recv_msg+0x57e/0x8d0 [tipc]
 [<f8e45402>] recv_msg+0x42/0x70 [tipc]
 [<c037dca2>] netif_receive_skb+0x172/0x1b0
 [<c037dd64>] process_backlog+0x84/0x120
 [<c037de80>] net_rx_action+0x80/0x120
 [<c0125ff8>] __do_softirq+0xb8/0xc0
 [<c0126035>] do_softirq+0x35/0x40
 [<c0107d45>] do_IRQ+0x175/0x230
 [<c0105cd0>] common_interrupt+0x18/0x20
 [<c0103106>] cpu_idle+0x46/0x50
 [<c050c984>] start_kernel+0x184/0x1d0
 [<c01001e0>] 0xc01001e0
                         
Code: 8b 58 0c 89 d7 8b 4e 10 0f c9 8b 43 08 c1 e9 10 81 e2 ff ff
 <0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing

One other thing.  buf_safe_discard exits its while loop on the first
busy buffer.  Is it intended to not go through the whole list?

Mark.

-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] test programs do not compile

[Jon M. <jon...@er...>]

Try with tipc_test-1.4 at SF. It is  a little hackish, but will give
you an idea about how tipc is used. Also, if you check out the latest
version from CVS at SF there is a userland program called tipc-config.c,
which uses the tipc-1.3 communication API to manage TIPC by
messaging.

/jon


Guochun Shi wrote:

>hi, 
>
>I downloaded tipc-1.3.10 and tried to compile some examples from the pdf documents(connless and conn client/server), 
>here are the errors I got from compiling conn_client.c
>(connles_client.c has similar errors, but both servers compile )
>
>[root@posic066 test]# make 
>make: Nothing to be done for `all'.
>[root@posic066 test]# make conn_client
>gcc -I/usr/local/src/linux-2.4.26/include -I/home/gshi/tipc/tipc-1.3.10/include/net/tipc conn_client.c -o conn_client
>conn_client.c:17: variable `server_subscr' has initializer but incomplete type
>conn_client.c:17: warning: excess elements in struct initializer
>conn_client.c:17: warning: (near initialization for `server_subscr')
>conn_client.c:17: warning: excess elements in struct initializer
>conn_client.c:17: warning: (near initialization for `server_subscr')
>conn_client.c:17: warning: excess elements in struct initializer
>conn_client.c:17: warning: (near initialization for `server_subscr')
>conn_client.c:18: warning: large integer implicitly truncated to unsigned type
>conn_client.c: In function `main':
>conn_client.c:29: `WAIT_FOR_NAME' undeclared (first use in this function)
>conn_client.c:29: (Each undeclared identifier is reported only once
>conn_client.c:29: for each function it appears in.)
>conn_client.c:32: `SOCK_TIPC' undeclared (first use in this function)
>conn_client.c: At top level:
>conn_client.c:17: storage size of `server_subscr' isn't known
>make: *** [conn_client] Error 1
>
>
>I guess these programs are obsolete. Are there any new test programs I can run as a start?
>
>Thanks
>-Guochun
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
>Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
>Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
>REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
>_______________________________________________
>TIPC-discussion mailing list
>TIP...@li...
>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>  
>

[Tipc-discussion] test programs do not compile

[Guochun S. <gs...@nc...>]

hi, 

I downloaded tipc-1.3.10 and tried to compile some examples from the pdf documents(connless and conn client/server), 
here are the errors I got from compiling conn_client.c
(connles_client.c has similar errors, but both servers compile )

[root@posic066 test]# make 
make: Nothing to be done for `all'.
[root@posic066 test]# make conn_client
gcc -I/usr/local/src/linux-2.4.26/include -I/home/gshi/tipc/tipc-1.3.10/include/net/tipc conn_client.c -o conn_client
conn_client.c:17: variable `server_subscr' has initializer but incomplete type
conn_client.c:17: warning: excess elements in struct initializer
conn_client.c:17: warning: (near initialization for `server_subscr')
conn_client.c:17: warning: excess elements in struct initializer
conn_client.c:17: warning: (near initialization for `server_subscr')
conn_client.c:17: warning: excess elements in struct initializer
conn_client.c:17: warning: (near initialization for `server_subscr')
conn_client.c:18: warning: large integer implicitly truncated to unsigned type
conn_client.c: In function `main':
conn_client.c:29: `WAIT_FOR_NAME' undeclared (first use in this function)
conn_client.c:29: (Each undeclared identifier is reported only once
conn_client.c:29: for each function it appears in.)
conn_client.c:32: `SOCK_TIPC' undeclared (first use in this function)
conn_client.c: At top level:
conn_client.c:17: storage size of `server_subscr' isn't known
make: *** [conn_client] Error 1


I guess these programs are obsolete. Are there any new test programs I can run as a start?

Thanks
-Guochun

Re: [Tipc-discussion] REPLICA_NODES set to 1

[Jon M. <jon...@er...>]

I can not find anything about this in the kernel style guides
I have looked through, but I a quick search in google gave me=20
this URL:=20
http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/5316.html
<http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-10/5316.html>=20

It should be fixed.

/jon

Mark Haverkamp wrote:


On Thu, 2004-06-10 at 18:43, Ling, Xiaofeng wrote:

 =20

-----Original Message-----

From: Mark Haverkamp [ mailto:ma...@os... <mailto:ma...@os...> ]=20

Sent: 2004=E5=B9=B46=E6=9C=8811=E6=97=A5 0:17

To: Ling, Xiaofeng

Cc: tipc

Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1



On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:

     =20

On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:

       =20

Yes, that's problem.The broadcast packet is not received by sender,

maybe we need to copy one to sender self.

how about this patch?  (The reture value still need to be resolved)

         =20

That seemed to work OK.

       =20

One small thing.  The patch declares the struct sk_buff below the start

of the code block.  This isn't standard C.

     =20

But It's in C99 standard, isn't it? :)

   =20



Sorry, I didn't realize that. I don't think that I've seen kernel files

declare variables other than at the start of a code block though.  Maybe

its a kernel coding style thing.





Mark.



 =20

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Mark H. <ma...@os...>]

On Thu, 2004-06-10 at 18:43, Ling, Xiaofeng wrote:
> >-----Original Message-----
> >From: Mark Haverkamp [mailto:ma...@os...]=20
> >Sent: 2004=E5=B9=B46=E6=9C=8811=E6=97=A5 0:17
> >To: Ling, Xiaofeng
> >Cc: tipc
> >Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1
> >
> >On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
> >> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
> >> > Yes, that's problem.The broadcast packet is not received by sender=
,
> >> > maybe we need to copy one to sender self.
> >> > how about this patch?  (The reture value still need to be resolved=
)
> >>=20
> >> That seemed to work OK.
> >
> >One small thing.  The patch declares the struct sk_buff below the star=
t
> >of the code block.  This isn't standard C.
> But It's in C99 standard, isn't it? :)

Sorry, I didn't realize that. I don't think that I've seen kernel files
declare variables other than at the start of a code block though.  Maybe
its a kernel coding style thing.


Mark.

--=20
Mark Haverkamp <ma...@os...>

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Mark H. <ma...@os...>]

On Thu, 2004-06-10 at 19:42, Ling, Xiaofeng wrote:
> =20
> >-----Original Message-----
> >From: Mark Haverkamp [mailto:ma...@os...]=20
> >Sent: 2004=E5=B9=B46=E6=9C=8811=E6=97=A5 1:22
> >To: Ling, Xiaofeng
> >Cc: tipc
> >Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1
> >
> >On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
> >> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
> >> > Yes, that's problem.The broadcast packet is not received by sender=
,
> >> > maybe we need to copy one to sender self.
> >> > how about this patch?  (The reture value still need to be resolved=
)
> >>=20
> >
> >I notice a pause between sending a multicast message and=20
> >receiving it on
> >another node that I don't see with the replicated multicast.  Do you
> >know why that might be?
> Do you mean there is a delay between=20
> sending and recevinig when using broadcast?

Yes, that is what I saw.  I have some subscription test programs running
connected to the event server on each node.  When I publish from one of
the nodes, the subscribers on all nodes are to receive the event data.=20
With the replicated multicast, I see the received event right away.=20
With broadcast there was some delay.  I haven't quantified the time
difference, just what I saw displayed on the screen.

Mark.
>=20
> >If you are interested in using an application for multicast testing, I
> >have an event service based on the SAF spec that I have been working
> >on.  It is what I have been using with TIPC.  It is still in
> >development, but it may be useful for some of your testing.   I have a=
n
> >event server, and some publish and subscribe test programs.  I have a
> >bitkeeper view at=20
> >
> >bk://bitkeeper.osdl.org/osdlcluster
> >
> >Or the latest tar at=20
> >
> >http://developer.osdl.org/cherry/osdlcluster/
>=20
> I'll try it.
--=20
Mark Haverkamp <ma...@os...>

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Ling, X. <xia...@in...>]

=20

>-----Original Message-----
>From: Mark Haverkamp [mailto:ma...@os...]=20
>Sent: 2004=C4=EA6=D4=C211=C8=D5 1:22
>To: Ling, Xiaofeng
>Cc: tipc
>Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1
>
>On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
>> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
>> > Yes, that's problem.The broadcast packet is not received by sender,
>> > maybe we need to copy one to sender self.
>> > how about this patch?  (The reture value still need to be resolved)
>>=20
>
>I notice a pause between sending a multicast message and=20
>receiving it on
>another node that I don't see with the replicated multicast.  Do you
>know why that might be?
Do you mean there is a delay between=20
sending and recevinig when using broadcast?

>If you are interested in using an application for multicast testing, I
>have an event service based on the SAF spec that I have been working
>on.  It is what I have been using with TIPC.  It is still in
>development, but it may be useful for some of your testing.   I have an
>event server, and some publish and subscribe test programs.  I have a
>bitkeeper view at=20
>
>bk://bitkeeper.osdl.org/osdlcluster
>
>Or the latest tar at=20
>
>http://developer.osdl.org/cherry/osdlcluster/

I'll try it.

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Ling, X. <xia...@in...>]

>-----Original Message-----
>From: Mark Haverkamp [mailto:ma...@os...]=20
>Sent: 2004=C4=EA6=D4=C211=C8=D5 0:17
>To: Ling, Xiaofeng
>Cc: tipc
>Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1
>
>On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
>> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
>> > Yes, that's problem.The broadcast packet is not received by sender,
>> > maybe we need to copy one to sender self.
>> > how about this patch?  (The reture value still need to be resolved)
>>=20
>> That seemed to work OK.
>
>One small thing.  The patch declares the struct sk_buff below the start
>of the code block.  This isn't standard C.
But It's in C99 standard, isn't it? :)
Anyway, use C89 standard is safer.

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Ling, X. <xia...@in...>]

=20

>-----Original Message-----
>From: Mark Haverkamp [mailto:ma...@os...]=20
>Sent: 2004=C4=EA6=D4=C210=C8=D5 23:36
>To: Ling, Xiaofeng
>Cc: tipc
>Subject: RE: [Tipc-discussion] REPLICA_NODES set to 1
>That seemed to work OK.
>
>I am curious about how the TIPC bcast works.  Does it do a=20
>real ethernet
>multicast or broadcast?  If so, why do we need to manually send a copy

It does a broadcast, but I'm not sure whether the NIC will deliver the =
broadcast to itself?
or it should be done in the stack?

Re: [Tipc-discussion] tipc-config is here

[Jon M. <jon...@er...>]

Actually, you don't have to always close sockets and connections
when the node address is changed.
Node internal connections and existing sockets are still valid
and usable after an address change. Sockets will change identity,
i.e. the sockaddr_tipc.addr.id.node field, but even the peer socket
on a connection will be updated about that, so node internal
connections will normally survive.

You just have to know that if you store a copy of a sockaddr_tipc
of type TIPC_ADDR_ID you can not assume it will be valid after
an address change. I think very few users should need to do anything
like that, anyway.

/Jon

hek...@ya... wrote:

>Hi Jon,
>
>Thanks! I totally understand the complexity in changing node address 
>without having to reset links though it sounds cool. In fact
>I'm prepared for that when "node-address change" event happens all 
>applications will close their previous TIPC sockets and re-open their
>TIPC sockets and re-bind them to the ports if necessary. The bottom
>line is that TIPC module doesn't have to be reloaded when node address
>change which seems to be well addressed by you :)
>
>Kevin
>
>--- Jon Maloy <jon...@er...> wrote:
>  
>
>>I perceive a wish here to be able to change node addresses
>>_without_ having to reset links, connections etc. Right ?
>>
>>Even this is doable, but it would be more complex to implement,
>>and certainly not anything I would prioritize now.
>>It is also unlikely to go completely without consequences, since
>>applications may retain copies of port identities which all by
>>sudden change, messages may already be on their way when the
>>destination port identity change, causing a connection abortion
>>etc.
>>When we _really_ have a stable kernel module, where inter-zone
>>links work, TCP/IPSEC support and all the other things in
>>the TODO list are done, this is something to consider, but there
>>has to be a need for it.
>>
>>/Jon
>>
>>
>>hek...@ya... wrote:
>>
>>    
>>
>>>Hi Jon,
>>>
>>>That is so cool !
>>>
>>>I've been waiting for this for a long time. So now we can
>>>simply "insmod tipc.o" and later on application can invoke
>>>"tipc-config" (or some IOCTLs ?) to dynamically change
>>>the node address ? Just want to make sure that after the
>>>node address has been set by "tipc-config" it can still
>>>be changed later by "tipc-config" for any time, right ? 
>>>
>>>I'm thinking of a scenario where a cluster is formed
>>>dynamically and the node address of an old node can be
>>>changed to avoid conflict with a newly joined "node".
>>>
>>>A side issue is that I found latest CVS has only linux-2.6
>>>support. Is linux-2.4 support planned to be dropped ?
>>>Anyway I've ported it to linux-2.4 since I have to use 2.4
>>>for a while.
>>>
>>>Thanks
>>>
>>>Kevin
>>>
>>>
>>>--- Jon Maloy <jon...@er...> wrote:
>>> 
>>>
>>>      
>>>
>>>>Hi all,
>>>>I have now checked in my new code for dynamic configuration of TIPC.
>>>>There are more changes than I really appreciate in one single delivery,
>>>>but it seems to work fairly well so far, and I think it was necessary to 
>>>>have
>>>>it done.
>>>>
>>>>Major changes:
>>>>
>>>>1: No module parameters anymore, -everything must be done via
>>>>  the new user-land tool "tipc-config" that comes with the package.
>>>>2: TIPC can be executed in single-node mode without any initial
>>>>   configuration at all. It will use the special node address <0.0.0>
>>>>   for single-node use, but this must be set to a real address before
>>>>    running in network mode.
>>>>3: A few bugs, primarily related to manager.c, but also to routing
>>>>   of named messages were fixed.
>>>>
>>>>tipc-config is far from being perfect yet, and can certainly be improved
>>>>both regarding readability and robustness, but it works well for the
>>>>basic cases, such as setting own node address and enabling/disabling 
>>>>interfaces.
>>>>Even the other commands have been tested,and work under normal
>>>>cirumstances.
>>>>Have a look at the command interface, -I have tried to make it as
>>>>comprehensible as possible, but I am very open for improvement
>>>>suggestions.
>>>>
>>>>Enjoy(?) /Jon
>>>>
>>>>
>>>>-------------------------------------------------------
>>>>This SF.Net email is sponsored by: GNOME Foundation
>>>>Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>>>>GNOME Users and Developers European Conference, 28-30th June in Norway
>>>>http://2004/guadec.org
>>>>_______________________________________________
>>>>TIPC-discussion mailing list
>>>>TIP...@li...
>>>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>>>   
>>>>
>>>>        
>>>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: GNOME Foundation
>>Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>>GNOME Users and Developers European Conference, 28-30th June in Norway
>>http://2004/guadec.org
>>_______________________________________________
>>TIPC-discussion mailing list
>>TIP...@li...
>>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
>>    
>>

Re: [Tipc-discussion] tipc-config is here

[<hek...@ya...>]

Hi Jon,

Thanks! I totally understand the complexity in changing node address 
without having to reset links though it sounds cool. In fact
I'm prepared for that when "node-address change" event happens all 
applications will close their previous TIPC sockets and re-open their
TIPC sockets and re-bind them to the ports if necessary. The bottom
line is that TIPC module doesn't have to be reloaded when node address
change which seems to be well addressed by you :)

Kevin

--- Jon Maloy <jon...@er...> wrote:
> I perceive a wish here to be able to change node addresses
> _without_ having to reset links, connections etc. Right ?
> 
> Even this is doable, but it would be more complex to implement,
> and certainly not anything I would prioritize now.
> It is also unlikely to go completely without consequences, since
> applications may retain copies of port identities which all by
> sudden change, messages may already be on their way when the
> destination port identity change, causing a connection abortion
> etc.
> When we _really_ have a stable kernel module, where inter-zone
> links work, TCP/IPSEC support and all the other things in
> the TODO list are done, this is something to consider, but there
> has to be a need for it.
> 
> /Jon
> 
> 
> hek...@ya... wrote:
> 
> >Hi Jon,
> >
> >That is so cool !
> >
> >I've been waiting for this for a long time. So now we can
> >simply "insmod tipc.o" and later on application can invoke
> >"tipc-config" (or some IOCTLs ?) to dynamically change
> >the node address ? Just want to make sure that after the
> >node address has been set by "tipc-config" it can still
> >be changed later by "tipc-config" for any time, right ? 
> >
> >I'm thinking of a scenario where a cluster is formed
> >dynamically and the node address of an old node can be
> >changed to avoid conflict with a newly joined "node".
> >
> >A side issue is that I found latest CVS has only linux-2.6
> >support. Is linux-2.4 support planned to be dropped ?
> >Anyway I've ported it to linux-2.4 since I have to use 2.4
> >for a while.
> >
> >Thanks
> >
> >Kevin
> >
> >
> >--- Jon Maloy <jon...@er...> wrote:
> >  
> >
> >>Hi all,
> >>I have now checked in my new code for dynamic configuration of TIPC.
> >>There are more changes than I really appreciate in one single delivery,
> >>but it seems to work fairly well so far, and I think it was necessary to 
> >>have
> >>it done.
> >>
> >>Major changes:
> >>
> >>1: No module parameters anymore, -everything must be done via
> >>   the new user-land tool "tipc-config" that comes with the package.
> >>2: TIPC can be executed in single-node mode without any initial
> >>    configuration at all. It will use the special node address <0.0.0>
> >>    for single-node use, but this must be set to a real address before
> >>     running in network mode.
> >>3: A few bugs, primarily related to manager.c, but also to routing
> >>    of named messages were fixed.
> >>
> >>tipc-config is far from being perfect yet, and can certainly be improved
> >>both regarding readability and robustness, but it works well for the
> >>basic cases, such as setting own node address and enabling/disabling 
> >>interfaces.
> >>Even the other commands have been tested,and work under normal
> >>cirumstances.
> >>Have a look at the command interface, -I have tried to make it as
> >>comprehensible as possible, but I am very open for improvement
> >>suggestions.
> >>
> >>Enjoy(?) /Jon
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: GNOME Foundation
> >>Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> >>GNOME Users and Developers European Conference, 28-30th June in Norway
> >>http://2004/guadec.org
> >>_______________________________________________
> >>TIPC-discussion mailing list
> >>TIP...@li...
> >>https://lists.sourceforge.net/lists/listinfo/tipc-discussion
> >>    
> >>
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: GNOME Foundation
> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
> GNOME Users and Developers European Conference, 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> TIPC-discussion mailing list
> TIP...@li...
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Mark H. <ma...@os...>]

On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
> > Yes, that's problem.The broadcast packet is not received by sender,
> > maybe we need to copy one to sender self.
> > how about this patch?  (The reture value still need to be resolved)
> 

I notice a pause between sending a multicast message and receiving it on
another node that I don't see with the replicated multicast.  Do you
know why that might be?

If you are interested in using an application for multicast testing, I
have an event service based on the SAF spec that I have been working
on.  It is what I have been using with TIPC.  It is still in
development, but it may be useful for some of your testing.   I have an
event server, and some publish and subscribe test programs.  I have a
bitkeeper view at 

bk://bitkeeper.osdl.org/osdlcluster

Or the latest tar at 

http://developer.osdl.org/cherry/osdlcluster/

Thanks,
Mark
-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] tipc-config is here

[Mark H. <ma...@os...>]

On Thu, 2004-06-10 at 09:03, Mark Haverkamp wrote:
> On Wed, 2004-06-09 at 16:29, Jon Maloy wrote:
> > Hi all,

[ ... ]

> 
> I was able to set the address of my node fairly easily, but when it came
> to enabling an ethernet interface, I haven't had any luck yet.  I have
> tried:
> 
> ./tipc-config  -be=eth1
> 
> But get:
> Command rejected, check syntax
> 
> I had assumed that I just use the net device name like with the insmod. 
> Am I doing something obviously wrong?

Never mind, I dug through the driver and figured out that the string
needed to be eth:eth1 to work.

Mark.


> 
> Thanks,
> Mark.
-- 
Mark Haverkamp <ma...@os...>

RE: [Tipc-discussion] REPLICA_NODES set to 1

[Mark H. <ma...@os...>]

On Thu, 2004-06-10 at 08:36, Mark Haverkamp wrote:
> On Thu, 2004-06-10 at 02:41, Ling, Xiaofeng wrote:
> > Yes, that's problem.The broadcast packet is not received by sender,
> > maybe we need to copy one to sender self.
> > how about this patch?  (The reture value still need to be resolved)
> 
> That seemed to work OK.

One small thing.  The patch declares the struct sk_buff below the start
of the code block.  This isn't standard C.

Mark.

cvs diff -u sendbcast.c
Index: sendbcast.c
===================================================================
RCS file: /cvsroot/tipc/source/unstable/net/tipc/sendbcast.c,v
retrieving revision 1.18
diff -u -r1.18 sendbcast.c
--- sendbcast.c	2 Jun 2004 21:31:36 -0000	1.18
+++ sendbcast.c	10 Jun 2004 16:15:45 -0000
@@ -238,8 +238,11 @@
 		    tipc_forward_buf2nameseq(ref, (struct tipc_name_seq *) seq,
 					     b, &orig, res, 17, &mc_head);
 	} else {
+		struct sk_buff *copybuf;
 		bcast_set_timer(16 * RTT);
 		check_bcast_outqueue();
+		copybuf = buf_clone(b);
+		bcast_port_recv(copybuf);
 		res = tipc_bsend_buf(b, &mc_head);
 	}
 	free_mclist(&mc_head);


> 
> I am curious about how the TIPC bcast works.  Does it do a real ethernet
> multicast or broadcast?  If so, why do we need to manually send a copy
> to ourselves?
> 
> Thanks,
> Mark.
-- 
Mark Haverkamp <ma...@os...>

Re: [Tipc-discussion] tipc-config is here

[Mark H. <ma...@os...>]

On Wed, 2004-06-09 at 16:29, Jon Maloy wrote:
> Hi all,
> I have now checked in my new code for dynamic configuration of TIPC.
> There are more changes than I really appreciate in one single delivery,
> but it seems to work fairly well so far, and I think it was necessary to 
> have
> it done.
> 
> Major changes:
> 
> 1: No module parameters anymore, -everything must be done via
>    the new user-land tool "tipc-config" that comes with the package.
> 2: TIPC can be executed in single-node mode without any initial
>     configuration at all. It will use the special node address <0.0.0>
>     for single-node use, but this must be set to a real address before
>      running in network mode.
> 3: A few bugs, primarily related to manager.c, but also to routing
>     of named messages were fixed.
> 
> tipc-config is far from being perfect yet, and can certainly be improved
> both regarding readability and robustness, but it works well for the
> basic cases, such as setting own node address and enabling/disabling 
> interfaces.
> Even the other commands have been tested,and work under normal
> cirumstances.
> Have a look at the command interface, -I have tried to make it as
> comprehensible as possible, but I am very open for improvement
> suggestions.
> 
> Enjoy(?) /Jon

I was able to set the address of my node fairly easily, but when it came
to enabling an ethernet interface, I haven't had any luck yet.  I have
tried:

./tipc-config  -be=eth1

But get:
Command rejected, check syntax

I had assumed that I just use the net device name like with the insmod. 
Am I doing something obviously wrong?

Thanks,
Mark.

-- 
Mark Haverkamp <ma...@os...>