Subject | RE: [IB-Architect] Multi-hop server ability |
---|---|
Author | Dan Palley |
Post date | 2000-09-21T22:05:29Z |
I was able to use this feature recently to speed up access to a remote
Interbase machine (running IB 6). Normally, all internet (HTTP, Winsock)
access goes through our proxy server. For most apps, the delay is minimal,
but for some reason, connecting to an IB database takes forever; once
connected, speed is fine.
I found that by connecting to the remote IB server via an IB server on my
local LAN that had direct access to the internet, I was able to get faster
connections. In my case, the local IB server was on 5.6, so I didn't run
into the bug.
Dan
-----Original Message-----
From: Ann Harrison [mailto:harrison@...]
Sent: Thursday, September 21, 2000 3:03 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Multi-hop server ability
At 10:26 PM 9/21/2000 +0100, Paul Wootton wrote:
request coming into the Y-valve (aka why.c) The Y-valve
has a number of back-ends, some stubbed, some present. It
passes the connect string to each back end in turn, asking
if it can open the database. The backends would include
an engine for the current ODS and the remote access layer,
they might also include engines for earlier ODS's, and
at one time, Rdb/VMS and Rdb/Replicator. The identifier
of the current node is stripped off the connect string
before the string is passed to the back ends.
The remote interface analyzes the remaining part of the
connect string, picks a protocol based on the format of
the string, makes the connection, and passes the connect
string to the remote system, with begins the process all
over. By chaining a series of node names you can cause
all your database access to go through several different
machines. Not, in general, a good idea, but if you
have a client and database on machines that don't share
a protocol, it helps (assuming you have a bridge somewhere).
Documentation? No, not really.
Cheers
Ann
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
Interbase machine (running IB 6). Normally, all internet (HTTP, Winsock)
access goes through our proxy server. For most apps, the delay is minimal,
but for some reason, connecting to an IB database takes forever; once
connected, speed is fine.
I found that by connecting to the remote IB server via an IB server on my
local LAN that had direct access to the internet, I was able to get faster
connections. In my case, the local IB server was on 5.6, so I didn't run
into the bug.
Dan
-----Original Message-----
From: Ann Harrison [mailto:harrison@...]
Sent: Thursday, September 21, 2000 3:03 PM
To: IB-Architect@egroups.com
Subject: RE: [IB-Architect] Multi-hop server ability
At 10:26 PM 9/21/2000 +0100, Paul Wootton wrote:
>Ann,The original model for InterBase starts with a connection
>
>Can you point me in the direction of any documentation regarding this
>feature?
>
>It's the first time I've heard of it..
request coming into the Y-valve (aka why.c) The Y-valve
has a number of back-ends, some stubbed, some present. It
passes the connect string to each back end in turn, asking
if it can open the database. The backends would include
an engine for the current ODS and the remote access layer,
they might also include engines for earlier ODS's, and
at one time, Rdb/VMS and Rdb/Replicator. The identifier
of the current node is stripped off the connect string
before the string is passed to the back ends.
The remote interface analyzes the remaining part of the
connect string, picks a protocol based on the format of
the string, makes the connection, and passes the connect
string to the remote system, with begins the process all
over. By chaining a series of node names you can cause
all your database access to go through several different
machines. Not, in general, a good idea, but if you
have a client and database on machines that don't share
a protocol, it helps (assuming you have a bridge somewhere).
Documentation? No, not really.
Cheers
Ann
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com