Rick's b.log - 2008/09/01
It is the 24th of November 2024 You are 3.145.115.139, pleased to meet you!

Ohmigod, now what?

I'm not overly worried as the woman who will be employing me handed me a piece of paper on which she has written that I begin "8/9/08", there's a scan of it on 24th July. But, really, who screwed up this time?

BBSing in a modern world

My version of VisualBasic doesn't want to talk to the WinSock ActiveX thingy. Must work out what that's about. So not to be defeated by some silliness, I decided to do it the hard way. A naff mixture of WSA commands and Berkeley sockets calls. And you know what? The bloody thing actually works. And better yet, it actually works across the intranet! (well, I had to (partially?) disable the Windows Firewall, must look into configuring that properly)

Here are the RISC OS telnet clients all on the iconbar:

Connecting to the server using each terminal was pretty much like:

When a user connects, basic telnet negotiation takes place, this is basically to say "don't echo stuff". The user would then be expected to enter their name and password, but this has not been implemented yet.
The text in the examples below is not strictly correct. You see, believe it or not there is no simple way to determine if a socket is active or if it has been disconnected, so I employed a quirky little cheat. If the line rests inactive for 60 seconds, MiniBBS will make the remote terminal beep. The side effect is that if the line has been disconnected, the send() call will fail and we can detect that. If the line is still active, the terminal will beep three times, at five second intervals, before the server times-out the line. So either way, the maximum a line can be tied up for without any activity is 1m15s.
Now, those C programmers among you might be saying "What's wrong with select()?". This, for those who don't know, is a command that will report on the readability and writeability of sockets. It is exactly what I am looking for, but sadly you cannot just pass a socket handle and two integers and get it to return status. Oh no, that's far too easy. Instead it will attempt to report on all sockets. Not bad, until you discover the FD_SET macro (to set a socket in the status bitmask) looks like this:

#define FD_SET(fd, set) do { u_int __i;\
for (__i = 0; __i < ((fd_set *)(set))->fd_count ; __i++) {\
	if (((fd_set *)(set))->fd_array[__i] == (fd)) {\
		break;\
	}\
}\
if (__i == ((fd_set *)(set))->fd_count) {\
	if (((fd_set *)(set))->fd_count < FD_SETSIZE) {\
		((fd_set *)(set))->fd_array[__i] = (fd);\
		((fd_set *)(set))->fd_count++;\
	}\
}\
} while(0)

The character codes you can see in the examples are for me typing "This is a test!" in the terminal.

Nettle
Nettle v0.2010r (2001/09/16) provided an "xterm/color" terminal, but it had problems that it echoed everything - and this is with MiniBBS performing basic telnet protocol negotiation and saying "please don't local echo".

FreeTerm
FreeTerm v1.44 (2000/12/30) provides a basic monochrome emulation of a VT102. It's a shame it isn't colour-capable as it is quite pleasing to look at. Odd quirk, it can't do ^C (so I've also made MiniBBS close a connection with ^X).

VoyTerm2
VoyTerm2 v0.90 RC1 (2002/01/16) provides a colourised VT102 emulation, and - yikes - that bold text is kinda heavy - using what looks like offset overprinting instead of brighter colours! Still, it worked well.

ANTterm
I had a copy of ANTterm lingering around and upon installing it I saw that it was complaining about its serial number dohickey was damaged. Well, do you seriously think I'm going to trash my room for some floppies I've not seen in a decade (and in another country!) when I can make three EQ instructions NV with !Zap? O'course not! <clicky><clicky><clicky> That's ANTterm sorted! ☺
ANTterm v0.73 (1997/07/03) claims VT220 compatibility, while looking much like an ANSI colour terminal. The font is okay. What lets the terminal down is that it is the only one to be outputting additional negotiation codes after the start-up. I might insert an additional short delay if this is an issue, but so far it only manifested with ANTterm. Oh, and while it claims to negotiate (the "[255][252][ 31]" at the start of the responses), it paid no attention to my request to not local echo.

Console telnet
The console "telnet" program supplied with XP works quite nicely, which was something of an unexpected surprise. It even negotiates, doesn't echo, behaves itself... Wow!

HyperTerminal
Believe it or not, HyperTerminal can do telnet! Well, it can if you have the XP version (v5.1 2001). When you are asked for a connection, name it, pick the phone with the atom 'cos it's a cute logo, then choose Connect using TCP/IP Winsock and you'll be asked for a host and a port. It's as simple as that.
Useful hint - the call and disconnect buttons up top will re-establish and/or disconnect the connection.

And here's the status display:

It gets more interesting when you consider one program managing several 'linetasks'. The way it was handled under RISC OS in the servers I remember looking into, namely ARCbbs and ArmBBS (though I presume RiscBBS, ArchiBoard, and NewsFlash are similar) work by having a control program that sits on the iconbar, and each BBS linetask is controlled by a separate linetask program which runs in the background. The benefits are many, as the linetask can run essentially as a state machine for everything that is happening.
Unfortunately, the drawbacks are equally numerous and important. Firstly, I would need to start writing DLLs to oversee operations and shift all of the messagebase code into C. Why? Well, what happens if user #1 deletes a message that user #2 is about to read? With a shared program, each task can be already aware of the state of the messagebase. It may be trickier if the message being deleted is actually being read at that moment (though a "message in use - try again later" error might suffice?). Secondly, in the good old days each linetask looked at a serial port. End of story. Us, working as a telnet system, have only one port to look at, and from there the connect() call will allocate us a special port number and resume looking at the telnet port - if that doesn't make a lot of sense, don't worry, that's just how it works to the port in question can remain free instead of being tied up by the first incoming connection. It isn't out of the question to have the overseeing program handle connections and fire up linetasks, but that would be a messy implementation.
And from the stand-point of efficiency, I really loathed how ARCbbs needed a ~300K linetask program for each port, with what was essentially a lot of duplicated code. That, with buffering and all the other junk (the WimpSlot per linetask being 384K, plus 288K for the overseeing program), meant that a 4Mb computer could probably run a two-line BBS. Anything else would start to get awkward (remember, 'doors' and sysop tools need memory too).

What I have in MiniBBS is a central loop that affectively looks to see:

1. Is the line timing out?
   (if so, handle that with the beeps and the disconnect)
2. Is there data buffered?
   (if so, read the byte)
3. Is there data in the to-send buffer?
   (if so, send in 512 byte chunks)

The reception? Well, I am going to have to code the linetask arbitrator in such a way that it will 'know' what is going on at every moment, so it can handle an incoming byte, and then 'exit' back to the central loop, and may be called for a different line doing something totally different. That ought to be, um, interesting.
To be honest, the byte arbitration is not terribly quick and is totally unsuitable for cases where the user might wish, say, to drag'n'drop a pre-written message (as a text file) into the message editor. I have thought of this, and you will see the beginnings of this concept if you hold down a key. For example, holding down 'A' would report something like:
  [ 65][ 65][ 65][chunk "AAAAAAA"][ 65]
Which means that the incoming byte threshold has been exceeded to the buffer was emptied as a string, not as individual bytes. I see no reason why this would happen in the menus, so this will be a mode specific to the message editor.

MiniBBS - have a go!

When you first start MiniBBS, it will ask to be configured:

When MiniBBS starts, it will pop up a little (and I mean little) display at the top-left of the screen. It does not force itself to the top so it can get hidden, however you can Alt-Tab it back.
It looks like this:

Double-clicking the word "MiniBBS" will open the status window:

In order to log-off, you must open the status window, go to the Server menu, and choose Shutdown. This will notify any current connections that you are closing down the system, and it will shut down tidily.

Want to edit the welcome display? In MiniBBS\sysdata\login is the file "welcome.txt".
You might wonder why it contains inline VT100/ANSI codes. This is because the server defaults to VT52 mode initially, and switches to VT100/ANSI mode when it knows you are using a capable terminal; hence the in-line codes to override this.
Don't try colour codes (like "{red}" and "{bgyellow}"), they are ignored until a user logs in, and that isn't available yet!
I might change this to assume VT100/ANSI unless told otherwise. D'you think the majority of telnet clients can do at least a VT100 emulation? Email me!

Logging in? Start MiniBBS. If you are going to log in on the same computer, either enter the hostname (as in the example below) or "localhost". If nothing seems to work, enter the IP address 127.0.0.1.
Leave the port at 23 (if you aren't offered, set it to 23).

To connect from a different computer, the process is the same - enter the computer's hostname (if you have a local DNS server or "hosts" file set up) or its IP address. If you have a computer on an intranet, you ought to know its IP address. That's the one that looks like "192.168.0.x" (or, less commonly, 10.0.x.x).
If you are trying to connect to a computer that is connected to the internet, particularly with dynamic IP addressing, you can determine the machine's current IP address using "netstat" or "ipconfig" on the command line of the computer concerned (refer to Windows help for details); alternatively double-click on the little two-computers icon in the system tray (bottom right, by the clock) and look for the IP address there.

If it fails when you believe it should not, then from the server, try to ping the client machine. It will look something like:

C:\>ping alyson

Pinging ALYSON [192.168.0.1] with 32 bytes of data:

Reply from 192.168.0.1: bytes=32 time<1ms TTL=128
Reply from 192.168.0.1: bytes=32 time<1ms TTL=128
Reply from 192.168.0.1: bytes=32 time<1ms TTL=128
Reply from 192.168.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

Ping statistics for 192.168.0.9:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

What this is, most likely, is the Windows Firewall blocking unwanted incoming connections. You are, currently, on your own regarding permissions required to get MiniBBS comms to pass the firewall. As I don't have internet here, I simply switched it off for the testing!

Today's word

Your comments:

No comments yet...