BS> (A danish pop band did actually made a song there is 
 BS> named Dr. Jones, are you a Ph.D? ;))

No, or not yet.....

 BS>> But actually what the reason for a WFC screen under
 BS>> Linux? I talked to Janis this afternoon on the phone
 BS>> (I'm calling USA to a few cents pr. minute by Internet
 BS>> phone), and she said it was very anying to see it run,
 BS>> because you couldn't get it away..

 BJ> Based on how the telnet code is currently working (for as far as Wes
 BJ> has progressed the code to date), the WFC screen is needed.

 BS> Unfortionally it's.. Made because Wes, do only emulate 
 BS> the modem, by implementing the write/get calls to the 
 BS> modem.

Basically true.  But it is done that way because that is how Max is coded
for hooking into right now.....

 BJ> The
 BJ> telnet code is only a single line support right now, and is like
 BJ> running a barefoot maximus or opus under DOS or 
 BJ> OS/2 (or Windows).  To
 BJ> get to the point of multi-line, the telnet stuff will need to be
 BJ> changed.

 BS> Automatically it's multiline. (It's here..)

And how are you handling multiple telnet sessions at one time?  

(a)  Are you Starting each up on a different tcp/ip port?  

(b)  Are you running a copy of Maximus for each telnet session?

 BJ> To prove that you only have a single line BBS support, try
 BJ> to make 2 or more telnet sessions to the same maximus telnet port at
 BJ> one time.  Only the first will succeed.....  And if you bring up a
 BJ> second copy of max/Linux for handling a second telnet port, you will
 BJ> have to use a different TCP/IP port number.

 BS> Well yes it handles only one telnet port, but more than 
 BS> one can be logging into the system at one time!

How are you starting maximus for this?  I don't think I've seen that work. 
How are the BBS sysop consoles handled in this siutation?

 BS>> The machine maximus is running on at my home, has not
 BS>> monitor so I didn't notice it.

 BJ> Well, if it wasn't there you would notice it, because the WFC screen
 BJ> is what is what does the initial handling of your connection with the
 BJ> BBS.

 BS> Yes I see.

 BS>>> Well at some time, maximus should be reverse engeeriered to
 BS>>> Windows.

 BJ>> Actually, Max could use a re-work for the multi-tasking
 BJ>> environment that Linux / Unix, OS/2 and newer Windows machines
 BJ>> support.....  But you have to watch out what you think when you
 BJ>> consider the differences between handling one (or more) serial
 BJ>> ports (with modems) vs TCP/IP based connections....

 BS>> Yes, but the most of the TCP/IP communication is like it's on
 BS>> UNIX afaik.

 BJ> Actually, not yet.  Under OS/2, I'm using the VModem (kludge) of SIO
 BJ> to have telnet (and VModem) TCP/IP sessions connect up to virtual com
 BJ> ports (and virtual modems) that each bink/max session connects to.

 BS> Well why don't write a natively TCP/IP connection module?

This is where the maxpipe and other issues may come in.  I believe the
(current) design of maximus includes a sysop console per available
connection....


 BJ> I
 BJ> currently have only two "lines" setup for telnet / vmodem access.
 BJ> The
 BJ> third attempt at a telnet / vmodem with my main (OS/2 based) system
 BJ> will not succeed....  Yes, I can add more "lines" 
 BJ> for telnet sessions,
 BJ> but it is still one instanciation of bink/max per
"line".....  Under
 BJ> unix, one way would be to have each new telnet session to the BBS
 BJ> spawn off it's own copy of the BBS.

 BS> Yes I noticed so (I've been loging on to your BBS by using telnet).

 BJ> This might be done under inetd,
 BJ> or via how Max opens the telnet port....  But this is not how it is
 BJ> currently done due to Max (sysop) console 
 BJ> issues.....  Which gets back
 BJ> to needing maxpipe (or similar) from OS/2 setup, along with a
 BJ> "virtual" console support added to maxpipe.....

 BS> I've not still understood why we just not can use STDIO.

 BJ> There are pieces of
 BJ> the max bbs code hard coded to expect (sysop) console support in
 BJ> addition to the user's terminal.

 BS> ?

 BS> [IPC]

All user interactions are displayed on their screen and on the sysop
console for that session.  So, the basic IO package is configured for
this.....

What was your question?

 BS>> Yes, but it would be nice as a multi line, because my
 BS>> default it's multiline because of the TELNET and POTS module.

 BJ> Yes it would be nice to have multi-line, but multi-
 BJ> line for telnet may
 BJ> need to be different than the multi-line support for POTS in the Unix
 BJ> environment.  And once that is done, we might be able to port native
 BJ> Telnet support back to the OS/2 environment (vs using the current
 BJ> VMODEM fix under OS/2).

 BS> Why actually using VMODEM? Why not natice TELNET?

Because maximus (under DOS, Win32 and OS/2) does not support native telnet.
 It support only what it thinks is a modem for the user.  Max was designed
to control a modem off a serial port interface, with a sysop console on the
system console....  To do anything else is a major code change....  Which
is also why Wes did the telnet support the way he did (for now)......

 BS>> That's right.. But I guess most people would run it
 BS>> from a frontend mailer.

 BJ> Front end mail on the serial port (modem lines) makes sense.  Front
 BJ> end mailers to the BBS on TCP/IP ports, while do-able, is not
 BJ> necessarily the smartest thing to do.  Yes, that's how I have it
 BJ> running under OS/2, but with TCP/IP, we should be 
 BJ> able to use one port
 BJ> for the front end mailer, and a different TCP/IP port for the BBS....

 BS> Yes I did only meant for POTS support :-)

Ok.

Take care.....

Bob Jones, 1:343/41



--- Maximus/2 3.01