Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!cornell!batcomputer!rpi!rpi.edu!deven From: deven@rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: DNet multiplexing ( was Re: uw ) Message-ID: Date: 1 Jun 89 08:18:25 GMT References: <50125@tut.cis.ohio-state.edu> <363@xdos.UUCP> <9993@watcgl.waterloo.edu> Sender: usenet@rpi.edu Organization: RPI Public Access Workstation Lab, Troy NY Lines: 68 In-reply-to: bmacintyre@watcgl.waterloo.edu's message of 31 May 89 16:52:29 GMT In article <9993@watcgl.waterloo.edu> bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) writes: > A question for you. Sure thing. > I've tried to do this, and it does work, but ... but, but, but... > - is there any way to give one channel a higher priority than another, > so you could have your terminal not slow down noticably when you do > a file transfer? The speed you get is intollerable with a transfer > going, since the transfer will usually have multiple packets sent out > before any given packet of the terminal. The terminal *does* have a higher priority. It's the transmission window that causes the delay. The speed is less intolerable than waiting for the entire transfer to finish. (which you can do with dnet, too... :-) If you need visual reinforcement of a typed character before you will type the next, then it would be intolerable. I have little trouble, as I tend to simply type away and only look at the screen occasionally... > - the other thing I would love would be flow control on the LOCAL END! > I don't use DNET anymore as just a terminal because ctrl-S and ctrl-Q > do not stop/start the data until a couple of screen after you press > them, in some cases. No, C-s and C-q get passed through in the data stream. I *want* that, especially for using Emacs. (incremental-search and quote-character are important functions) For local flow control, I normally use the menu -- either press the right mouse button, or (more often) just press Right Amiga-Right Alt, which locks the layers and freezes the screen. (while displaying the menu bar) True, then you must hold it down to KEEP it stopped, but you get used to it. More useful, the transfer continues, so you can read, while the next page is transferred... In an FTerm, DNet will buffer an indefinite amount. (I suspect limited only by available memory, probably dynamically allocated messasges. At least, that's how *I* would do it.) If there is a lot of output, you must have quick timing to avoid losing output, because it's already in memory, just being dumped to the window. Moreover, the flow control is INSTANT. > These two things together would increase the utility of DNET by an order > of magnitude or more! When I get around to doing my own DNet-type program, you may be pleasantly surprised. :-) > Of course, I still think it's a great program. I use it for all my > file transfers now, just because of it's ease of use. Indeed. > >Ah, well... I can run it, so I'm happy. :-) > Me too! I have zero problems starting it. Of course, I use a dialup > phone line. That helps. Deven -- shadow@[128.113.10.2] Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet Troy, NY 12180-2306 <> "Simple things should be simple and complex things should be possible." - A.K.