paul@csnz.nz (Paul Gillingwater) (09/19/88)
I'm planning to set up a UNIX based BBS on a 386 box, and I'd like some
advice on various aspects.
1) New Zealand supports a nation-wide CCITT X.25 network. I have two options
for providing access (I think): either direct dial-up to an auto-answer
modem (by-passing the X.25), or through the Packet Switch network.
2) If I use the Packet Switch network, there seem to be two options: either
lease a PAD with asynchronous ports, and hardwire each port to a getty
on the UNIX box, or find BBS software that can support a direct X.25
connection. Does anyone know how this can be done?
3) I understand that classic BBS usage requires character-based connection,
so that the BBS can support interactive editing and word-wrap. X.25
however is more suited for line-based usage, sending a packet for each
line that is transmitted. Clearly, character mode connections are much
less efficient - is there any BBS software that will cope elegantly with
line-based interaction? Will this impinge upon, e.g. ZMODEM transfers?
4) Which flavour of UNIX is better suited for X.25 or BBS work - Xenix/386
or the MicroPort? I'm a SCO Xenix user at present.
5) I believe there are plug-in cards with multiple modems available that
support multi-user BBS under DOS - will these work under UNIX, and
more importantly, will they work with a 20 MHz 386 bus?
Thanks in anticipation.... e-mail and I will summarize...
--
Paul Gillingwater UUCP: {alberta,ubc-vision}!calgary!vuwcomp!dsiramd!csnz!paul
Computer Sciences New Zealand Ltd. ACSnet: paul@csnz.co.nz
Magic Tower BBS (24 hrs) NZ +64 4 753-561 (V21/V23/V22/V22bis/B103/B212A)dave@lsuc.uucp (David Sherman) (09/25/88)
In article <62@csnz.nz> paul@csnz.co.nz (Paul Gillingwater) writes: >3) I understand that classic BBS usage requires character-based connection, > so that the BBS can support interactive editing and word-wrap. X.25 > however is more suited for line-based usage, sending a packet for each > line that is transmitted. Clearly, character mode connections are much > less efficient - is there any BBS software that will cope elegantly with > line-based interaction? Will this impinge upon, e.g. ZMODEM transfers? We've been running a UNIX system that's accessible via Datapac, the Canadian X.25 network, since 1984. It's a v7-based system (Perkin-Elmer 3220). Our users include students located across the province of Ontario (and, in some cases, across the country) doing CAI courses, and staff in our Ottawa and London, Ontario offices, doing database access, email, some editing, and "notes" (internal computer conferencing). None of the out-of-town staff use Usenet much. To avoid ridiculous charges, you do indeed need to operate on a line-by-line basis. We set up our calls (using X.29 to set the remote PAD when the call comes in) to have a packet transmitted on CR or any control character; that allows interrupt chars such as DEL, ctrl-C or ctrl-\ to send the packet. We make do fine with line-based editors (a souped-up version of "ed", the University of Toronto ed), a line-based version of "notes", etc. A few things aren't quite as pleasant, but on the whole it functions fine. You have to make sure you turn on echo on the caller's PAD (have them do it themselves or you do it for them with X.29), and stty -echo at the UNIX end. I have some hacks to login, passwd and similar tools (actually a change to getpass(3) catches all of these) to change the concept of "turn echo off" for PAD lines to mean "send an X.29 instruction to turn echo off at the far end" rather than "stty -echo". If you want to run "notes" for your BBS software, I have a hacked-up version that greatly simplifies all the commands, and uses line-based interaction only. It's based on the version of notes that was current in the fall of 1984. David Sherman The Law Society of Upper Canada Toronto -- { uunet!attcan att pyramid!utai utzoo } !lsuc!dave
karl@mstar.UUCP (Karl Fox) (09/27/88)
In article <1988Sep25.001151.6452@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: >To avoid ridiculous charges, you do indeed need to operate on a >line-by-line basis. We set up our calls (using X.29 to set the >remote PAD when the call comes in) to have a packet transmitted on >CR or any control character; that allows interrupt chars such as >DEL, ctrl-C or ctrl-\ to send the packet. > >We make do fine with line-based editors (a souped-up version of >"ed", the University of Toronto ed), a line-based version of >"notes", etc. If you have a directly attached X.25 interface, it can use X.29 commands to put the remote PAD into character-by-character mode when using VI or EMACS and then return it to line mode when you go back to your shell. An external PAD connected via serial lines can't see the tty ioctl() commands, and therefore can't detect the user's intent as well. Ioctl() commands can send X.29 commands to set echo, erase and kill characters, forwarding characters for ksh or tcsh users, etc. Even with a serial-line-connected PAD, however, a knowledgeable user can log in, escape back to PAD command mode, change parameters to use character-by-character mode, go back to data mode, and run VI. Not convenient, but it is possible. -- Karl Fox, Morning Star Technologies ...!{att,osu-cis,pyramid}!mstar!karl
dave@lsuc.uucp (David Sherman) (10/06/88)
In article <934@mstar.UUCP>, karl@mstar.UUCP (Karl Fox) writes: > In article <1988Sep25.001151.6452@lsuc.uucp> dave@lsuc.UUCP (David Sherman) writes: > >To avoid ridiculous charges, you do indeed need to operate on a > >line-by-line basis. We set up our calls (using X.29 to set the > >remote PAD when the call comes in) to have a packet transmitted on > >CR or any control character; that allows interrupt chars such as > >DEL, ctrl-C or ctrl-\ to send the packet. > > > >We make do fine with line-based editors (a souped-up version of > >"ed", the University of Toronto ed), a line-based version of > >"notes", etc. > > If you have a directly attached X.25 interface, it can use X.29 > commands to put the remote PAD into character-by-character mode when > using VI or EMACS and then return it to line mode when you go back to > your shell. An external PAD connected via serial lines can't see the > tty ioctl() commands, and therefore can't detect the user's intent as > well. Ioctl() commands can send X.29 commands to set echo, erase and > kill characters, forwarding characters for ksh or tcsh users, etc. Sure, but you can simulate this by arranging for ioctl() to send the PAD the appropriate X.29 triggers. That's effectively what we do, but rather than muck with ioctl I just changed getpass(), which was all I needed. For a more complete solution you'd just change the ioctl() routine in /lib/libc.a to invoke the real ioctl code on non-PAD lines and send X.29 trigger sequences on PAD lines, and recompile all your applications. Of course, you need to standardize on what trigger sequences will have your PAD send our X.29 commands, and avoid using sequences that can occur in your data. We set up our Memotec PAD to treat ^A^A^A as "echo on" and ^B^B^B as "echo off". > Even with a serial-line-connected PAD, however, a knowledgeable user > can log in, escape back to PAD command mode, change parameters to use > character-by-character mode, go back to data mode, and run VI. Not > convenient, but it is possible. Sure it's possible. The problem on any large network such as Datapac is that the turnaround time will be too slow for echo to be comfortable. (Read: it would be downright painful.) David Sherman Toronto -- { uunet!attcan att pyramid!utai utzoo } !lsuc!dave