[sles-beta] php disappeared in beta6?

[Joe Doupnik]

Josef,
     I have dealt with SLP since it first arose decades ago as a way of 
finding printers with duplex printing and colour.
     First, do not use multicast or broadcast for services. Those are 
dandy on a home/SOHO network. They don't work or survive when routers 
are encountered nor when the local wires have lots of other strange 
things (think running in the rack of an ISP somewhere). It may work in 
one spot but not in the room across the hall (different subnets). Many 
servers reject multi/broadcast traffic. Thus dependence on 
multi/broadcast is to ensure failure, and you designed it that way.
     As stated previously, believing and acting on multi/broadcast 
traffic is naive (at best). It is akin to "Click Here." Sound 
engineering practice does not countenance such acts.
     Second, SLP has the loose notion of SCOPES where both clients and 
servers can rendezvous on one of many SCOPE names. That means 
configuration details, else failure. It does not scale at all. But you 
designed it that way.
     Third, SLP requires existing SLP serving software be running on the 
network and within radar range of all clients. That becomes an 
assumption without which many SLP clients will fail, and you designed it 
that way.
     DNS has the facilities to resolve names to numbers. It scales. It 
is already present. Use unicast to speak to known points.
     These matters were understood about twenty years ago. My Brainshare 
presentation on SLP is long since lost in the mists of time. The above 
points should be sufficient warning to abandon it. Auto discovery is 
designed to fail, as I may have mentioned.
     Joe D.

On 20/05/2014 12:29, Josef Reidinger wrote:
> On Tue, 20 May 2014 12:18:07 +0100
> "Joe Doupnik" <jrd at netlab1.net> wrote:
>
>> On 20/05/2014 12:05, Josef Reidinger wrote:
>>> On Tue, 20 May 2014 11:57:30 +0100
>>> "Joe Doupnik" <jrd at netlab1.net> wrote:
>>>
>>>>        Thanks for chiming in Kai. Your comments simply reinforce
>>>> what I speculated about. Removal has nothing, nada, to do with
>>>> offering more, as anyone can see at first glance. It has
>>>> everything to do with the people who want customers to use the
>>>> "more" facility. Thus the attempts at gloss and justification
>>>> continue.
>>>>
>>>>        While here, addressing points by Richard Brown today. Auto
>>>> discovery of services is basically "designed to fail." One would
>>>> not want that rating in one's engineering copybook.
>>>>        Broadcast/multicast are normally terminated at routers, often
>>>> terminated upon entry to servers as well. A person/box which
>>>> naively believes what arrives from goodness knows where gets what
>>>> they deserve. The broad/multicast approach went out more than 20
>>>> years ago when MS Windows and Novell IPX traffic flooded our
>>>> networks. May I recommend sound engineering practice here, unicast
>>>> using known destinations. No "Click Here" for our servers.
>>>>        Joe D.
>>>>
>>> Well, we use well known
>>> SLP protocol
>>> ( http://en.wikipedia.org/wiki/Service_Location_Protocol ) and it
>>> do multicasting. If SLP (multicasting) is disabled in your network,
>>> then you still can pass on boot command line url to such server.
>>        You can't be serious. A server needs booting, and we are
>> supposed to remember to add a particular chunky command line in the
>> middle of that process?
> There is probably misunderstanding. You need it only during
> installation. For massive installation often is used PXE boot with
> predefined parameters. So you need to manually type it only when doing
> installation without PXE, without SLP and without registering against
> scc.suse.com
>
>> Not likely to be accepted in the field. Nor
>> will be SLP; too may variations about its use, and its *cast radar
>> range is severely limited at routers.
>>       Long term experience with SLP indicates that it is best ignored
>> entirely. I gave a Brainshare talk on its short comings and offered a
>> better design many many years ago.
> I wasn't on Brainshare and did not hear your talk. Can you share with us
> what is such better design and if is standartized and documented
> similar like SLP with its RFCs?
>
> Josef
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta