Hi Richard,
The fact is we should be using something closer to the hardware to
indicate an interface - like the MAC address or something. The point of
that code is to allow slp server to bind to the correct card during
startup. If the bind interface is specified as ADDR_ANY or 0, then slp
binds to all cards as ADDR_ANY. If a specific address is given, then slp
server will only bind to that card. The problem is that we're trying to
allow the administrator to bind to a given bit of hardware on his box -
a particular network card, but we're using a mechanism to specify cards
that happens to be more convenient than specific. It's a commonly
accepted technique to bind to a particular bit of hardware using an ip
address because generally servers don't run DHCP and network interfaces
are then hand-configured to a particular address. Even MAC addresses can
be changed manually these days, but not remotely - as in the case of
DHCP setting an ip address on an interface. So if we used MAC addresses
to specify interfaces, there'd be no chance of a remote configuration
changing which card we bound to. We could easily add code that would
recognize a MAC address and use it rather than an IP address.
John
On 11/18/2010 02:43 AM, Morrell Richard (external) wrote:
> I have been asked by one of our developers whether he can use
> hostnames in the net.slp.interfaces property.
>
> Looking at the code (SLPIfaceGetInfo), I see that it uses inet_pton,
> which expects a numeric address, so I've told him that he can't. In
> fact, his issue was with being assigned a different address via DHCP,
> so I told him to try commenting out the net.slp.interfaces property,
> so that the daemon uses the interface address as allocated (the
> machine is single-homed).
>
> However, I was wondering if there was a technical reason the
> interfaces property is restricted to numeric addresses ie. would it
> be possible to resolve the name to an interface, then choose IPv4
> and/or IPv6 addresses based on which protocols are enabled ? This
> should work for IPv4, but I confess I don't have much experience with
> IPv6.
>
>
> --
>
> Richard Morrell
> Middleware & Infrastructure
>
> *Thales UK
> *Poseidon House, Ashurst Drive, Cheadle Heath Stockport SK3 OXB - UK
>
>
> Tel: +44 (0)161 741 3426.
> e-mail: richard.morr...@uk.thalesgroup.com
> <mailto:richard.morr...@uk.thalesgroup.com>
>
> /Please consider the environment before printing a hard copy of this
> e-mail.
> /
> The information contained in this e-mail is confidential. It is
> intended only for the stated addressee(s) and access to it by any
> other person is unauthorised. If you are not an addressee, you must
> not disclose, copy, circulate or in any other way use or rely on the
> information contained in this e-mail. Such unauthorised use may be
> unlawful. If you have received this e-mail in error, please inform us
> immediately on +44 (0)1932 824800 and delete it and all copies from
> your system.
>
> Thales Corporate Services Limited. A company registered in England and
> Wales. Registered Office: 2 Dashwood Lang Road, The Bourne Business
> Park, Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 959962.
>
> Thales UK Limited. A company registered in England and Wales.
> Registered Office: 2 Dashwood Lang Road, The Bourne Business Park,
> Addlestone, Weybridge, Surrey KT15 2NX. Registered Number: 868273
>
>
>
> 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.
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today
> http://p.sf.net/sfu/msIE9-sfdev2dev
>
>
> _______________________________________________
> Openslp-devel mailing list
> Openslp-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openslp-devel
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
