Off-site users who connect infrequently to distributed networks present unique challenges
Michael Nadeau
One of the most difficult challenges of implementing distributed networks is dealing with remote clients. These clients might be workers in branch offices, people working at home, or mobile personnel using portable computers. What makes them different from other nodes on the network is that they are connected only intermittently.
This presents several problems. First, most remote links are made through a dial-in line via a modem. Phone connections are expensive, so it is critical to know how often a remote user connects and the type of data transmitted.
Second, remote or mobile employees, away from the watchful eyes of the network manager, are notorious for using unauthorized software. Controls are
needed not just to ensure that the software at the remote client is legitimate, but to ensure that authorized software can be updated centrally.
Most significant, for both the business and the remote user, the database is never up-to-date. There is always some information at a disconnected site waiting to be reconciled with the rest of the corporate data. When it's finally reconciled, it must be both accurate and available in a timely manner.
Making the Connection
Remote-access software, such as Symantec's Norton PC/Anywhere and Microcom's Carbon Copy, provide access only to a local node on the network, via a slave/host relationship. They transmit the screen image of that local node to the remote client and allow for file transfer, but they do not make the remote client an actual node on the network.
Instead, off-site users commonly make the network connection by dialing in to a remote-access server using a high-speed modem or sometimes a dedicated line. A remote-access server acts as
a bridge that provides remote clients a two-way connection to the network--usually via Ethernet or token ring. To the network, the client looks like anyone else on the network. The user sees no difference, either, except for slower performance caused by the smaller bandwidth of the remote connection. Most remote-access servers allow for up to eight simultaneous connections. Common features include protocol independence, built-in security, and management utilities.
Remote LAN Node from Digital Communications Associates (Alpharetta, GA) emulates an Ethernet or token-ring NIC (network interface card) in software on the remote client. The RLN product can handle an unlimited number of dial-in ports on a single phone number. RLN doesn't care what kind of network protocol you're running. On the client side, only DOS and Windows are supported, although the company plans to support OS/2 and the Mac as well.
The trusted-domain feature of RLN lets a network administrator set up access to the RLN server,
so that no matter where the user is calling from, he or she logs on using the same security procedures. For example, if a branch manager travels to another company site and logs on to the local network, RLN automatically knows to authorize that person according to the security protocols of that local network.
Shiva Corp. (Burlington, MA) popularized the concept of remote servers and network modems, which effectively function as single-port access servers. Its LANRover/Plus remote servers provide four to eight ports and come with the Shiva Net Manager, which allows remote or local management of the server--an important feature if servers are installed at multiple sites. LANRover/Plus supports the Novell NetWare Bindary user security ID lists. The client part, Shiva Remote, supports MS-DOS, Windows, and Unix.
LANexpress Server from Microcom (Norwood, MA) comes with both remote-node and remote-control software. It is Windows-based and gives you a grid of simple icons representing key functions. Yo
u also get the expressWatch management software for monitoring and configuring the system.
The MicroAnnex NCS from Xylogics (Burlington, MA) provides only two ports, but at $995 it is considerably less expensive than other remote-access servers, which can cost several thousand dollars. It, too, supports NetWare Bindary security, and it comes with Xylogics' Fastlink remote-node software. Other vendors of remote-access servers include Cayman Systems (Woburn, MA), Telebit (Chelmsford, MA), 3Com (Santa Clara, CA), and Cisco (Menlo Park, CA).
The above remote-access servers have hardware and software components. Citrix Systems (Coral Springs, FL) sells applications-server software, WinView for Networks, that provides remote Windows access. WinView offers server-based processing for Windows and MS-DOS applications, sending the results only to client workstations. A 486 WinView server supports 10 Windows or 20 MS-DOS users simultaneously accessing applications running on the server. Citrix's Intelligen
t Console Architecture minimizes traffic by sending only Windows graphics commands and mouse and screen updates over the dial-in connection. Except for file transfers, Citrix claims near-network performance for remote nodes. WinView also supports remote-access servers from Novell, Digital Communications Associates, Shiva, and 3Com.
Performance bottlenecks over dial-in connections are a fact of life for remote users, but you can minimize them. Using a fast modem--28.8 Kbps or higher--with the latest compression algorithms is the easiest way to boost transmission speed. Ultimately, though, the greatest gains are achieved by the distributed applications themselves. "The trend is to design applications that are bandwidth-sensitive," says Mark Monday, the RLN product manager.
Applications need to be aware of when there is a slow connection to the network and then act to minimize the traffic over that connection. This most likely means keeping more of the data at the server and running more of the app
lication at the client.
Also, performance is only as good as the slowest link. This point is especially critical with notebook PCs. A high-speed modem won't do much good if it's attached to a slow serial port on a notebook. You want to equip mobile clients with notebooks that have high-speed serial ports and modems that can take advantage of them.
Managing Remote Clients
The tasks that give network managers fits at the local site are doubly frustrating when remote users are involved. Software updates, applications auditing, and usage monitoring require different tactics for faraway nodes .
RemoteWare from Xcelle-Net (Atlanta, GA) is a suite of client/server software tools for creating and managing applications systems that automate information flow between remote/mobile users and central information systems. Besides a server component, the RemoteWare line includes the Forms, Report, Document, Desktop, and Mail modules. Using RemoteWare, a manager can update a form or provide new deskto
p options to all appropriate remote personnel automatically. Similarly, the remote client can send his or her updates to the server as a mail message, and the RemoteWare server software routes those changes to the appropriate locations. For example, an expense report might go to the accounting department or orders to the warehouse.
You also want to know who does or does not call in during certain periods of time. In a sales application, it is particularly important to monitor reports from the field. RemoteWare and the management components of many remote-access servers keep a log of who calls in and when.
It is also difficult to monitor remote users for authorized software. As a manager, you don't want to support different software for each client or be responsible for pirated software used at a remote site. One way to minimize the problem is to tightly weave the remote applications to the local database, and this frequently happens with legacy applications.
But this method does little to
prevent remote clients from using unauthorized nonnetworked tools. RemoteWare provides the means to lock out anyone who attempts access with unauthorized software. One product, SEAM (Saber Enterprise Applications Manager) from Saber Software (Dallas, TX), specializes in this task. SEAM is a Windows/DOS software-metering tool that creates a TSR program that resides on the client system. This TSR monitors the software being used according to predetermined rules. SEAM also lets you share licensed software.
Keeping Up to Date
In a large organization, there could be hundreds of information transfers between remote clients and the local database occurring at any time. It is impossible to make all the information generated at either end available to everyone immediately. At best, you can make it available in real time when the remote client connects, but this is the most expensive route. Some organizations, especially those that deal with frequent financial transactions, have no choice. "We want to be ext
remely confident that we don't have cross-tier and cross-time-line discrepancies," says Jeff Devlin, a database manager for The Equitable Companies (New York City).
To perform a real-time update requires the use of intelligent software at both ends of the transaction. This software analyzes the data, routes it to the appropriate storage location, and updates the database. It also checks to see who else is accessing the same data at that time and acts according to a predetermined set of rules that governs who has priority when multiple clients access the same data simultaneously. For example, client A logged in first, so the software notifies client B that the data is unavailable. When client A is finished, the software sends an all-clear message to client B.
Updating in real time also demands that data be treated discretely, rather than as files. That is, if client A places an order for 10 widgets, only the changes to the database are transferred. Sending that data as a file would require gettin
g an entire subset of the database; another step would be needed to analyze the subset and extract the changed information before making the updates.
DataSync from Datawatch Corp. (Research Triangle Park, NC) is a database-synchronization middleware tool that helps you build the necessary intelligence into your software. As you create a DataSync application, the product lets you define data subsets that will be transferred between the remote clients and the local site. You also set up "synch" rules, which tell the application the specific rows and columns in the database to choose from. These rules can be customized.
DataSync relies on ODBC (Open Database Connectivity). ODBC, developed by Microsoft, provides a common interface for Windows applications to access networked databases. Most relevant Windows applications now provide ODBC drivers, including contact managers like Symantec's ACT and database software like Microsoft Access. This permits more flexibility in terms of the applications remot
e clients use as front ends. For example, if client A wants to use ACT and client B wants to use Lotus Approach, both can be accommodated, assuming that the applications are ODBC-capable. You can also build the applications using Visual Basic or C++. DataSync requires Windows on the client side, but it's platform-independent on the server side.
The more often you dial in, the higher your phone bill. For many businesses, however, frequent updates are not as critical. In these cases, the remote clients can log in once a day, upload their data (usually as a file), and receive their own updates and other messages. At the local site, those files are processed batch style--probably after hours--and the database is updated.
Cost isn't the only reason to process database updates in batches. "Some legacy applications are not meant for remote access," says Mark Freitas, who's vice president of Microcom. Rather than rewrite the application, it is easier to gather the updates and process them independently
before changing the data on the legacy system.
The very nature of distributed computing encourages the use of remote nodes. While remote clients complicate the design of distributed networks, ensuring that all users have access to the information they need more than makes up for the trouble.
Illustration: XcelleNet's RemoteWare lets you build forms-based applications using simple icons for access. Updates to both the forms and icons can be sent automatically from a central location.
Illustration: How DataSync Works
DataWatch's DataSync relies on ODBC applications to maintain data integrity. Users permanently connected via the desktop access the server to directly modify the data, sending changes only to the server database. Remote users receive via modem a subset of the data, which is then synchronized with the local database.
Michael Nadeau is a BYTE senior editor. You can contact him on the Internet or BIX as
miken
@bix.com
.
Remote Connections
