gnu@hoptoad.UUCP (02/12/87)
Tonight I got hoptoad's uucp to call up uuslave, send mail, send files,
receive files, negotiate hangup, and hang up. Uuslave behaved itself
beautifully. It's the first time I've seen it really work.
To do this, I had to write an acknowledgement layer for uuslave. It
currently runs with window size = 1 (half duplex), unlike unix uucp
where if you watch the modem lights, you can see the data keep right on
coming while the acks go BLIP..........BLIP........BLIP........ at the
same time. With uuslave, it's a bit slower at the moment -- the data
stops while the ack BLIPS back -- but it's a lot easier to program and
there's a chance it will even run on non-interrupt-driven systems.
There are still a few loose ends, e.g. data packets aren't checksummed
yet, though the control info is checksummed. I will do a bit more
cleanup of this sort and post it to net.sources soon.
If a few SF Bay Area people want to get an early copy and make it
compile (if not run) on their IBM PC or Atari or Amiga or whatever,
that would save the rest of the net a lot of minor editing. I have it
running on Unix. Send me mail IFF you will work >= one day (or night)
on it this week, so I can post it soon.
Of course, uuslave still lacks a few amenities like: logging (hmm, who
*was* that who called my system and what files did they get?); master
mode (ability to dial out); uuxqt (a separate program that runs
commands for mail and news); larger windows to overlap data and acks;
and such. That stuff can wait til after I release the working
uuslave.c -- so we won't have to merge different versions as much.
If somebody could work on building a standalone, PD program that dials
a modem and goes through a login sequence (parameterized from a file or
argv) then this would make master mode uucp significantly easier.
I have heard that V8 Unix has a "dial" command that does this, but
it passes back a file descriptor via "streams" which is not very portable.
People with concrete ideas for the sysop's interface to the dialer
should post their ideas. Ideally we could get better control of the
login than the traditional uucp send/expect strings; anyone seen a
better paradigm, like in a fancy terminal emulator? I think I've seen
one described that has loops and conditionals and such. Function calls
would be great, since we could define a function like dial_pc_pursuit()
that would encapsulate all the hair and then just invoke it from the
host's dialing information. We can also use the same send/expect code
to talk to the modem's dialer and interpret the resulting status, so
users can configure it for whatever modem they have -- unlike Unix
uucp.
There may be some code we can use in C-Kermit but it will probably need
to be untied from the rest of Kermit. Volunteers?
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu
Overheard at a funeral: "I know this may be an awkward time, but do
you recall him ever mentioning source code?" -- Charles Addamsjc@cdx39.UUCP (02/13/87)
> > People with concrete ideas for the sysop's interface to the dialer > should post their ideas. Ideally we could get better control of the > login than the traditional uucp send/expect strings; anyone seen a > better paradigm, like in a fancy terminal emulator? One suggestion: include shell escapes in whatever syntax you develop. While hacking at uucico.c a while back, I found it extremely useful to make it interpret send-expect phrases that looked like "!dial foo" in the obvious way, with a non-zero exit implying failure. That way, it doesn't matter if your setup isn't quite perfect, because the user can then write a standalone program that does its own magic. This approach is better than a subroutine capability, because you don't need source code to invoke it. Congrats on your work so far. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: Uucp me out of here, Scotty; there's no AI on this node!