At 02:39 PM 17/11/2004 +0100, you wrote:

>Nando,

>Helen,
>as I suspected most of the confusion we have happens on the
>terminology ground, not in the substance.
>
>I have to admit that each time I happen to get involved in this kind
>of discussion I am tempted to forward everything to Dmitry Y, since
>when I was saying that overriding the IPServer connection string
>syntax to do embedded connections would have caused confusion he
>assured that wouldn't happen. It has happened on a regular basis since
>then and it is happening still. Oh well...

I wish you *would* forward it to Dmitry! Ideally, then he can sort out
*everyone's* confusion and update the README if he thinks there is an
essential deficiency there.

>Let's try to get a common terminology for the benefit of all. Firebird
>supports several *communication protocols*. Examples:
>
>1) Local (a.k.a. IPServer) c:\some\file\name.fdb
>2) TCP/IP hostname:c:\some\file\name.fdb
>3) NetBeui (a.k.a. Named Pipes) \\hostname\c:\some\file\name.fdb

3) is inaccurate. The protocol is Named Pipes: it happens to use the
NetBeui transport in the various Windows distributions.

>4) IPX/SPX (a.k.a. Netware) hostname@c:\some\file\name.fdb
>
>All of these are supported by the *client library* fbclient.dll.
>
>The *embedded engine* fbembed.dll embeds a client library and a
>Firebird SS engine in one file.

Correct.

>Its client library supports 2), 3) and
>4) above for connectiong to a *stand-alone Firebird server*,

Correct, speaking of the client library in isolation from the embedded server.

>and in
>addition supports:
>
>5) Embedded c:\some\file\name.fdb
>
>Since 1) and 5) share the same syntax, one of them has to give. Thus,
>fbembed cannot support 1). This means that it cannot be used as a
>client for a local (meaning on the same machine) stand-alone Firebird
>server via the Local/IPServer protocol.

...except for 4), which is a red herring...but the implication of your
reasoning adds confusion where there is none, since you imply that 1) and
5) are two different protocols. They aren't. The conflict (if it were
allowed, but is not) is that, while the IPServer client is operating in the
same IPC space as the embedded server (as it does) it can't be
simultaneously operating in the same IPC space as another server.

>It *can* be used as a client
>for a local Firebird server via any other supported protocol.

Not on any of my Windows systems, other than via the network (TCP/IP or
Named Pipes). Named Pipes doesn't work for a local connection to a
stand-alone server if there is no network.

>Aside: when using the TCP/IP protocol with "localhost" or "127.0.0.1"
>as hostname, it is conventional to say that we are using the "TCP/IP
>local loopback protocol". Actully there's no such thing as a loopback
>protocol per se: it's just that the TCP stack detects localhost and
>127.0.0.1 and doesn't send the packets over the wire.

That *is* what "local loopback" means.

It's not really an "aside" at all in the context of local
connections. Let's clear up this term "stand-alone server". It refers to
a machine that is running a database server but is NOT connected to a
network. On a stand-alone server, provided the TCP/IP service is enabled,
you can connect using TCP/IP local loopback, even if there is no NIC
installed on the machine. Moreover, it's what you *must* do on Windows if
the stand-alone server is Classic.

>This can be thought of as an optimization that happens at a much lower
>level that Firebird and as such, as far as the Firebird client library is
>concerned, there's no difference between
>localhost:somefilename
>
>and
>
>somehostattheotherendoftheworld:somefilename

It is true to say that the regular firebird client (i.e., one that isn't
embedded with a server) doesn't distinguish between localhost and a
networked host. Firebird isn't alone in this: http and other servers on
stand-alone machines depend on its being handled at a lower level, too.

However, it's not true that the client in fbembed.dll can't distinguish
between localhost (pointing to 127.0.0.1 or another local loopback address)
and a networked host (pointing to an IP address that is being broadcast by
the network). I don't know how it makes the distinction, but I know for
sure that it does. It distinguishes 10.12.13.1 (the dev machine's network
address) from 127.0.0.1 and allows the fbembed.dll client to attach to the
local (full) server by the former but not the latter.

>I hope this clears things a bit.

I don't think so.

>If it does, it would be useful to publish it somewhere. If it doesn't,
>then it should be corrected or things should be made clearer by themselves! :-)

Since this isn't the first time you have made claims about the connection
behaviour of fbembed.dll that I can't reproduce, at least here on a network
of Win2K machines, it would be a worthwhile exercise for you to get
together with Dmitry and, between you, to update the readme in a way that
dispels the potential or actual myths.

In any case, the protocol conflicts should disappear in Fb 2, with Dmitry's
reworking of embedded to use XNET instead of IPServer.

./heLen