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
