james@dlss2.UUCP (James Cummings) (08/24/90)
In article <1990Aug23.051212.24281@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >I gave up looking about 35% of the way through the code; do you anywhere >protect against killing a user during downloads, when the terminal would >normally be idle for long (up to several hours with a slow modem and big >files) periods of time? You're absolutely right!...although I have not tested it in this particular manner, I would think that during a download you WILL accumulate IDLE time that the program will notice. Because of the nature of "cheating" users who use a looping shell program to "fake" a screen activity, I choose to use stat and the utmp log. This would mean that "real" keyboard activity would need to occur to keep idle time from building up. Of course, if it's your machine and you have the control, simply add yourself to the immune file. This makes a point though and if I can find a reasonable way to incorporate a "safety switch for downloading", I'll add that as a patch or new version (you get the fame and glory for the idea). Generally most system administrators want to keep someone from jumping off the system or just getting up from the keyboard and walking off, leaving an active shell behind. Thanks again for the suggestion. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |Disclaimer: | James Cummings | | You can't blame me! | UUCP: | | I'm ignorant! | ..swblat!{texbell!texnet.. | |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| swgate!dlss1..}!dlss2!james | |Send flames to: | NET: | | sowc@devnull.com | jc@smunews | | | | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
bob@wyse.wyse.com (Bob McGowen x4312 dept208) (08/24/90)
In article <1990Aug23.143804.24954@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes: >In article <1990Aug23.051212.24281@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >> ... I'd be a little huffy about having my kermit >>session killed in mid-download because I hadn't sent a keystroke in a > >But, but, kermit (and all other error-correcting download protocols) send in ^^^ >keystrokes all the time! If my understanding of "sliding window" protocols is correct, it IS possible for a download to never (or seldom) have a response. The basic idea is that if an error has not occured, why spend the overhead to ack the packet. So a stream of packets flows until an error. If no problems, then no input, so line is idle and off we go in the middle of the transfer somewhere. (The above is my deduction, not a quote so please be gentle in setting me straight :-). Thanks.) Bob McGowan (standard disclaimer, these are my own ...) Product Support, Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com
new@ee.udel.edu (Darren New) (08/24/90)
It might be better to kill idle *programs* rather than idle *users*. Any forground process running csh, rn, vi, .... could be killed fairly harmlessly. Of course, the question of how to kill the csh which invoked the rn which invoked the vi that somebody walked away from is interesting. The best solution may be to patch the tty drivers to report how long there have been outstanding read() calls, rather than how long since something was typed. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
roy@cs.umn.edu (Roy M. Silvernail) (08/25/90)
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) writes: > In article <2868@wyse.wyse.com> bob@wyse.UUCP (Bob McGowen x4312 dept208) wri > >If my understanding of "sliding window" protocols is correct, it IS possible > >for a download to never (or seldom) have a response. The basic idea is that > >if an error has not occured, why spend the overhead to ack the packet. > > No, even with a "sliding window" protocol, acknoledgements are sent. > The main difference is that you don't wait for an ack to continue > transmission but wait if a specified number (window size) of acks > is missing. I think Bob is thinking of a streaming protocol, such as Zmodem. Zmodem will leave the return channel completely empty, unless an error is discovered by the receiving end. Streaming protocols are, of course, distinct from sliding-window protocols. Now, the question in my mind (and this really has nothing to do with the original thread :-) is... which type is SEAlink? I have used it on several systems, and had varying results. In some cases, it has behaved as a streamer (with no activity seen on the alternate-channel modem light), and sometimes it's acted like a sliding-window, if not downright packetized. -- Roy M. Silvernail | #include <stdio.h> | Does virtual now available at: | main(){ | reality need cybrspc!roy@cs.umn.edu | float x=1; | swap space? (cyberspace... be here!)| printf("Just my $%.2f.\n",x/50);} | -- me
woods@robohack.UUCP (Greg A. Woods) (08/26/90)
In article <TADGUY.90Aug23155542@abcfd21.larc.nasa.gov> tadguy@abcfd01.larc.nasa.gov (Tad Guy) writes: > In article <1990Aug23.143804.24954@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes: > > > ... I'd be a little huffy about having my kermit > > >session killed in mid-download because I hadn't sent a keystroke in a > > >while. > > > > But, but, kermit (and all other error-correcting download protocols) send in > > keystrokes all the time! > > Except that kermit uses /dev/tty, so on many UNIXes, the real tty line > appears idle, even though characters are going by all the time... So if your UNIX has this problem, complain to your vendor, and get it fixed. You shouldn't complain about a programme which uses one of the better ways of determining idle time. If you can't get your UNIX fixed, please try and discover a way in which idle time can be reliably determined instead of flaming about a perfectly fine programme (actually I've not compiled it yet, but I hope to try it very soon). -- Greg A. Woods woods@{robohack,gate,eci386,tmsoft,ontmoh}.UUCP +1 416 443-1734 [h] +1 416 595-5425 [w] VE3-TCP Toronto, Ontario; CANADA
xanthian@zorch.UUCP (08/27/90)
I gave up looking about 35% of the way through the code; do you anywhere protect against killing a user during downloads, when the terminal would normally be idle for long (up to several hours with a slow modem and big files) periods of time? I run my own downloads with a script that logs me off and hangs up the phone, then I go to bed. I'd be a little huffy about having my kermit session killed in mid-download because I hadn't sent a keystroke in a while. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
peltz@ux1.cso.uiuc.edu.UUCP (08/27/90)
In article <1990Aug23.051212.24281@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > ... I'd be a little huffy about having my kermit >session killed in mid-download because I hadn't sent a keystroke in a >while. But, but, kermit (and all other error-correcting download protocols) send in keystrokes all the time! -- Steve Peltz Internet: peltz@cerl.uiuc.edu PLATO/NovaNET: peltz/s/cerl
tadguy@abcfd20.larc.nasa.gov.UUCP (08/27/90)
In article <1990Aug23.143804.24954@ux1.cso.uiuc.edu> peltz@cerl.uiuc.edu (Steve Peltz) writes: > > ... I'd be a little huffy about having my kermit > >session killed in mid-download because I hadn't sent a keystroke in a > >while. > > But, but, kermit (and all other error-correcting download protocols) send in > keystrokes all the time! Except that kermit uses /dev/tty, so on many UNIXes, the real tty line appears idle, even though characters are going by all the time... ...tad
xanthian@zorch.UUCP (08/27/90)
[Sorry if you see this twice; I messed up the attribution on the first one, and only caught it and sent a replacement and a cancel several hours later.] tadguy@abcfd01.larc.nasa.gov (Tad Guy) writes: >peltz@cerl.uiuc.edu (Steve Peltz) writes: [xanthian (me!) wrote:] >> > ... I'd be a little huffy about having my kermit >> >session killed in mid-download because I hadn't sent a keystroke in a >> >while. >> >> But, but, kermit (and all other error-correcting download protocols) send in >> keystrokes all the time! > >Except that kermit uses /dev/tty, so on many UNIXes, the real tty line >appears idle, even though characters are going by all the time... [Thanks, Tad.] More pertinent, kermit was just an example. I've worked in user support on timeshare systems where everyone edited huge files online for 7.5 hours straight without a save (saves took a _long_ time), then all hit "s"ave essentially at once (to go home), the system got so loaded down that saves took over 0.5 hour, the users got automatically logged off for lack of keyboard input (the save locked the terminals keyboards, so they couldn't even sit their bouncing the backspace key to stay alive, or whatever), their files were _truncated_ at the point where the save died, and their entire day's work was lost (not to mention the nuisance of trying to get several large files restored on a system with crowded disks). The timeshare site's sysops thought this was perfectly acceptable behavior and wouldn't change it. The moral of the story is that an idle terminal is not a correct indication that the system is doing no useful work for the user. One must check for suspended or background tasks, a foreground task other than the shell, and probably several other precautions before deciding that a user is really idle. [Most safety checks that protect legitimate "idleness" will be fooled by a line dropped because some idiot buggy game hung up, too, so this is not a place for amateur hacks to be blindly applied, but that is a separate question.] A very pertinent example today might be a raytracing routine; run in foreground, it could sit for a day on a system as slow as my home machine, churning bits to some disk file, without a single keypress or character to the screen; nuking it on a remote login because I'm "idle" is a fairly unfriendly act. [Not that a site might not do that by policy to free up a line from a user to lazy to learn how to run a job disconnected from his/her sessiion; just another example.] The autologout blunders I saw in the mid 70's need not be repeated in the 90's, which is why I raised the question. I still don't know if the code that started this thread is in fact taking a careful look around before deciding to nuke the user's session, I'm just promoting the idea of taking that look first, in this and any other autologout routines. It is easy to do more harm than good with a naive approach to this complicated problem. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
p554mve@mpirbn.UUCP (08/27/90)
In article <2868@wyse.wyse.com> bob@wyse.UUCP (Bob McGowen x4312 dept208) writes: >If my understanding of "sliding window" protocols is correct, it IS possible >for a download to never (or seldom) have a response. The basic idea is that >if an error has not occured, why spend the overhead to ack the packet. So >a stream of packets flows until an error. If no problems, then no input, so >line is idle and off we go in the middle of the transfer somewhere. No, even with a "sliding window" protocol, acknoledgements are sent. The main difference is that you don't wait for an ack to continue transmission but wait if a specified number (window size) of acks is missing. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
xanthian@zorch.UUCP (08/27/90)
james@dlss2.UUCP (James Cummings) writes: >xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >>I gave up looking about 35% of the way through the code; do you anywhere >>protect against killing a user during downloads, when the terminal would >>normally be idle for long (up to several hours with a slow modem and big >>files) periods of time? > > You're absolutely right!...although I have not tested it in this >particular manner, I would think that during a download you WILL accumulate >IDLE time that the program will notice. Because of the nature of "cheating" >users who use a looping shell program to "fake" a screen activity, I choose >to use stat and the utmp log. This would mean that "real" keyboard activity >would need to occur to keep idle time from building up. Gee, I hate to criticize someone who's being so pleasant, but compelled as I am... Until you see something like this, it's hard to accept that software can display an "attitude", but here's the needed example. You _cannot_ stop me from keeping a session alive from my home dialup line if you make it a matter of hostility. I can and have written little idle loops that sit at the cursor and emit "space backspace" until I come back to my home computer and kill the idle loop, simply to defeat "hostileware". The user will always win, because there is always some user somewhere who is smarter than you, finds a way to beat the system, and then shares it with like minded friends for the glory of having "beaten that damn autologout nuisance". Given that trying to force autologout on a user who doesn't want it is a waste of time, what attitude will permit autologout to serve the system? That software that also serves the user! Give me a autologout that takes care of the times I _do_ want to have my session killed, and can't do it myself: 1) my modem died, and the line is burning up my account use limit for this time period, or money on a pay by the hour system (used to happen on The Well all the time before the hardware upgrade); 2) some buggy program hung the line, and I can't/don't know how to get in on another line and kill the session, so I can't log back on or continue with my work until you kill my session and free the line; 3) I fell asleep in front of my compter (happens all the time), and there's nothing running or backgrounded in my session of importance, and I don't want to anger the sysop by building up a huge idle line time account; please nuke me tender; 4) I have some long task to run that doesn't need watching, so I'm going out for a burger, fries and a look at the moonlight with a very dear friend, and I'd like the system to kill my session without my help when the task is done; 5) I typed "exit" and turned off my screen (leaving the modem on as usual) forgetting that I had a suspended "rn" session that was going to pop back up instead of my session ending. The point being, users frequently _want_ the benefits of autologout, and will use it as a valuable tool if it is indeed wielded for their benefit, but will do everything in their power to disable it if you decide to make a war with the users out of system management. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
jpn@genrad.com (John P. Nelson) (08/27/90)
>> ... I'd be a little huffy about having my kermit >>session killed in mid-download because I hadn't sent a keystroke in a >>while. > >But, but, kermit (and all other error-correcting download protocols) send in >keystrokes all the time! Not ZMODEM. ZMODEM only sends "response" characters at the beginning and end of a transfer, or when an error is detected. john nelson uucp: {decvax,mit-eddie}!genrad!jpn domain: jpn@genrad.com
wiml@milton.u.washington.edu (William Lewis) (08/28/90)
In article <L3VFo1w162w@cybrspc> cybrspc!roy@cs.umn.edu (Roy M. Silvernail) writes: >Now, the question in my mind (and this really has nothing to do with the >original thread :-) is... which type is SEAlink? I have used it on >several systems, and had varying results. In some cases, it has behaved >as a streamer (with no activity seen on the alternate-channel modem >light), and sometimes it's acted like a sliding-window, if not downright >packetized. Well, last I checked, SEAlink was a very lightly modified XMODEM (CRC) and sliding window. Basically, the ACK/NAK byte was expanded to a very small (3 or 5 byte) packet containing the last valid packet received. The window size defaulted to something on the order of 6 XMODEM packets. I have no idea why it wouldn't show activity on the return channel; maybe the modem light flickered too briefly for a packet only 5 bytes long? Or maybe the protocol has been updated since I looked at it, though I doubt it. [Note also that using SEA products is sometimes considered politically incorrect, after SEA sued PKWare ... though, SEAlink *is* a nice clean protocol .. and this doesn't belong in this group anyway.] -- wiml@blake.acs.washington.edu Seattle, Washington | No sig under (William Lewis) | 47 41' 15" N 122 42' 58" W |||||||| construction
roy@cs.umn.edu (Roy M. Silvernail) (08/28/90)
wiml@milton.u.washington.edu (William Lewis) writes: > [Note also that using SEA products is sometimes considered politically > incorrect, after SEA sued PKWare ... though, SEAlink *is* a nice clean > protocol .. and this doesn't belong in this group anyway.] Quite true, and the primary reason I don't use SEAlink unless it's vital. (I used to call a BBS in Anchorage that had SEAlink and Xmodem Checksum available only) In fact, I don't even have it installed in my current comm program. I just keep it in the floppy bins in case of emergency. I only mentioned it because of seeing the differing behaviour. -- Roy M. Silvernail |+| roy%cybrspc@cs.umn.edu |+| #define opinions ALL_MINE; main(){float x=1;x=x/50;printf("It's only $%.2f, but it's my $%.2f!\n",x,x);} "This is cyberspace." -- Peter Da Silva :--: "...and I like it here!" -- me