dvv@hq.demos.su (Dmitry V. Volodin) (08/30/90)
Is there something like that? Dima <dvv@hq.demos.su> or <dvv%hq.demos.su@fuug.fi>
lars@iclswe.icl.se (Lars Tunkrans) (09/12/90)
dvv@hq.demos.su (Dmitry V. Volodin) writes: >Is there something like that? Yes, there is in two variants that I know of : 1) The UUCP "f" type protocol which I have only heard of, I have got the impression that this UUCP version runs over the X.25 network layer and is a SVR 5.2 soloution. 2) On SVR 5.3 and SVR 5.4, ICL has implemented the UUCP "e" type protocol to run over the Transport Level Interface ( TLI ) that AT&T supplied as a part of SVR5.3, Using the TLI we can use UUCP over the OSI transport protocoll that sits on top of X.25 as Layer 4 in the OSI model. This also works with OSI protocol on Ethernet. Hope this helps Lars. -- Lars Tunkrans Phone +46 (0)76096368. | The ICL DRS6000 SPARC system is still DRS Systems Support. | the only off the shelf deliverable UUCP: uunet!mcsun!sunic!iclswe!lars | Unix System V Release 4.0 system. DOMAIN Address : lars@iclswe.icl.se |
csg@pyramid.pyramid.com (Carl S. Gutekunst) (09/17/90)
>Is there something like that?
Sure. Half the world is still using UUCP or X.25 as its primary transport
medium for UNIX E-mail and news.
If you are running end-to-end between host X.25 implementations (no external
PAD), and the implementation has some way for UUCP to easy place calls, then
it is possible to run plain old 'g' protocol over X.25. It's can be expensive,
though; 'g' data packets are 70 bytes long (two segments!), and all those
uucico RR packets tend to come back one packet per. The uucico RR delays can
also kill throughput.
To cut costs, and to run properly across PADs that are not 8-bit transparent,
Piet Beertema and Robert Elz wrote a thing called 'f' protocol. The source is
public domain; it has been widely integrated in non-AT&T Unixes. (Peter Honey-
man actually gave the AT&T UNIX folks a version of HoneyDanBer that had 'f'
protocol in it. AT&T ripped it out, claiming they already had their own UUCP
or X.25 protocol, called 'x'.) The 'f' protocol assumes that the link is
"mostly error free," and not 8-bit transparent; it quotes all 8-bit and non-
printing characters (good for PADs, bad for costs), and does not send any
data acknowledgements until the very end of the file (a big win).
The afore mentioned 'x' protocol is garbage. Don't waste your time.
Of course, there are also lots of ways to run higher-level protocols over X.25
(including SNDCF and ISO transport), and if your X.25 can use one of those you
can accomplish something similar. But it adds a lot of overhead, and requires
both ends to be running the same high-level protocol; I don't think that is
what you were asking....
Note that many international sites have now abandoned X.25 in favor of dial-up
lines and Telebit TrailBlazers. They are considerably faster than 9600-baud
international X.25, and about a factor of 10 cheaper. Not as realiable (calls
don't always go through to some countries), but at these prices, who cares?
<csg>src@scuzzy.in-berlin.de (Heiko Blume) (09/21/90)
if your x.25 line is 8 bit transparent (the pad should allow to set this) you might also (apart from f) look into e protocol which is a streaming protocol that expects the line to be error free -> no overhead at all. we use it over HST modems which works very nice. however your serial ports must not loose a single character, otherwise the protocol will timeout and drop the line. -- Heiko Blume c/o Diakite blume@scuzzy.in-berlin.de FAX (+49 30) 882 50 65 Kottbusser Damm 28 blume@scuzzy.mbx.sub.org VOICE (+49 30) 691 88 93 D-1000 Berlin 61 blume@netmbx.de TELEX 184174 intro d scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp
prc@erbe.se (Robert Claeson) (09/24/90)
In a recent article src@scuzzy.in-berlin.de (Heiko Blume) writes: >if your x.25 line is 8 bit transparent (the pad should allow to set this) >you might also (apart from f) look into e protocol which is a streaming >protocol that expects the line to be error free -> no overhead at all. >we use it over HST modems which works very nice. however your serial ports >must not loose a single character, otherwise the protocol will timeout >and drop the line. Actually, as I understand it, the 'e' protocol isn't intended to be used via a PAD, but directly over X.25 PLP (layer 3) and with the X.25 interface directly in the system. -- Robert Claeson |Reasonable mailers: rclaeson@erbe.se ERBE DATA AB | Dumb mailers: rclaeson%erbe.se@sunet.se | Perverse mailers: rclaeson%erbe.se@encore.com These opinions reflect my personal views and not those of my employer.
enag@ifi.uio.no (Erik Naggum) (09/24/90)
Is there something which would handle X.25 Reset Requests correctly? Most software I've had to look at get totally confused when they occur and most drop the line. Some simple protocol should use X.25 as a network service and decide on some resynchronization points and take it up from there. Too difficult? Or is that what AT&T did with their UUCP over X.25 protocol, which hasn't become very popular? -- [Erik Naggum] Naggum Software; Gaustadalleen 21; 0371 OSLO; NORWAY I disclaim, <erik@naggum.uu.no>, <enag@ifi.uio.no> therefore I post. +47-295-8622, +47-256-7822, (fax) +47-260-4427
csg@able (Carl S. Gutekunst) (09/24/90)
>Is there something which would handle X.25 Reset Requests correctly? None of the present "X.25" protocols actually know anything at all about the underlying packet-level protocol. Generally, host-based X.25 implementations return an error when a Reset is received; uucico considers that a failure, and hangs up. PADs either toss the Reset, or insert a "reset" service signal. Both will cause uucico to detect a transmission error, and retry either the packet ('g' protocol) or the whole file ('f' protocol). PADs that barf on the Reset or that drop into command mode will cause uucico to time out. You *could* write something that detected Reset packets properly, and did a real layer-4 style resynchronization. But it would not be portable; there is no standard X.25 PLP applications interface. (If you have something like CONS, you are probably going through a higher-layer protocol anyway, so uucico does not need to care.) One alternative would be a generalization of 'g' or 'f' to recognize certain types of errors (like EL3RST, for you System V fans) as a temporary condition, and try to recover from there. With 'f' that is much harder, since the present implementations of 'f' provide no way for the receiver to notify the sender of a problem until end of file. >Or is that what AT&T did with their UUCP over X.25 protocol, which hasn't >become very popular? You mean 'x' protocol? It isn't popular because it doesn't work. It requires 8-bit transparency, has no error checking, no flow control, and requires that a zero-length data packet be able to be passed end-to-end to mark the end of file. Not only is this impossible with a PAD, some PDNs don't even recognize it as legal. <csg>