Hello Bob!

May 30 17:21 03, Bob Jones wrote to Bo Simonsen:

 BS>> What UNIX systems did you work with?

 BJ> Let's see if I can remember the various flavor's I've used....

 BJ> * BSD 4.3 on old Vax 11/780 based (and newer) hardware...
 BJ> * Various flavor's (and renames) of DEC's version of Unix (Ultrix, 
 BJ> True64, etc.), on various DEC based equipement (DEC-20, Vax 11/780, 
 BJ> Alpha, etc.)
 BJ> * Hmmm....  Sun's variation of Unix (Solaris?) 
 BJ> * NeXT Step (3.1, 3.2, 3.0, 2.?), which is really the NeXT Step GUI 
 BJ> on top of a BSD (4.3?) flavor of Unix running on a Mach kernal.
 BJ> * Irix (System V based) on 

 BJ> I may have forgotten a few I've played on.  At one point, I prefered 
 BJ> BSD based Unix systems over System V based systems, but at this 
 BJ> point, either will do.

Ok, you've worked in somekind of companey where they used those unixes?

 BS>> And if the BBS got a 
 BS>> **EMSI_something_there_is_not_IEMSI i should call the 
 BS>> Mailer? 

 BJ> Hopefully, any protocol that leads to an FTS based fidonet session 
 BJ> will be handled prior to Max starting, so I see no reason for Max to 
 BJ> call a mailer.  There are no options for Max to call the mailer under 
 BJ> OS/2 or DOS when Max is used in a wait-for-caller mode (i.e. where 
 BJ> Max answer's the phone line)....

No, me neither, but i'm rather comfused about the case.

If it was up to me the raw IO module should be rewritten, so it works...
and then max -k should be copied and rewritten a bit, so it asked about
username/pwd, and it might work then.

The is some IO problems about using the telnet-curses module.

 BS>> Then we got a underfull tool like mgetty, i don't find 
 BS>> it smart to program your own serial communication unit.

 BJ> That's why we should be using a flavor of getty for answering the 
 BJ> serial ports or even TCP/IP "telnet" type ports.  [The
TCP/IP telnet 
 BJ> ports used to be PTYxx while RS-232 based ports used to be TTYxx on 
 BJ> most systems I've used.  Ah....  I see PTS# under my Debian Linux 
 BJ> setup for the pseudo terminals instead of PTYxx devices.]

That's right, but what the problem about communicating thru ttySX?

 BS>> You don't see my point?

 BJ> We may still have a communication gap.....  I'm not sure....

If i understand you well, we mostly agree.

 BS>> But there is a terminal issue, that it's the IO now 
 BS>> over telnet is using ncurses and it won't work out over 
 BS>> mgetty, but maybe we could use the RAW IO, so max just 
 BS>> is called by max -pots or something, then it start up 
 BS>> like local login.

 BJ> For the most part, terminal IO [including ncurses issues] doesn't 
 BJ> matter wether it is telnet or RS-232 serial port (to modem) or some 
 BJ> other lower level connection methoid.  

That's right..

 BJ> If the Unix error /signal 
 BJ> handling (interupts) are properly implemented, then a disconnect 
 BJ> (modem hang up or TCP/IP port closure) comes in to Max with the 
 BJ> proper signal.  

Oh i see, for example MBSE, have a mbtask manager there ensure that the
processes whitch doesn't exist is beeing killed.

 BJ> I'll admit I haven't looked at how Linux may be 
 BJ> different than BSD flavored Unixes in this regard.....  I may be 
 BJ> getting into differences between System V and BSD flavors....  And 
 BJ> Linux was (originally?) a System V flavored clone.

Linux is a sysv flavored clone.. But it's only about the initializing method?

I/O is quite the same in most unixes?

 BJ> Now it may matter for when Maximus needs to disconnect the 
 BJ> session.....  Because Max may need to force the modem to hang up in 
 BJ> that case.  

As it's now does maximus sends a ATH even over telnet.. if we are
communicating between ttySX it should be possible.

Maybe it should be +++ATH+++..

 BJ> On the other hand, the system services code that 
 BJ> (re)starts getty (or getty it self) may need to be properly 
 BJ> configured to "hang up" the modem when Max closes out the 
 BJ> session.....

That's right..

 BS>> Agree captian, so the things work.

 BS>> If we provide the two things, we could get mgetty, working quite 
 BS>> quickly.

 BJ> Using getty can get us completely out of the issue of handling 
 BJ> opening up TCP sockets, etc...  The TCP/IP socket handling / deamon 
 BJ> code will only handle TCP/IP based connections.  Getting Max to talk 
 BJ> running under getty based connections gets us both TCP/IP and serial 
 BJ> port type connections with the exact same code.  Have you ever looked 
 BJ> at pseudo terminals in a Unix based environment?  Unfortunately, 
 BJ> using getty will mean needing to look into some IOCTL functions to 
 BJ> make sure we are 8 bit clear and not interpreting control caracters, 
 BJ> etc.
 
Well the TCP/IP thing works now, so i'm doesn't care about it now.. And i'm
satisfied about that method maximus is running over with tcp/ip.

The POTS/ISDN handlingen is what i care about.. 

 BS>>> Inetd calls a program with -h hostname and other 
 BS>>> arguments, mgetty calls it with -b connect bound ... Or 
 BS>>> something.

 BJ> Agree that we may need one or more command line arguments to flag Max 
 BJ> being rung from inetd....

Ofcause.

 BS>> How would you configure mgetty/getty for tcp 
 BS>> connection? (without the program is listening on a tcp port)

 BJ> Your TCP/IP based code may be the better solution 
 BJ> for the short term, since you know understand what you are doing 
 BJ> there....

It's not mine ;)

 BS>>> I wonder if the operating system can?

 BJ> It can.  A POTS / ISDN call to a modem on the physical system will 
 BJ> (typically) come in on a TTY port (see the devices listed by 'ls 
 BJ> /dev/tty*').  The telnet call will (typically) come in on a pseudo 
 BJ> terminal port (PTY port in older systems, see the devices listed by 
 BJ> 'ls /dev/pty*').  If you get into the OS information of those devices 
 BJ> you will find the differences at the operating system level.

Yes, that's right (on linux it's ttySX) :)

 BJ>> At a low enough level, yes.  One of the problems with some folks 
 BJ>> imeplementing the isolated one or two modems on a unix system was 
 BJ>> folks didn't always turn on the options to "logout"
when modems got 
 BJ>> disconnected.  It's not a good security "feature" to
be able to call 
 BJ>> back on a modem line and pick up exactly where you left off -- 
 BJ>> without any login prompts.  This was a fairly common mistake on 
 BJ>> systems where most users came in via hardwired 
 BJ>> terminals or telnet'ed 
 BJ>> into the system....

Yes i see the problem. I ran elebbs too, if a user didn't close the session
correctly, the process used all my CPU power.

 BS>> But obviosly on the high level, i mean what the user in 
 BS>> the other end sees, it doesn't.

[i see your point]

 BS>>> The idea in having maximus listening on a port, could 
 BS>>> be it would control the chat system and so on, but it 
 BS>>> doesn't do that... 

 BJ> Ah....  Yes....  If Maximus was a TCP server (deamon), and if all 
 BJ> Maximus nodes were TCP/IP based, then yes, we could rely on the 
 BJ> internal chat function relying on a parent / child process and the 
 BJ> items this allows (potential common memory, or pipes, etc.).  
 BJ> Unfortunately, this doesn't handle (a) a local console session (moot 
 BJ> point with telnet to local host), or (b) serial port based 
 BJ> connections (needed for the modem based sessions).....  

Excatly.. my i really doesn't see a good reason to use IPC.

 BS>> If one process was fork()ing them all, there could be 
 BS>> inter process communication, so the chat system and so 
 BS>> on will be working, multinode.

 BJ> Ah....  As I mention above, this only handles the TCP/IP based 
 BJ> sessions if max is a TCP/IP server / deamon.  Another method is 
 BJ> running a chat deamon for Maximus, and have each node connect to it 
 BJ> for interprocess communication.  I believe Max under OS/2 does 
 BJ> something like this.  If I remember correctly, if Max doesn't see an 
 BJ> IPC process running, it starts it, and in either case then connects.  
 BJ> Chat, Who is on, and maybe one or two other things use this piece of 
 BJ> code....

It's controled by writing/reading files afaik. But it's too somekind of
IPC, the way i thought about was send()/recv().

 BS>>> Even more, it share configfile with my ticker, 
 BS>>> msgeditor and other programs.

 BJ>> Understand.  I haven't broken down to configure fidoconfig yet....

 BS>> All my fidonet utillities except for my mailers and 
 BS>> fastlst is using fidoconf.

 BJ> Which is why compatibility with fidoconf via some methoid (scripts, 
 BJ> direct support, etc.) will be useful in the Unix / Linux environment. 
 BJ>  And with the Husky tool set ported to OS/2 and Windows based 
 BJ> environments, will also help there.

All the husky tools works on OS/2 and Windows too?

My BOSS runs hpt/OS2

 BS>>     * Maximus should have 2 options for using tcp/ip 
 BS>> connections, it should be listening on some port by it 
 BS>> self, and it should be called from inetd.

 BJ> As seen above, this could actually be optional....  But it is how you 
 BJ> have started porting the code....

Not me, wes ported the most of it, i actually only made some corrections so
it compiled (and worked) on newer Linuxes...

And i did some corrections in msgapi too..

 BS>>     * Maximus should be called from mgetty, after it 
 BS>> detects it's a human call.

 BJ> Be it hardwired terminal, modem, or a (telnet or TCP/IP) pseudo 
 BJ> terminal connection.....

Hmm?

 BS>>     * Maximus should _never_ be a telnet only bbs.

 BJ> Agreed....

If i would like so, i ran synchronet :)

Regards,
Bo

--- Msged/LNX 6.1.2