Our focus has always been local area networks. Recently, however, we've taken over AREV support for a company that has an office in California (where AREV resides on Novell 4.1) and an office Maryland that connects over a WAN to access AREV. They are running the NLM v1.5 as well.

Now we are being asked to suggest ways to improve speed and enable printing for the WAN users. Since I don't fully understand WAN connectivity and all that it entails, would any of you experts kindly give me a primer on the subject and then offer some general tips on how to accomodate these requests?

Thank you very much,

[email protected]

SRP Computer Solutions

Hi Don,

ARev on WANs… Big subject but let's see what we can do.

Think about it as if you had a customer that wanted the ARev on all the local machines and only the data stored on the network. This will help a bit.

Each location (LAN) should have a copy of ARev on a server and only the data and dictionaries are centralized at 1 site. This means that each and every site will load to the client workstations from the local LAN and not across the WAN. This way, you provide faster login times.

Dependant upon your application, this can mean a bit of redesign due to having multiple system files and copies of the windows, messages, popups, etc.. at each site. You will then need to look at a method for deploying updates across the multiple copies.

One trick is to make sure that each sites copy has a different name for all volume media maps. This way, when an update occures, you can attach each and every locations files and, using some sort of file naming schema (PHILLYREVBOOT, NYREVBOOT or what not and calling the Q-File pointers – PHILLYVERBS, NYVERBS, etc..), you can then roll the changes into each locations files.

As for WAN printing, there are no major tricks to this. Right now, in a multi-server LAN with more than 1 print server, you have to specify which one to print to. Same principle for a WAN.

Simply hand the print job off to the network and let it do the job. If performance is bad, you may need to have a localized (on the local LAN segment of the WAN) print-q setup where the print jobs are spooled to. Then let that print-q handle the actual sending of the job to the remote printer. This way, ARev isn't waiting for a remote printer or print-q to respond. The local print-q responds and then it deals with the remote printer but, this is basic LAN/WAN optimization techniques and not database system design considerations. All you need do is make sure you can have the database send printer output to where it needs to go and, if you are familiar with their network and can have it print to LAN printers then, having it print to WAN printers is no different from your stand point.

Hope this helps,

Mark Martin

Don,

The bandwidth of the connection between the two operations is often a key limiting factor when considering to run AREV on a WAN. If you combine multiple remote users and other non-AREV WAN traffic, your AREV application performance can become unbearably slow. Considering the distance between the two operations, the cost of a high bandwidth connection (T1 or better) would be exorbitant.

I was faced with a similar senario several years ago when I wanted to connect our Maryland headquarters to our Nevada facility. The solution that has worked great for us was Citrix WinFrame, an application server product. In addition to my 40 local users, I have 10 remote users simultaneously connected to our AREV Apps over a low bandwidth WAN connection with great performance. Another benefit is that no modifications to the AREV application are necessary.

Bob Cloney

Elite Spice, Inc.

[email protected]

Mark and Bob,

Thanks for your responses. Mark's technical brief was very helpful and Bob's suggestion of Citrix gave me another vote for a direction I am considering already.

If anybody else still has any useful stories please post.

Much appreciated,

[email protected]

SRP Computer Solutions

View this thread on the forum...