| Subject | Local connection on Windows, was Re: [IBO] "Cannot open file" error |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-01-19T08:13:14Z |
At 10:01 AM 17/01/2003 -0800, you wrote:
of the client/server networking layer (exact details I can't supply off the
top of my head...but search the old Mers archives for a posting from
Charlie Caro around April/May 2000 for a description). To do so, the
client runs in the same inter-process communication space as the
server. This is fine if only one instance of the client is running on the
machine, or if multiple instances don't step on one another's
spaces. Anything "other" can cause overwriting of one instance's spaces by
another.
To put it another way (less technical and therefore less likely to be
misrepresented by me), since IB on Windows went to SuperServer, several
problems arose with local connections that were attributed variously to
broken multi-threading in client applications, illegal deployment of local
IB to unlicensed clients, sunspots, whatever. This went on through all the
"5.x's" and onward into the IB 6 betas. It wasn't really until those
halcyon days in the first half of 2000, that senior IB software engineers,
freed (albeit temporarily) from the yoke of marketing spin, were allowed to
spill the beans and admit that the Windows local connection was not
guaranteed to be safe for multiple-connections or even multiple threads.
But TCP/IP local loopback *is* safe, because the client-to-server
inter-process communication uses the same network-layer mechanism as "real"
TCP/IP.
server goes down with it because of the IPC space corruption, or it is the
server that crashes first and takes the clients down with it. Someone on
Firebird-devel might be able to explain the sequence of events.
transactions, but not data corruption, that I know of.
One circumstance where it's ok to use it is when sysdba is logged on with
exclusive access, e.g. when running gfix. Another OK situation will be
where you have a stand-alone setup and your single-user application doesn't
use events and doesn't allow multiple client instances to be running
simultaneously.
We have all *done* the multiple client instance thing during development,
and have gotten away with it, so reproducible cases in the development
environment can be quite elusive. It's flukey.
It seems ok for sysdba to log in locally, e.g. to run gsec or gbak - while
all there are remote connections. I say "seems", because I can't actually
recall anyone posting a thread like "using gsec | gbak crashes the server".
My take on local connection is that it's a legacy from Win 3.x, initial
Win95 and maybe Winnt 3.x, when TCP networking didn't ship "out of the box"
with Windows, and Borland needed a quick fix to enable Delphi 2 developers
to continue to use something equivalent to the old LIBS for development
with IB 4.2 SuperServer...
Footnote: There's even the possibility of getting something like LIBS back
again with Firebird 2, since one or two of the developers seem very keen to
restore and enhance the Classic server for Windows...but whether anyone
would consider there was any value in "fixing up" local connection on
Windows is another thing altogether.
cheers,
Helen
> > >Tip: hard-wire TCP/IP and give 'localhost' for the Server in the caseThe reason it's not thread-safe is that it, for SuperServer, it is a hack
> > >where you are sure that the client and the server are on the same
> > >box. cpLocal is very flukey and it's certainly not thread-safe.
>
>Helen,
>
>I've got to thinking more about this. Could you explain a bit more about
>how cpLocal is very flukey and not thread-safe?
>
>How is it flukey?
of the client/server networking layer (exact details I can't supply off the
top of my head...but search the old Mers archives for a posting from
Charlie Caro around April/May 2000 for a description). To do so, the
client runs in the same inter-process communication space as the
server. This is fine if only one instance of the client is running on the
machine, or if multiple instances don't step on one another's
spaces. Anything "other" can cause overwriting of one instance's spaces by
another.
To put it another way (less technical and therefore less likely to be
misrepresented by me), since IB on Windows went to SuperServer, several
problems arose with local connections that were attributed variously to
broken multi-threading in client applications, illegal deployment of local
IB to unlicensed clients, sunspots, whatever. This went on through all the
"5.x's" and onward into the IB 6 betas. It wasn't really until those
halcyon days in the first half of 2000, that senior IB software engineers,
freed (albeit temporarily) from the yoke of marketing spin, were allowed to
spill the beans and admit that the Windows local connection was not
guaranteed to be safe for multiple-connections or even multiple threads.
But TCP/IP local loopback *is* safe, because the client-to-server
inter-process communication uses the same network-layer mechanism as "real"
TCP/IP.
>When you say it's not thread safe, do you mean that it makes my client appI don't know whether it is just the client that crashes, or whether the
>non-thread-safe, or it makes the server process non-thread-safe?
server goes down with it because of the IPC space corruption, or it is the
server that crashes first and takes the clients down with it. Someone on
Firebird-devel might be able to explain the sequence of events.
> WhatAVs, hang-ups, server crashes...data loss, of course, from unfinished
>kinds of problems would you expect to see, using it? Do you mean that it's
>bad to use in any circumstance, or that it's bad to have both cpLocal and
>TCP/IP connected to the same server, or that an app using cpLocal shouldn't
>be run more than once, or that a single instance of an app shouldn't have
>more than one cpLocal connection, etc.
transactions, but not data corruption, that I know of.
One circumstance where it's ok to use it is when sysdba is logged on with
exclusive access, e.g. when running gfix. Another OK situation will be
where you have a stand-alone setup and your single-user application doesn't
use events and doesn't allow multiple client instances to be running
simultaneously.
We have all *done* the multiple client instance thing during development,
and have gotten away with it, so reproducible cases in the development
environment can be quite elusive. It's flukey.
It seems ok for sysdba to log in locally, e.g. to run gsec or gbak - while
all there are remote connections. I say "seems", because I can't actually
recall anyone posting a thread like "using gsec | gbak crashes the server".
My take on local connection is that it's a legacy from Win 3.x, initial
Win95 and maybe Winnt 3.x, when TCP networking didn't ship "out of the box"
with Windows, and Borland needed a quick fix to enable Delphi 2 developers
to continue to use something equivalent to the old LIBS for development
with IB 4.2 SuperServer...
Footnote: There's even the possibility of getting something like LIBS back
again with Firebird 2, since one or two of the developers seem very keen to
restore and enhance the Classic server for Windows...but whether anyone
would consider there was any value in "fixing up" local connection on
Windows is another thing altogether.
cheers,
Helen