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.
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)?
--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
