The A-Shell/Windows Telnet Service Daemon (ATS or ATSD) provides a way to run A-Shell/Windows via ordinary terminals or terminal emulators over Telnet connections. In other words it allows you to serve A-Shell/Windows connections on an NT or W2K or XP server in much the same way you would with A-Shell/UNIX or A-Shell/LINUX on UNIX/LINUX servers. Yet another way to look at it is as a text-based alternative to Windows Terminal Server and Citrix/Metaframe.
Why would anyone want to do such a thing? Here are a few possible scenarios which might offer justification:
| • | You have a standard peer-to-peer LAN installation of A-Shell/Windows which you are happy with, but want to add one or more remote connections. ATS does not eliminate the need to establish a network connection, but once that is in place (perhaps via dial-up RAS, or a DSL Internet connection) ATS would permit excellent performance over a 28K link. (In contrast, if you tried to extend your peer-to-peer network over a WAN connection, even a fast one, you will find the performance is very disappointing.) |
| • | You have an enterprise network and need to allow a wide variety of far-flung workstations access to your a-Shell/Windows application, but security and other logistical considerations militate against allowing peer-to-peer access to the Windows server throughout your enterprise. With ATS, you only need to open a single port (which you can select). And although that port accepts Telnet connections, ATS there is no access to the operating system except through A-Shell. |
| • | Compared to Windows Terminal Server, ATS has a much smaller "footprint" (demands less CPU and memory resources) so you can support a lot more client connections before you need to start getting into exotic server configurations. ATS is also much cheaper to license, especially in comparison to Metaframe. |
| • | Even in a small LAN, using ATS connections exclusively (i.e. eliminating all the peer-to-peer connections) can result in an environment that is easier to maintain, more secure, more reliable, and may even offer better performance. It’s easier to maintain because it eliminates the need to configure disk sharing and even user logins at the OS level. The lack of shared disks also makes it more secure. The improved reliability and performance come from eliminating the complexity and overhead of the peer-to-peer disk sharing protocols. With the ATS model, all the users are running on the one server, thus eliminating nearly all of the data and protocol traffic between machines (except for the characters involved in keyboard input and screen display.) |
ATS Components
Most of the code supporting ATS is embedded in A-Shell; it requires A-Shell build 787 or higher. The only essential external module is ATSD.EXE, which must be launched on the server machine. ATSD.EXE just waits for clients to initiate Telnet connections, and as they are accepted, it spins off a new A-Shell session for each client.
Although launching ATSD.EXE as an application on the server is easy enough, it suffers from the fact that you have to be logged in to do it (even via the Startup folder), and many installations prefer to leave the server machine logged out (presumably to discourage unauthorized use of the console.) In order to allow ATSD to be launched automatically even before a login is established on the server console, we provide a wrapper module, ATSDSRV.EXE, which runs as a standard system service and can be maintained from the Windows Services Applet. ATSDSRV.EXE is configured via a simple INI file, ATSDSRV.INI, which primarily just tells it how to launch ATSD.
To clarify the terminology, "ATS" (A-Shell Telnet Service) refers to the capability or service in general or as a whole. ATS encompasses code inside ASHW32.EXE as well as the external modules ATSD.EXE and ATSDSRV.EXE. "ATSD" refers to the executable program ATSD.EXE that accepts the Telnet connections. The "D" suffix was meant to stand for "daemon", which is what background service programs (such as telnetd, the Telnet daemon) are called in the UNIX world (even though ATSD.EXE provides the un-daemon-like option of a standard foreground user interface.) ATSD is sometimes used interchangeably with ATS. "ATSDSRV" refers to the program module ATSDSRV.EXE which provides the Services Applet interface.
The "Services Applet" is a utility built in to the Windows NT, and W2K+ operating systems which keeps track of all the available services and allows you to control which services are started automatically, as well as to manually stop or start a service. Under NT, you will find it in the Control Panel. Under later versions of Windows, you will find it in the Administrative Tools folder, which is itself in the Control Panel. Some people refer to this applet as the Service Manager.
