Bill,
You got some very good advice already but I'd like to add a couple of
thoughts.
The way to look at digital trunks is, as Ben said, as a pipe of a
certain size: you buy so much bandwidth and it's there all the time.
There are two way to manage the bandwidth: statically, meaning it is
sliced up in fixed widths (in and out, voice and data), or dynamically,
meaning it is managed according to demand i.e. if 1 user is busy with
e-mail, he can give up bandwidth to someone watching streaming video.
Not all vendors provide both types.
These digital connections can bog down because the telcos allow DSL
providers (also themselves) to sell more bandwidth than is available in
the CO because of the "unlikelihood" that they will hit 100%
utilization. The bandwidth you can get is only as much as the narrowest
available between you and your destination so your max. bandwidth is the
width of your narrowest bottleneck. (The argument of cable vs. DSL can
boil down to where do you like your bottleneck located - out in the
street or further away?) You would, therefore, have to base the need for
bandwidth on the same type of calculation that the telcos make: average
utilization vs. peak. Bottom line is how often is your customer prepared
to tolerate overload?
Since it is apparently a Sisyphean task to secure Windows NT/2000
against the hole du jour, I wonder if it may be better to duck the
issue. If the customer will accept the latency, another way around might
be to keep the internet-accessible database separate from the main LAN
database and use some batch mechanism to update even every few minutes.
Thus your own web server crosses the firewall and the only data going to
your main database is your own. Perhaps someone else on the list is
already doing this.
Nicky
