Menu
▾
▴
tipc-discussion
|
From: Jon M. <jon...@er...> - 2004-06-09 23:29:23
|
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
|
|
From: <hek...@ya...> - 2004-06-09 23:43:40
|
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 |
|
From: Jon M. <jon...@er...> - 2004-06-10 13:46:14
|
Regards /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 ? > Yes, you can change the address at any time. The only limitation now is that when you do that TIPC "forgets" about the activated interfaces, so they will have to be enabled again. This is relatively easy to fix with a patch: let tipc-config read the enabled bearers (a string), keep the string on the stack, and re-apply it automatically on TIPC once the address has been changed. But I had to draw the line somewhere... (You are welcome to fix this, of course) > >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. > Yes, the 2.4 support has been dropped, since in involves too much extra work to keep it alive. We still try to keep all environment dependencies isolated to a few files, though, so it is a doable task to do this, if you really need it. > >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 >> >> |
|
From: Jon M. <jon...@er...> - 2004-06-10 14:23:12
|
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 >> >> |
|
From: <hek...@ya...> - 2004-06-10 19:05:37
|
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 |
|
From: Jon M. <jon...@er...> - 2004-06-10 19:56:14
|
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 >> >> |
|
From: Randy M. <mac...@no...> - 2004-06-15 13:38:25
|
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
|
|
From: Jon M. <jon...@er...> - 2004-06-15 14:14:18
|
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, > |
|
From: Mark H. <ma...@os...> - 2004-06-10 16:03:18
|
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...> |
|
From: Mark H. <ma...@os...> - 2004-06-10 17:08:15
|
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...> |
×
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