dave@sdeggo.UUCP (David L. Smith) (05/10/87)
I've got a SysV.2 system and there is an X.25 protocol documented in the manual. However, it says that there are no settings for baud rate with this. What's the scoop? In my experience with X.25 I've had external PADs hooked up to serial ports. Does this assume a baud rate or is it looking for an internal PAD of some form? Is this protocol compatible with the 'f' protocol documented in the BSD 4.3 UUCP manual? Thanks in advance, David L. Smith -- David L. Smith sdcsvax!sdamos!sdeggo!dave, ihnp4!jack!man!sdeggo!dave, hp-sdd!crash!sdeggo!dave sdeggo!dave@sdamos.ucsd.edu "Morals are one thing. Ratings are EVERYTHING!"
brad@bradley.UUCP (05/15/87)
System V is not compatable to the 'f' under BSD....we move the 'f'io.c file to system V instead.
csg@pyramid.UUCP (05/16/87)
In article <52@sdeggo.UUCP> dave@sdeggo.UUCP (David L. Smith) writes: >I've got a SysV.2 system and there is an X.25 protocol documented in the >manual. However, it says that there are no settings for baud rate with this. True, if you're on an AT&T or DEC system using an internal PAD. It's a board in the bus, and baud is pretty meaningless in that context. And while you do have a synchronous serial link from the board to your PDN modem, that speed is part of the system configuration, and not under user control. >In my experience with X.25 I've had external PADs hooked up to serial ports. Like Dynapac, Micom, and others? Depending on your implementation, SVR2 UUCP will run X.25 on those, too, as will the BNU (HoneyDanBer) UUCP from SVR2.0.4 and SVR3. I wouldn't advise this, though, for the reasons below. (Binary sites should note, too, that AT&T no longer is shipping BNU with the X.25 support enabled. You have to have source, and recompile.) >Is this protocol compatible with the 'f' protocol documented in the BSD 4.3 >UUCP manual? No. The 'f'-protocol uses a 7-bit-printable-ASCII encoding (suitable for the bizarre international gateways) and carries a checksum accross the entire file for error detection. AT&T SVR2 and BNU use the 'x'-protocol, which requires total 8-bit transparency and provides no error detection whatsoever. Neither uses packetizing, and both depend on the underlying hardware for flow control and catastrophic failure detection (like a down line). I would discourage the use of the 'x'-protocol for anything other the domestic links using an internal PAD, where the error rate between the PAD and the UUCP software is likely to be very low (and error corrected by hardware). External PADs will introduce flow control problems (you can't use XON/XOFF), and you'll never know if an error occurs. You can use good ol' 'g'-protocol through an external PAD on domestic X.25 links, although it will nearly quadruple your packet charges. If you are not paying by the kilosegment, then this won't matter much. Note that the 'f'-protocol source is publically available from mod.sources archive sites. The 'x'-protocol is proprietary to AT&T. <csg>
korn@altger.UUCP (05/25/87)
the x-protocol ha one mayor problem with x.25:
at the end of the file transfer, a datapacket with
length zero is transmitted. i dont know any
pad-software, that takes care of zero-sized packets. do you?
replies requested!
----------------------------------------------------------------------------
Hans Korneder UUCP: somwhere!mcvax!unido!altger!korn
SNAILMAIL: Gebsattelstr. 32, D-8000 Muenchen 90
VOICE: +49 89 4488373
----snip----snip----snip----snip----snip----snip----snip----snip----snip----
+-------------------------------------+
The opinions above are my own. | Advertising space for rent ! |
They can be yours too !! | Send requests to the adress above ! |
Send $57.95 to the adress above. +-------------------------------------+
(Offer void where prohibited by law or good taste)