Hi Varun, I agree with Roels' comments regarding making the network interface name optional in the net.slp.interfaces list, for backwards compatibility at least. I'm sure there will be many setups where there will not be a conflict in IPv6 addresses between interfaces, so there would be no need to specify the interface.
I also agree in general with his points about the multiple binding issue. Also, if the issue with permissions gets resolved, then there will be IPv6 multicast sockets (up to 1024) created for the services, so the performance hit of having multiple sockets for interfaces is likely to be small compared to having multiple service sockets. -----Original Message----- From: Varun Chandramohan [mailto:var...@linux.vnet.ibm.com] Sent: 08 July 2010 09:25 To: Roel van de Kraats Cc: Morrell Richard (external); John Calcote; 'openslp-devel@lists.sourceforge.net'; dlste...@us.ibm.com; samud...@us.ibm.com Subject: Re: [Openslp-devel] Suggestions For OpenSLP Imporvements. Hi Roel, Thanks for your reply. My comments inline. On Thursday, July 08, 2010 12:47:17 pm Roel van de Kraats 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. ok to avoid the OS needing to do all the routing decisions, you think its better to have control in openslp. Sounds ok to me. How about others? > > 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. > I have to revisit the RFC too, but i wonder how this was missed in RFC. I mean, if a interface is given without the interface what assumption are we supposed to make? To me it sounds wrong. Making it optional might work, but that will make a code a little bit complicated. I will start to work this way. If anyone has any idea on this do let me know. > 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 email, including any attachment, is a confidential communication intended solely for the use of the individual or entity to whom it is addressed. It contains information which is private and may be proprietary or covered by legal professional privilege. If you have received this email in error, please notify the sender upon receipt, and immediately delete it from your system. Anything contained in this email that is not connected with the businesses of this company is neither endorsed by nor is the liability of this company. Whilst we have taken reasonable precautions to ensure that any attachment to this email has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. ------------------------------------------------------------------------------ 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
