Thanks for the clarification Nick. So can we decide that we will introduce % as optional while running with existing ip based interface selection? I want to start working on that next week, so if anyone has a problem please let me know. If not ill start off on that tomorrow.
Regards, Varun On Friday, July 09, 2010 09:09:25 pm Nick Wagner wrote: > The proc code was a stopgap. I'm glad you are fixing that. > > I suppose I was thinking more of ipv4 LL addresses than ipv6 ones, where the > address was much more likely to have conflicts. I am certainly fine with > keeping the address scheme as we have it now, but I thought I'd bring this > up since using the MAC to differentiate interfaces has proved very useful > for configuration-free services on machines like laptops, where each NIC > only had one address, but that address changed as the laptop was run in > different locations. And in such instances I have found it useful to write > something that can dynamically detect the ip address changes. In windows, > this is a trivial system notification, on other platforms something as > simple as re-enumerating the NICs every 5 seconds to see if their address > changed inelegantly works -- making that more elegant was always "on my > list". > > But perhaps this is overkill for what we are trying to provide with slpd. > And your points about knowing what mac is to use ipv4 vs. ipv6 are well > taken -- I haven't had to support ipv6 yet beyond some very rudimentary > connections, and have not had to think about the ipv4/ipv6 problem in my > other work. If slpd is being configured away from the default to only run > on one NIC, presumably it is being configured by someone who will know about > these issues, and who will find it easier to work with the ip addresses % > optional interface. > > --Nick > > > > 2010/7/8 Varun Chandramohan <var...@linux.vnet.ibm.com> > > > Hi Nick, > > > > On Thursday, July 08, 2010 09:55:16 pm Nick Wagner wrote: > > > I agree with Roel about handling multiple interfaces. There are definite > > > differences in how sockets operate in the different OSs, especially with > > > respect to multicast and multiple NICs. > > > > > Alright! I think we can skip this. Lets leave it the way slpd does > > currently. However for linux part, i do intend to change > > reading ipv6 ips from proc to system apis. I have written that code tested > > it well. Is that ok with all? The older proc code > > had major issues with endianess when tested in power system. > > > I'm very glad to see that people are still actively working on making > > > openSLP better. I haven't been able to get back to it for quite a while > > -- > > > I had hoped to test some of these changes on Windows and OS X by now, but > > > work has taken over my time. > > > > > > I had a comment on changing net.slp.interfaces. IP address % interface > > > doesn't fully solve the specification issues when dealing with link-local > > > addresses, as those can change underneath you. The same could > > potentially > > > happen with a DHCP address. What if we changed net.slp.interfaces to > > > something that also allowed you to select the NICs via MAC address (with > > the > > > optional % interface for full differentiation on OSs that supported it)? > > > > > Iam a bit confused here. So, if we change it to MAC how can a user specify > > which ip openslp must use? > > I mean how to even say weather ipv4 or ipv6 should be used. If its ipv6, > > which ip of the list of ips for that interface must be used? > > My understanding is that LL address are system generated from the MAC > > address. Although i agree a link local address can be deleted and > > another LL address can be added, i feel this might not be the right > > approach. I have not though this through, may be we should introduce > > dynamic ip address change monitor? Like "ip monitor addr" does? Will this > > help? Just out of curiosity there must be many other projects that > > need requirement like this. How do they handle? I got your explanation > > wrong, please explain. :-) > > > > > > --Nick > > > > > > > > > > > > On Thu, Jul 8, 2010 at 2:17 AM, Roel van de Kraats < > > r...@advancedcargo.eu>wrote: > > > > > > > > > > > > > > > On 07/08/2010 08:49 AM, Varun Chandramohan wrote: > > > > > Hi All, > > > > > > > > > > I have been looking into openslp code and i found a few changes > > > > that might make things better in openslp. I dont have patches to share, > > but > > > > i will create them if everyone here agrees. > > > > > > > > > Dear Varun, > > > > > > > > Thanks for putting this effort in improving Openslp and for discussing > > > > your ideas on the mailing list. > > > > > - Multiple Binding Issue: I observed that, when the list of > > interfaces is > > > > not specified in the config file, the slpd daemon reads all interface > > > > information and binds to all address of all interfaces. I feel this is > > a > > > > overkill. When no specific interfaces are given, its much easier to > > bind to > > > > :: or INADDR_ANY. > > > > > > > > > That sounds simpler indeed. However, by doing so a lot of > > responsibility > > > > is moved from slpd (which we can adapt to our needs) to the OS (for > > > > which this is much harder). Since handling multiple interfaces the > > > > correct way is quite delicate, I'd rather keep this responsibility on > > > > the slpd side. And although receiving messages may become simpler this > > > > way, for sending messages it is still necessary to specify the > > > > interface; otherwise the 'default' interface (chosen by the OS) is > > used. > > > > Finally, since the functionality for handling different interfaces is > > > > needed anyway (in case they are specified in the cfg), it is, in my > > > > opinion, better to have one mechanism (behavior) for the different > > > > situations. > > > > > Proposal: In SLPDIncomingInit() function all the address are bound. > > > > > > > > > > if (G_SlpdProperty.interfaces != NULL) > > > > > > > SLPIfaceGetInfo(G_SlpdProperty.interfaces,&ifaces,&G_SLPDProcInfo, > > > > AF_UNSPEC); > > > > > else > > > > > ifaces.iface_count = 0; > > > > > When the interfaces are found to be NULL, we can assume that slpd > > must > > > > bind to all inetfaces. So depending on the config file we have 3 cases. > > > > > Case 1: Only IPv4 enabled. We can create TCP/UDP sockets with > > INADDR_ANY. > > > > > Case 2: Only IPv6 enabled. We can create TCP/UDP sockets with :: > > > > > Case 3: Both IPv6& IPv4 enabled. We can create sockets with :: but > > use > > > > IPV6_V6ONLY option set. > > > > > > > > > > This way we will have only 1 or 2 sockets listening instead of all. > > > > Improves performance as well. My only doubt is how this works with > > Windows. > > > > Iam no expert in that. > > > > > If the interfaces are specified then we do exactly what is done now. > > Is > > > > that ok with everyone? > > > > > > > > > > - Wrong Representation Of Interfaces In Config File: Although it > > looked > > > > at first as a minor issue, this has caused multiple problems to basic > > > > functionality. Openslp takes in ipaddress without the need for > > interface > > > > information. > > > > > This leads to major issues. The function v6GetScope() is faulty > > function. > > > > > > > > > > There can be cases when interfaces can have same ips. Eg: > > > > > eth2 Link encap:Ethernet HWaddr 00:06:29:55:60:81 > > > > > inet6 addr: fe80::206:29ff:fe55:6081/64 Scope:Link > > > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > > > RX packets:4037 errors:0 dropped:0 overruns:0 frame:0 > > > > > TX packets:134395 errors:0 dropped:0 overruns:0 carrier:0 > > > > > collisions:0 txqueuelen:1000 > > > > > RX bytes:436006 (425.7 KiB) TX bytes:14655216 (13.9 MiB) > > > > > Interrupt:16 Base address:0x2200 > > > > > > > > > > eth2.30 Link encap:Ethernet HWaddr 00:06:29:55:60:81 > > > > > inet addr:192.168.1.2 Bcast:192.168.1.255 > > Mask:255.255.255.0 > > > > > inet6 addr: 3001::1/128 Scope:Global > > > > > inet6 addr: fe80::206:29ff:fe55:6081/64 Scope:Link > > > > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > > > > RX packets:367 errors:0 dropped:0 overruns:0 frame:0 > > > > > TX packets:15830 errors:0 dropped:0 overruns:0 carrier:0 > > > > > collisions:0 txqueuelen:0 > > > > > RX bytes:40872 (39.9 KiB) TX bytes:1650541 (1.5 MiB) > > > > > > > > > > The LL address of both interfaces are same, In which case it becomes > > > > clear viewing the v6GetScope() code that the scope id returned will be > > same > > > > for both interface but in reality it is different. This results in > > binding > > > > to > > > > > only one interface. This is wrong. This has to be changed. This also > > is > > > > the case with ips specified in the config file. > > > > > > > > > > net.slp.interfaces = fe80::206:29ff:fe55:6081 > > > > > > > > > > There is no way of saying which interface this must bind to. > > > > > > > > > > Proposal: The posix standard must be adopted to fix the issue. The > > > > interface must be specified. > > > > > net.slp.interfaces = > > > > fe80::206:29ff:fe55:6081%eth2.30,2001::1%eth1,10.0.0.1%eth0 > > > > > > > > > > The<ip>%<iface> is standard posix method. This will greatly help in > > > > getting the correct scopeid. > > > > > > > > > This is (probably) not described in the SLP RFC and I don't know if it > > > > creates an incompatibility, but when this extension is made optional, > > it > > > > sounds fine to me. I assume interface names never contain a ',' > > > > otherwise that would clash with the list separator. > > > > > > > > BR, > > > > Roel > > > > > I have already looked into the code and made a temporary fix for the > > > > above problem. But i want to rewrite that patch to make it better. If > > > > everyone is ok with the above i will start working on it. Please reply > > back > > > > with any > > > > > issues. I have no windows programming knowledge, so if iam making a > > > > blunder here, do let me know. > > > > > > > > > > Regards, > > > > > Varun > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > This SF.net email is sponsored by Sprint > > > > > What will you do first with EVO, the first 4G phone? > > > > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > > _______________________________________________ > > > > > Openslp-devel mailing list > > > > > Openslp-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/openslp-devel > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > This SF.net email is sponsored by Sprint > > > > What will you do first with EVO, the first 4G phone? > > > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > > > _______________________________________________ > > > > Openslp-devel mailing list > > > > Openslp-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/openslp-devel > > > > > > > > > > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Openslp-devel mailing list Openslp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-devel
