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.) |
