bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) (05/31/89)
In article <DEVEN.89May31080955@daniel.rpi.edu> deven@rpi.edu (Deven Corzine) writes: >DNet also supports *reliable* transmission of *binary* files (or full >directory trees, even) at a high throughput (~2200 baud on a 2400 baud >modem, vs. ~600 baud throughput for Kermit over the same modem) AT THE >SAME TIME AS MULTIPLEXING TERMINAL WINDOW STREAMS. You can read news >and download files simultaneously. True, the juxtaposition will slow >both your reading and the file transfer, but you spend a lot more time >reading than the transfer (of the text to be read) takes, and the >remaining bandwidth of the modem is used for the file transfer in >progress. This feature alone can be worth its weight in gold. No >need to start a transfer and go find lunch... A question for you. I've tried to do this, and it does work, 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 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. These two things together would increase the utility of DNET by an order of magnitude or more! 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. >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. -- = Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} // = = now appearing at the Computer Graphics Lab, U of Waterloo! \X/ = = "There's nothing the matter with BR that a shot gun blast wouldn't fix" cge = = "It's not my fault, fatboy!" - Felder, pilot of TL Student Driver On Board =
kent@swrinde.nde.swri.edu (Kent D. Polk) (06/01/89)
In article <9993@watcgl.waterloo.edu> bmacintyre@watcgl.waterloo.edu (Blair MacIntyre) writes: [..] > 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. [...] >= Blair MacIntyre, bmacintyre@watcgl.{waterloo.edu, UWaterloo.ca} // = Try holding down the RIGHT Mousebutton. Sometimes it takes two hits, but always works for me - even at 9600 baud. (Ctrl-S/Ctrl-Q never work for me.) ======================================================= Kent Polk - Southwest Research Institute {cs.utexas.edu, gatech!petro sun!texsun}!swrinde!kent kent@swrinde.nde.swri.edu ------------------------------------------------------- "Anything worth doing is worth overdoing" =======================================================
deven@rpi.edu (Deven Corzine) (06/01/89)
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] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.