Subject Re: connecting to remote server and sharing connections
Author Adam
> I need to connect to a firebird database server running at a
remote location using broadband internet connection.
>
> The scenario is like this, a firebird database server is running
on W2k Server at location A and I need to connect a few client
machines to this server from location B running windows XP. Broadband
net connection is available at both the places.
>
> What and all is required for this setup?

In its simplest possible case, it involves port forwarding traffic
from 3050 on the router at location A to the database server internal
IP at location A. That is incredibly dangerous and slow, so don't.

> How do I share the connection at location B?

In the hostname setting where you would normally put the database
servers name, you put the IP address or DNS address of the router
(which yes would have to be static)

> Can I share the connection using a switch?

Um, a switch is a LAN thing to plug computers together in a single
LAN. There is probably a switch at location A between your database
server and router, and probably one at location B as well.

>How much connection speed is required to run the application
>comfortably?

Knowing nothing about your application, how can we possibly answer
that? Depending on where you live in the world, broadband means
different things. Where I live, the fastest broadband available at a
sensible price is still significantly slower than a 10 speed hub. How
does your application run on an old slow network? Chances are better
than over the broadband connection.

An application designed for client-server does not generally perform
well when you use it over a slow link. Slow links have to be allowed
for in your design. If you are designing an application to query 6MB
of data from the server when the form opens, how do you think it will
perform when you open the screen on a remote client with a 512K
connection? When designing for slow links, you need to be harder on
the specifications. When a customer says, I want all this data, you
need to tell them that that means it will take X seconds to load the
screen. Do they REALLY need ALL of that data at that point in time, or
can you perhaps have a drilldown design where the screen opens quickly
with minimal data, and if they need more, then they can click and wait
for it. Otherwise you can go down the track of having a local database
with replication.

>Do I need seperate net connection for each client?

No.

You must understand that the protocol used by Firebird is not
encrypted nor is it compressed. Someone with the right knowledge could
easily watch the data as it crosses the wire.

Giving anyone the ability to access the database server is also a bad
idea. Of course they don't know you passwords, but do you really want
to risk some time in the future that a bug in Firebird may leave your
server and data exposed?

Because you have a limited number of locations, you could use a VPN to
take care of it. Otherwise you could create a secure tunnel using
Zebedee. It is a wise idea to have a security layer to put between
your database server and the rest of the world.

If after you have tested your application, you find that even with
compression provided by VPN or Zebedee that the experience is too
slow, then your best hope would be to use Terminal Services. Put a
terminal server in at location A, preferably keep the VPN connection
to that terminal server. We nearly exclusively use terminal services
now for our main application because

* Parts of our application were designed with a CS mindset rather than
with remote clients on slow connections in mind.
* Better hardware, it is easier to convince a company to invest in a
single machine than to upgrade their win98 machines to something more
appropriate. Most applications run much better when they are run on a
state-of-the-art server than some old junk.
* Better OS support, you can use rdp clients on Mac or Linux clients,
as well as any version of Windows without having to specifically cater
for the limitations of whatever client.
* Easier support, support desk can shadow sessions to resolve issues
quicker. They can download backups of the database for developers if
necessary.
* From a commercial standpoint, it works really well for smaller
companies without IT infrastructure. We host our smaller customers,
take care of backups (including offsite strategy), monitoring servers,
buying more hardware if necessary, service packs for a fee that is
less than if they needed to pay someone else to do it. Of course if
they already have the expertise, they are free to self host.

There are of course downsides, like CAL costs, non-admins can't yet
shadow sessions, limited printing support (although there are third
party addons), but I am way OT.

The setup for firebird would look something like:

[db]--[ts]--[vpn]--[sw]--[fw/rtr]<--[net]<--[fw/rtr]--[sw]--[vpn]--[cl]

db = Firebird Database server
ts = terminal server
sw = switch
fw/rtr = firewall/router
cl = client workstation (using RDP)

There is no possibility to directly connect to Firebird from the net.

Adam