SQL Server Magazine

If I could, I would make sure every desktop computer on Earth had its own modem and analog phone line. I am so used to being able to remotely access Windows NT domains with Remote Access Server (RAS), connect to the Internet with Point-to-Point Protocol (PPP), dial in to CompuServe, and fax from my word processor that the thought of being disconnected from the phone system makes my skin crawl. But every firm can't afford or justify having a modem and phone line on every desktop. To those unfortunate souls who don't have their own modem, I offer a simple solution: SpartaCom Asynchronous Port Sharing (SAPS).

SAPS lets clients share one or more modems connected to their server. A client system can access the server-side modem as if it were a local modem--SAPS lets the local client system see the modem as a direct-connect device. For example, you can set up NT or Windows 95 to autodetect and autoconfigure a modem connected via SAPS. This tight level of integration is, in my mind, one of the best aspects of SAPS. Installing SAPS is just like giving yourself extra serial ports to play with.

SAPS on Our Server
To gain a better appreciation for what SAPS can do, I brought it into the Windows NT Magazine Lab for a test drive. The first thing I had to decide was what kind of system to use as the modem server. SAPS lets you use NT (Intel, Alpha, or MIPS), Win95, or Windows 3.1x systems as modem servers. I used a generic 200MHz Intel system running NT Server 4.0. I also chose to try SAPS with a variety of modems, including a U.S. Robotics V.Everything modem, Zoom V.34 modem, Zoom K56Flex modem, and Motorola ModemSURFR K56Plus modem.

I used both NT and Win95 systems as the client systems in my tests. SAPS also includes client software for Windows 3.1x and DOS; however, I chose to ignore those operating environments (I've had my fill of both, thank you very much). I interconnected the client systems with the server via a 10Mbps Ethernet network.

Installation of the SAPS server component is straightforward. In fact, I found the most difficult aspect of the installation to be pounding in the too-long serial number (23 characters) and matching key (8 characters). After installing the software, you use the SAPS Server Manager, shown in Screen 1, to configure the ports you want to share and determine when you want sharing activated. The sharing software component runs as an NT service, so I elected to start it when NT starts.

To declare a shared port, you create a logical name, which the client will use to attach to the server, and then associate one or more ports with it. By assigning multiple ports to a single name, you create a pool of ports. A client system can then connect to the pool and automatically attach to any available port. Obviously, if you take the pool approach, you want to make sure the modems or other devices attached to all the ports in the pool are identical--or at least interchangeable. Once you define your ports and start the SAPS service (via the SAPS Server Manager), you're ready to tackle the client side of the equation.

SAPS on Our Clients
Installation of the SAPS client is simple, but yes, client-side installation also requires that you enter a 23-character serial number and an 8-character key. I suggest that SpartaCom find a better way to handle licensing. If you install a simple, five-client SAPS network, you must key in 186 characters (31 for the server and 155 for the clients). I'm particularly sensitive to this point because I had some technical problems and had to reenter licensing information multiple times.

As part of the client-side installation, SAPS prompts you to create a logical COM port. You can choose any unassigned COM port you want, and it doesn't have to be a physical port. Thus, if you have a full client system with four serial ports, you can tell SAPS to use COM5, COM6, and so forth. You can create as many SAPS ports on the client as you want. I recommend creating a unique SAPS port for each type of modem or device you will want to connect to.

After defining the name of the port, you define the SAPS server associated with the port, as Screen 2 shows. This server definition is another area of SAPS that can stand a little improvement, because it forces you to manually enter the server name and resource name of the SAPS server. The program does not provide a browse function to help the client discover SAPS servers and their associated resources. And the SAPS client does not verify the information you enter; you don't find out whether you made a mistake until the first time you connect.

Once you have installed the client software, you can treat your SAPS port like any other port. I used RAS for the bulk of my testing, which meant I had to first use the Modem applet in the Control Panel to define the modem connection for that port. Defining the SAPS port is as simple as defining a direct-attached or PC Card modem. You can let NT or Win95 automatically detect the modem type over the SAPS port, or you can manually configure the modem type and corresponding SAPS port. I found no flaws in the way SAPS integrates with the NT or Win95 port structure.

Despite my gripes about the long serial number and the requirement that you manually define the server connection, I found the client-side installation to be relatively painless. SAPS worked great on both NT and Win95 clients when I installed it with the correct licensing and server information.

   Prev. page   [1] 2     next page