tpc@leibniz.UUCP (Tom Chmara) (09/22/88)
Not sure where to ask; hope these groups are fine. I'm trying to improve the news distribution within our organization. Here's the scenario: We have a number of USENETted machines. They interconnect using modems (1200bps and up). Our major feed is getting itself Ethernetted, and 9600 bps hardware is becoming available in-house -- this opens up two possible migration paths. The problem: The 9600bps interfaces are nonstandard: they don't look like Hayes, nor Ventel, nor anyone familiar. Hence, my SUN's uucp can't work with it. I've hacked it by writing a program which configures the line, dials the number, and calls uucico who treats it like a direct line. Kludgy, but it avoids needing source. Evidently, H-D uucp is better for configurability, but it doesn't come with SUNs, and isn't P-D to the best of my knowledge. The Ethernet is another option. In this hacking frame of mind, I've been thinking about performing the same kludge for it, for those of our feeds which support Ethernet: rlogin(1)ing into the desired feed, system(2)ing uucico, and voila, a high-speed feed. The question: I've had time to calm down and think. The thought I came up with is: does anyone on the Net have a better idea than this? Has anyone already handled these problems? NNTP as I understand it is not acceptable, as not ALL the hosts have Ethernet access, and we'd like to keep the Ethernetted ones fairly autonomous. Please save me from myself... ---tpc--- -- I am sole owner of the above opinions. Licensing inquiries welcome. ------------------------------------------------------------------------ Tom Chmara UUCP: ..utgpu!bnr-vpa!bnr-di!leibniz!tpc BNR Ltd. BITNET: TPC@BNR.CA
mouse@mcgill-vision.UUCP (der Mouse) (10/02/88)
In article <166@leibniz.UUCP>, tpc@leibniz.UUCP (Tom Chmara) writes: > The Ethernet is another option[:] rlogin(1)ing into the desired feed, > system(2)ing uucico, and voila, a high-speed feed. Hm. This might work, but it will be difficult to persuade rlogin to run with no escape character (unless you have source). Or unless your uucp has a protocol that doesn't expect a completely transparent 8-bit data path. > The question: > I've had time to calm down and think. The thought I came up with is: > does anyone on the Net have a better idea than this? Has anyone > already handled these problems? NNTP as I understand it is not > acceptable, as not ALL the hosts have Ethernet access, and we'd like > to keep the Ethernetted ones fairly autonomous. 4.3 uucp is capable of running over a TCP connection. I would hope that Sun has picked this up by now, but given how sluggish they've been about some other things (only with 3.5 did Sun get networking features that Berkeley has had ever since 4.3!), I'm not too optimistic. NNTP isn't entirely out of the question; some of your feeds can be NNTP-based without requiring all of them to be. Personally, I think NNTP is a Good Thing. But beware: the nntpxfer in the distribution we got (I don't know whether it's been improved since; I can't seem to reach anywhere to get a fresh distribution to check) was horribly inefficient. I have a much improved one; someday I'll send it in to Phil....in the meantime, anyone who wants can get a copy by sending me mail. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
niederle@lan.informatik.tu-muenchen.dbp.de (Herbert Niederle) (10/06/88)
Another way to exchange news over an Ethernet without using the Berkeley 4.3
uucp-t-protocol between local-node A and neighbour-node B works as follows:
1) Create on the remote node B the file A.cmd in the batched-directory
(mostly /usr/spool/news/batched/A.cmd) with the following contents:
rsh A -l news /usr/.../rnews
2) Create the analogous file B.cmd on your machine A
(mostly /usr/spool/news/batched/B.cmd) with the following contents:
rsh B -l news /usr/.../rnews
3) Add the entry "B news" on machine A in the news' .rhosts-file
4) Add the entry "A news" on machine B in the news' .rhosts-file
After all this is done, you can exchange news between host A and host B,
for example on host A, by executing the commands:
sendbatch B (from A -> B)
rsh B -l news -n /usr/.../sendbatch A (from B -> A)
You can bring these two commands into a shell-script, which for ex. tests
such things like, is the remote host up, have both enough space, before
starting the transfer.
We use this method under ULTRIX-2.2 and b-news 2.11.14 and it works great.
If you use sendbatch and during the transfer one machine goes down, then the
next sendbatch-call to that machine will continue ONLY NEARLY at the "break-
point". It may be, if the receiver went down first, that still about 1 to 3
topics are sent until the sender stops, and if you do nothing, these three
topics would be lost.
You can solve this problem this way:
Look before you execute the command "sendbatch B" for a B.work file in the
"batched-directory". If there is one, then the former "sentbatch B" wasn't
completet. If you always made a copy of the "batched-file" B before starting
sendbatch, then you can correct the B.work file by comparing the last copy of
the "batched-file" B with the news-logfile log on system B.
Replace the B.work file with the corrected one, execute "sendbatch B" and no
topic would be lost.
Because of 3) and 4) this is only recommended, if both news-users on
machine A and B can trust each other.
Hope this helps.
Herbert Niederle Inst. fuer Informatik, Technische Universitaet Muenchen
Postfach 20 24 20 8000 Muenchen 2, West Germany
niederle@lan.informatik.tu-muenchen.dbp.de Tel: +49 89 2105 8197
niederle%lan.informatik.tu-muenchen.dbp.de@ {relay.cs.net, unido.uucp}