What follows is part of a dialog I am having with netcom support right now about the use of the Screen hyper-shell. I've been using it between home and work and it is awesome if you have never seen it. The man pages for it in ascii are ~rcain/pub/screen.man if you are on netcom and want to check out what it can do. There is someplace here I could put it for anon ftp if somebody could tell me the name of that drirectory from a netcom shell. The dialog starts as a discussion of the problem I have with the two or three minute inactivity timeout on the San Jose modems and is mostly about the low impact I see it having on resource usage. If you know all about Screen or aren't really interested in a bunch of justification, go forward about 100 lines to get to the part that discusses crypto. Peace, Bob
Netcom Support sez:
Robert Cain writes:
[some stuff deleted]
First the short duration of your modem timeout pushes the envelope of the ridiculous. I'm not sure what it is but when a brief conversation or call of nature causes it to disappear *IT IS TOO DAMNED SHORT*.
I'm sorry you have a problem with our policy, but we have no intent to change it in the future. We'll take your suggestions under consideration, but as I said we have no plans to modify it at this time.
You certainly sound intransigent. What would the implications of doubling it be for example? You could at least try it for a while and see if it has the effect of increasing the load on modem banks signifigantly. What is the currently programmed inactivity interval anyway? I lost it again in the middle of this damned note because I got a phone call. Damn I hate it when that happens. At lest this time there was a "vi -r" message in my mailbox after logging on.
I have a solution to this that I am using on our sun network at work. It is a package called "screen" that has wonderful features like multiple windows (all stacked one atop the other) that are easy to create and switch between if you want several contexts available at once. The most exciting feature is that if I wish to or if my line goes down, I can reconnect to it at the next login and pick up as if nothing had happened. This would be a wonderful feature at netcom too. I know that your no nohup hacks prevent us from having processes that persist when we log off (OR ARE FORCED OFF) but if you changed that specifically for the screen processes and it's descendants to instead reduce them to the lowest possible priority until a reconnect then all this hassle would go away and netcom could offer a very neat feature. IBM mainframes have had disconnect/reconnect forever and I've never understood the lack of it on Unix. Here it is! It is a very friendly and powerful capability. Users would love it and the cost to netcom would be entries in process tables and swap space for the processes. You seem to have more than enough of those kinds of resources now. Please consider it.
The use of "Screen" is not supported on Netcom because of its drain on system resources. It violates our policy against running detached backround processes. This is also a policy we have no plans to modify at this time.
Hmmm, I'm not sure you read me. What I am suggesting would not violate the intent of your policy WRT detached background processes. Let me try and persuade you.
If whatever you use to kill processes upon detachment, logout or forced by timeout, could instead merely lower their priority to the minimum then, as I said, they would not load the system's cycle capacity, merely occupy some process specific tables and some swap space. I am pretty sure that in one of the netcom newsgroups (to which I am posting a copy of this) we hassled this out and it was determined what the cost in real memory was for a process's tables that was totally swapped out. It was truly insignifigant in proportion to the size of real memory that is on the systems. There is little drain on system resources if you do this unless the number of processes becomes absurdly high.
Yes, there is a cost for swap space. Is it possible to set up your unix to use more than one swap area? If so then it could be arranged that a user's pages were swapped into storage he is paying for (possibly after he/she had exceeded some limit in the system swap area) and then this would become a revenue generator for netcom rather than a drain on resources. If that is not a thing you know how to do then you could simply establish a daemon that checks the number of processes (or the total size) and warns the user when he is in violation of the limit. That limit should be based on a determination of the real cost in process tables and swap space rather than just set arbitrarily. I don't see how my request does much more than offer serial line users <!!the same advantage that lucky telnet or rlogin users enjoy!!>. They can and do stay logged in indefinitely and in effect have various processes running all the time without concern about an inactivity timeout.
Arguing against having a bunch of virtual windows makes no sense because you can effect that if you know emacs reasonably well anyway. Screen is just an easier way that doesn't require one to learn emacs. As a hypershell, Screen has *many* powerful features for power users. For fairly naive users only a fairly few keystrokes need be remembered to use it's most useful features. In combination with the menu program you offer it would be very powerful across a slow line.
One of Screen's features is a rather elaborate filtering mechanism whereby all incoming keystrokes and outgoing screen data can be filtered by user programs. I would like to use this to add encryption for my phone line. It would be straightforward to encrypt my outgoing and incoming data here at my PC that is acting as a terminal since I think my terminal emulator has similar filter hooks so the same programs that I used on the netcom end or my work end would function on this end as well if I explicitly wrote them to be that way. Given that, I would make Screen effectively my login shell, have it negotiate (via the filters) a secure link with my terminal emulator here at home and then go through another password process before invoking my startup shell. Viola I no longer have to worry about someone grabbing my real password nor can I be snooped or spoofed between my system and a system at netcom. This has *HUGE* advantages to users and I will use a cypher (IDEA) in a mode that is *very* fast so that the system load that would be introduced by the crypdec filters would not be all that great. I have all the necessasary C libraries of long integer math routines and hard crypto functions as well as the theoretical knowledge of crypto needed to code what's left to write such a filter.
Hell, Screen's capability would *greatly* enhance Netcom's account attractiveness and good crypto could be used as a big selling point in attracting commercial accounts where you make substantial profit per account. In fact when I get this to work I wouldn't be surprised if users demand it. :-)
I have the man pages for Screen in my ~rcain/pub directory if anybody at netcom wants to check out Screen's capabilities. I could also make them temorarily available for incoming anon ftp if requested.
Now, while all this is true in theory, in all honesty I am too deeply involved in other things (like a day job) to actually do the implementation I speak of but I *do* have all the tools if anybody else wants to take a shot at writing the filters. Since screen runs across rlogin just fine, if this were done I could rlogin to any other machine on the net and have a secure session across the net. I think it could also be made to be secure across "talk" or "irc" sessions and even email between machines. It could also be used as the front end to any text based telnet port too. So if you want to be able to dial in securely at least and communicate with a system that is secure, and across systems that are secure badly enough to put the time into it (or pay me enough to quit my day job :-), here is a chance to maybe make some history. I think this is the right way to get a start on global network security. Screen offers such a rich environment for single windowed connections already that it is a natural starting point given that it's author has thought ahead to the kinds of filters we need. It also could care less what shell you run and it is transparent to the applications running below it (from the experience I have had to date) It is a work of art to begin with IMHO and with this crypdec capability there would hardly be a reason not to use it since if you don't know it and don't want to learn, you won't know Screen is there until you invoke it's commands with the ctrl-A key (which can be changed to anything else as an escape if you use applications that are fond of ctrl-A.) Peace and hoping, Bob -- Bob Cain rcain@netcom.com 408-354-8021 "I used to be different. But now I'm the same." --------------PGP 1.0 or 2.0 public key available on request.------------------ --