Date: Wed, 28 Oct 1998 11:19:15 -0800 From: Terry Lambert <terry@whistle.com> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: small@FreeBSD.ORG Subject: Re: Unified Configuration Interface Message-ID: <36376E33.20DB@whistle.com> References: <XFMail.981028122123.asmodai@wxs.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeroen Ruigrok/Asmodai wrote:
] Have to read up on SLP, but afaik SLP will be/is used by Novell
] in NetWare 5 with Native IP to replace SAP.
Actually, SAP was obsolete the day NDIS shipped; the only
reason it stuck around is Bindery emulation for older clients
and servers that weren't upgraded to uses NDIS. The process
that replaced it is the NDIS "pull model", called "skulking"
(like NIS's push model, but without the dependency on a single
master, but with the potential for replicate desynchronization
for the period of time between a boot after outage and a "skulk").
] So if I may base my conclusions on SAP, it will request per
] a broadcast certain servers/services, get a reply back and
] then use those services via SLP or just by making TCP
] connections or just dumping UDP datagrams? Correct me if I
] am wrong, but I don't have the time at the moment to dig
] through that RFC.
RFC 2165, Service Location Protocol, Standards Track.
Actually, SLP uses multicast and DHCP.
I. There is a directory agent
Scenario A (most desirable):
1) Client boots
2) Client gets IP and other information, including
address of directory agent, via DHCP
3) Client unicasts requests to the directory agent
Scenario B:
1) Client makes multicast request to directory agent
discovery address to get address of directory
agent
2) Directory agent responds to client
3) Client unicasts requests to the directory agent
Scenario C (least desirable):
1) Client is preconfigured with knowledge of the
address of the directory agent
2) Client unicasts requests to the directory agent
II. There is not a directory agent
Scenario A:
1) Client multicasts a request to the service-specific
multicast address, to which the service it wishes
to locate will respond.
2) All service agents listening to this multicast
address will respond, provided they can satisfy
the request.
Scenario B (the pick-list):
1) Client wishes to obtain a list of all services.
2) Client applies a retransmission/convergence
algorithm (everyone respond, except you, you, and you)
to get all late/avoidance responses.
So basically, it's not succeptible to "SAP storms", and it's
scalable to the enterprise level because it has the capability
of a directory agent to act as a well-known proxy responder for
the service agents.
In a small network, a directory agent isn't necessary. In a
larger network, a directory agent (or DA) reduces the amount
of network traffic.
In a very large network where a single central repository is
unfeasible, or in the case where you want to administratively
restrict access to service clusters, you define a "scope",
which can apply to the services advertised by service agents
and by proxy, by directory agents. Think of a color printer
that only wants to be used by the marketing department. 8-).
] > That would make it most probably a client implementation only.
] > I mention ACAP because it's a fairly small client implementation
] > as well.
]
] Having used ACAP I can say it's a fun protocol ;)
Yes, but it fails the transaction test, and if you wanted
to use it to configure an appliance (which is a server),
then you have to run the protocol backwards.
It also won't compile with the GNU toolchain without a number
of modifications, and won't run on FreeBSD without STL modifications
for FreeBSD's pthreads, and pthreads implementation modifications
(currently, to drop pthreads *back down* to the Draft 4 level to
avoid confusing the STL and the ACAP code).
I'm pretty sure that we have the only ACAP that runs on FreeBSD,
and will until FreeBSD upgrades to the G++ 2.8.1 + Jeremy Allison's
per-thread exception stack code changes to libgcc, and FreeBSD
supports the Moscow center for SPARC computing's STL implemetnation.
] > The main issue is that there needs to be someone, somewhere,
] > to "be the king"; whether this just means a machine to export
] > an NIS+ service, or whether this means SNMP or LDAP is undefined.
]
] Well, ye mean here the MAster server that is the general backup
] provider shouldst departemental/floor servers not be reachable?
] Or am I thinking in way the wrong direction?
Think in terms of where you would store credential information
for 500 accounts for a printer booting FreeBSD diskless out of
ROM.
] > ] What worries me, though, is that the only one (free)
] > ] implementation of snmp agent that I'm aware of is, well, more
] > ] than bulky...
]
] Ok, but basing on the equipment we use at work (HP OpenView) I
] tend to prefer SNMP in use with MIBs. Although we also write
] out own shellscripts for that.
Actually, the IBM SNMPv2 reference implementation is pretty
small, and allows registration of subtrees by other programs.
This goes a long way towards a "manage me" API. But it's
a Streams MUX implementation; in theory, you could use dlopen
and .so's with a minor redesign of the net interface code to
make it work the same way as a daemon.
But again, the point of MIBs is to get standards compliant
schema for exposed tunables, and the method of exposure is
much less interesting.
] > But the point of mentioning RFC 2307 wasn't to specifically
] > advocate LDAP; it was to point at a MIB that defines most of
] > the things needed for storing all NIS+ data. The MIB is, as
] > above, schema information, totally seperate from implementation.
]
] Heh, schema sounds so alike to Novell's NDS schema ;)
The word "schema" in the context of database design means
only "record contents without specifying ordering or indices";
it's easier to say "schema". 8-).
-- Terry Lambert
-- Whistle Communications, Inc.
-- terry@whistle.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36376E33.20DB>