Bill,

Instead of using the '$' as a marker, could the DB connect logic be
modified slightly such that:

1) Server would attempt to use db string as normal DB file
specification

2) If connection fails, then check db string against alias "table"

3) if connection still fails, report/raise connection error.

Using this approach would require no change to the clients, and could
perhaps even allow for older clients to use alias.

I would expect that the time required for step #1, in the case where an
alias is used would add < 10ms to the connect timing.


Sean

-----Original Message-----
From: Bill Karwin [mailto:bill@...]
Sent: Tuesday, August 08, 2000 2:50 PM
To: IB-Architect@egroups.com
Subject: Re: [IB-Architect] Re: Is it _really_ necessary to expose the
location of the database file?

> I don't think this possibillity is enough to stop us from making
> database aliases available.

Agreed. Aliases would be good. I have some comments and proposals.

For the sake of illustration, assume the syntax for an alias is CONNECT
"server:$alias" where the $ symbol indicates that the following string
is an alias name, not a pathname. This allows the NetBEUI and IPX/SPX
syntax to work too: //server/$alias, server@$alias.

I can imagine aliases being implemented in the client access method or
in the server access method. That is, one could CONNECT "$alias" and
the client gds32.dll looks up $alias and finds it maps to
"linuxserver:/usr/local/data/blah/blah/blah.gdb".

Alternately, the server could do the mapping: in CONNECT
"linuxserver:$alias" the ibserver daemon would look up $alias and find
that it maps to /usr/local/data/blah/blah/blah.gdb.

In fact, in InterBase, the access method is somewhat recursive. You can
actually do this: CONNECT "ntserver:linuxserver:/path/data.gdb". The
way InterBase handles this is the following:
1. Client opens a TCP/IP connection to ntserver, removes the "ntserver:"
part of the string and sends the remainder.
2. The ibserver service on ntserver sees that the syntax matches a
host:path pattern.
3. ibserver on ntserver invokes another remote connection to
linuxserver, removes "linuxserver:" from the string and sends the
remainder.
4. The ibserver (or gds_inet_server) process on linuxserver sees the
/path/data.gdb and opens the corresponding file on its filesystem.
(note that all data traffic now goes through two network connections
before it reaches your application; not recommended for efficiency, but
you can use it for proxy servers.)

This illustrates that the server functions as a sort of client. If
aliases are implemented in the client layer, they would implicitly work
in this environment, so CONNECT "$alias" would work, and CONNECT
"serverhost:$alias" would also work. You can of course map $alias to a
simple path, without a second hostname included.

Now to discuss implementation:

InterBase's jrd/why.c contains the code that does all the local/remote
access methods that I described above. (Why "why"? It has to do with a
Y-valve, which is to convey that a connect string can follow one of
multiple paths to resolve the connection.) The architecture in why.c
treats local and remote as SUBSYSTEMS, and allows for more subsystems to
be added transparently. It's complex, but once done it works with all
the other subsystems nicely. This is the right way to do aliases, as a
new subsystem.

Where to record the alias definitions:

1) Windows registry.
Advantages: Somewhat secure. Consistent with Win32 programming
practices.
Disadvantages: Win32-specific. Obscure, proprietary repository,
requiring a special front-end app for easy configuration.

2) ibconfig.
Advantages:
- Repository already exists on all IB clients.
- Cross-platform solution.
- Easy to edit.
- Easy to deploy.
Disadvantages:
- Write security is problematic.
- Read security is impossible.

3) LDAP server.
Advantages:
- Takes advantage of existing front-end tools for configuration (e.g.
NDS).
- Well-established directory standard.
- Cross-platform solution.
- Aliases can be recorded centrally.
- OpenLDAP is available as an opensource LDAP server
- Most enterprises have one already anyway.
- Security is configurable.
- Deploying groups of aliases is easy with LDIF files.
- Values are queryable on demand, allowing aliases to be updated
while apps and ibservers run uninterrupted.
Disadvantages:
- Not the most "lightweight" distribution, if it requires a second
server to be set up.
- Client must at least know the hostname for the LDAP server (named
in ibconfig?)

Another approach would be to allow multiple alias repositories. For
instance, I really like the LDAP approach (could you tell?), but it
shouldn't preclude an ibconfig repository too. Perhaps the
implementation could be specified in the ibconfig (e.g., 'ALIASES LOCAL'
or 'ALIASES LDAP servername').

On the other hand, why limit to one or the other? Why not allow both
mechanisms simultaneously? Local alias definitions would take priority
(think of DNS servers vs. local hosts file).

Example: gds32.dll would load aliases from ibconfig upon startup. If I
try to connect to an alias, it first searches its cached alias list, and
if it can't find the alias I want, it then requests resolution from the
LDAP server. If that doesn't work, then it returns an error.

Regards,
Bill Karwin



To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com