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 >> >> |