wpl@burdvax.UUCP (William P Loftus) (11/10/86)
Anyone have the same problem? I cd-ed into a directory using the menus of vt100, and startup kermit with * as the filename. After transfering the first file in the directory all the other files timed-out. -- William P Loftus UUCP: wpl@burdvax, sword@excalibur SDC R&D/Software Technology ARPA: PO Box 517 BITNET: Paoli, PA 19301 215-648-7222 (work) 215-646-8434 (home) 215-628-2067 (home, yet again) Disclaimer : I hereby deny it.
james@uw-atm.UUCP (James M Synge) (11/11/86)
In article <2838@burdvax.UUCP>, wpl@burdvax.UUCP (William P Loftus) writes: > I cd-ed into a directory using the menus of vt100, and startup kermit > with * as the filename. After transfering the first file in the directory > all the other files timed-out. Sounds like your remote host was NOT running a server, but instead was waiting to RECEIVE a single file. First start the remote host as a server, then you can send and get multiple files without difficulty. james. -- --------------------------------------------------------------------------- James M Synge, Department of Atmospheric Sciences, University of Washington VOX: 1 206 543 0308 (Work) 1 206 455 2025 (Home) UUCP: uw-beaver!geops!uw-atm!james ARPA: geops!uw-atm!james@beaver.cs.washington.edu
dss@cubsvax.UUCP (David Silver) (11/12/86)
In article <burdvax.2838> wpl@burdvax.UUCP (William P Loftus) writes: > > >Anyone have the same problem? > >I cd-ed into a directory using the menus of vt100, and startup kermit >with * as the filename. After transfering the first file in the directory >all the other files timed-out. > Yup. I found that I couldn't send multiple files by doing a kermit r on a remote machine and kermit send * on the vt100 kermit. The first file got transfered, the remote kermit went away, and the vt100 kermit sat there trying to send the rest of the files to noone. Any ideas? -- David Silver {philabs,rna}!cubsvax!dss cubsvax!dss@columbia
james@uw-atm.UUCP (James M Synge) (11/13/86)
In article <576@cubsvax.UUCP>, dss@cubsvax.UUCP (David Silver) writes: > I found that I couldn't send multiple files by doing a kermit r on > a remote machine and kermit send * on the vt100 kermit. The first file > got transfered, the remote kermit went away, and the vt100 kermit sat > there trying to send the rest of the files to noone. Any ideas? It went away because it had done what you asked: it had received a single file. Kermit had SERVERs added to the protocol to handle just this problem. They allow the remote host to handle multiple transactions with out "intervention" for every transaction. Thus you could send 3 files, receive 1, send 1 more, then quit, all this with only one command type to the server. Of course you would be typing the names of several files on the Amiga, but it cann't guess the files! james. -- --------------------------------------------------------------------------- James M Synge, Department of Atmospheric Sciences, University of Washington VOX: 1 206 543 0308 (Work) 1 206 455 2025 (Home) UUCP: uw-beaver!geops!uw-atm!james ARPA: geops!uw-atm!james@beaver.cs.washington.edu
wpl@burdvax.UUCP (William P Loftus) (11/14/86)
In article <576@cubsvax.UUCP>, dss@cubsvax.UUCP (David Silver) writes: > In article <burdvax.2838> wpl@burdvax.UUCP (William P Loftus) writes: > > > > > >Anyone have the same problem? > > > > Yup. I found that I couldn't send multiple files by doing a kermit r on Use kermit -x instead of kermit -r. Someone sent me the solution, but I delete the letter before I could thank them -- Thanks whoever you were. Bill -- William P Loftus UUCP: wpl@burdvax, sword@excalibur SDC R&D/Software Technology ARPA: PO Box 517 BITNET: Paoli, PA 19301 215-648-7222 (work) 215-646-8434 (home) 215-628-2067 (home, yet again) Disclaimer : I hereby deny it.
keithe@tekgvs.tek.com (Keith Ericson;6276042;50-383;LP=A;) (11/15/86)
In article <51@uw-atm.UUCP> james@uw-atm.UUCP (James M Synge) writes: >In article <576@cubsvax.UUCP>, dss@cubsvax.UUCP (David Silver) writes: >> I found that I couldn't send multiple files by doing a kermit r on >> a remote machine and kermit send * on the vt100 kermit. > >It went away because it had done what you asked: it had received a single file. >Kermit had SERVERs added to the protocol to handle just this problem. Um, er, ah... NO. The UNIX kermit we have on our VAX has the following identifying strings buried in the executable: C-Kermit, 4D(060) 18 Apr 86 C-Kermit functions, 4D(049) 4 Jun 86 C-Kermit Protocol Module 4C(030), 19 Mar 86 I have exercised this version with the VT-100 v2.2 Kermit on my Amiga and with IBM-PC MS-Kermit V2.29 26 May 86. For the first experiment I started the UNIX Kermit with the instruction kermit -r <cr> MS-Kermit will successfully transfer multiple files to the Unix Kermit whereas the VT-100 v2.2 Kermit will "hang" after (successfully) sending only the first file. VT-100 v2.2 TRIES to send the subsequent file but it never gets past the status line that says File: [filename] Pckt: S Pckt No: 0 Retrn: 5 Bytes: 0 Stat: TMOUT To regain control of the Amiga I had to terminate the host (Unix) login session at which time the local (Amiga) Kermit aborted and control was returned to me. The UNIX Kermit had terminated. I then ran the MS-Kermit and the VT-100 v2.2 Kermit into a UNIX Kermit that had the logging turned on. This time I started UNIX Kermit with just the command "kermit" which invokes the interactive mode. After requesting that the packets, debugging, session and transaction information be logged into files I gave Kermit the "receive" instruction. The transaction.log for the VT-100 v2.2 did not have any mention of an attempt to negotiate the transmission of a second file, in contrast to the transaction.log for the MS-Kermit transfer which showed that indeed the UNIX Kermit had been prompted to negotiate for and receive a second file. If anyone is trying to fix this I hope this helps. keith ericson at teklabs
thurlow@utcs.UUCP (11/17/86)
Kermit protocol when sending has the following packet types.
S == beginning of transmission packet.
F == file header packet.
D == data packet.
Z == end of file packet.
B == end of transmission packet.
A kermit upload looks like this:
Send an S packet. For each file, send an F packet, then as many D packets as
needed, and a Z packet. Once all the files are transfered, send a B packet.
the vt100 kermit upload looks like this:
For each file, send an S packet, an F packet, as many D packets as needed,
a Z packet, and a B packet. Note that an S and B packet is being sent for
each file rather than just at the beginning and end of the transmission.
vt100's method doesn't work since it sends an B packet after each file and
regular kermits (including the vt100 one) exit as soon as they get an B
packet.
I will be fixing this and "Real Soon Now" ...
--
--
S.A. Thurlow
UUCP: {decvax,seismo!mnetor,utzoo}!utcs!thurlow
ARPA: ??????dpvc@ur-tut.UUCP (David Cervone) (11/25/86)
In article <576@cubsvax.UUCP> dss@cubsvax.UUCP (David Silver) writes: >In article <burdvax.2838> wpl@burdvax.UUCP (William P Loftus) writes: >> >> >>Anyone have the same problem? >> >>I cd-ed into a directory using the menus of vt100, and startup kermit >>with * as the filename. After transfering the first file in the directory >>all the other files timed-out. >> > >Yup. I found that I couldn't send multiple files by doing a kermit r on >a remote machine and kermit send * on the vt100 kermit. The first file >got transfered, the remote kermit went away, and the vt100 kermit sat >there trying to send the rest of the files to noone. Any ideas? > >-- >David Silver >{philabs,rna}!cubsvax!dss >cubsvax!dss@columbia I haven't looked at Dave Wecker's code, but you might want to check that all the files are being sent as one batch. The local Kermit should send a start- of-batch packet (S?), then a start-of-file (F?), then send the file data packets and then an end-of-file packet (B?); at this point a second start-of-file packet can be sent, and finished with an end-of-file packet. Additional file are sent in the same manner. When all the files have been sent, an end-of-batch packet (Z?) is sent. When the "Z" packet is received by the remote Kermit, the RECEIVE command should complete. If Dave's code sends each file in its own batch (i.e., if he sends an "S" and "Z" packet for each file), then you will not be able to send more than one file at a time to a Kermit that is not in server mode. As I said, I haven't looked into Dave's code, but you asked if anyone had any ideas, and this one sounded plausable. Hope it helps. Davide P. Cervone University of Rochester Computing Center DPVC@UORDBV.BITNET