SAPS

SpartaCom delivers modem access to all desktops

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.

Up and Linked
Once I had the modem defined, I only had to configure Dial-Up Networking (DUN) to use the correct modem, and I was off and running. Well, sort of. I used SAPS to dial in to the Windows NT Magazine domain, the Windows NT Magazine Lab domain, and my Internet Service Provider (ISP). Two of the three connections worked fine. I had no problem with the Lab domain connection or my Internet account, but I couldn't maintain a connection to the Windows NT Magazine domain. The server hung up on the modem after a few seconds of connectivity.

I thought I might have a protocol-related problem. But SAPS can transport any protocol, because it fits into the network at a level where it operates independently of the LAN protocol. Technical support suggested I had a licensing problem. They thought the Windows NT Magazine domain had a SAPS server with the same licensing information. Yes, that's why I entered the SAPS licensing information multiple times­I tried various combinations of SpartaCom license keys.

All of this typing was to no avail. I never resolved the problem of dialing in to the Windows NT Magazine domain. SpartaCom's technical support was willing to go to any length to resolve the problem, but when I needed to run a network monitor to see what was going on, I realized I didn't have the time to invest to reach a solution. Don't let this experience deter you, though. I would have resolved the problem had I continued working on it. And remember that my other two test connections worked fine. The only word of caution I can give you is to try SAPS before you buy it (SpartaCom has trial versions available on its Web site).

Although I gave up on dialing in to the Windows NT Magazine domain, I continued to test SAPS by dialing in to the Windows NT Magazine Lab domain and the Internet using all the modems at my disposal. In all cases, SAPS provided connections with the same reliability and speed I got when I used the modems in a direct-connect environment.

SAPS for You?
SAPS is not a general-purpose solution for all your remote connectivity needs. SAPS does not let multiple clients share the same modem concurrently. SAPS is not a router, nor is it a proxy server.

However, SAPS does let you share a limited number of modems or high-speed connections (e.g., ISDN, X2, K56Flex) among a set of desktops. SAPS also works well with desktop fax solutions: You can configure the clients to access a fax modem via a SAPS port. And SAPS is an excellent solution if your desktop users need to occasionally dial in to a bulletin board system (BBS) or the Internet.

When I was reviewing SAPS, I was also testing proxy server products and I found another use for SAPS that is not immediately obvious. When you are using a proxy server, your client systems don't have real IP addresses on the Internet. Unfortunately, many software programs demand a real IP address to function properly--realtime audio/video conferencing programs (e.g., CUSeeMe and IPhone) are an obvious example. Because of the IP address problem, I found that SAPS makes an excellent complement to a proxy server. For example, when I am accessing generic Web sites and email from my clients, I can use the proxy server link. But when I want to use conferencing software, I can use SAPS to make a direct connection between my system and the Internet. SAPS provides a neat solution to a difficult problem.

I certainly regard SAPS as a good choice for port sharing in the NT environment. Once I worked through the minor licensing and configuration issues, SAPS gave me rock-solid performance. You can't help but like a product that does what it promises and does it well. SAPS clearly falls into that category.