That is great news. That also might help in getting it threaded. I believe it will be to tough to have it fully threaded. But what I was thinking is if someone is connected, a message stating to call back later could be put in.

UPDATE:

During the last week I've successfully ported all of the existing core functions of ContikiBBS to process code and am happy to tell you that all of them are working very well! Only a few things are missing (e.g. the login procedure) and I've also rewritten the setup program from scratch. Due to the changes in the program structure and with better portability in mind, the upcoming 2.5 version will not look as nifty on your local C64 screen as the last one. Still, the remote shell will be much better than the old one. Stay tuned...

_________________
LOAD ":*",8,1
READY.
RUN

Good news, everyone!

To all of you who want to take a first look at the upcoming ContikiBBS 0.2.5 release, you can now try the online preview on my webserver. The full sourcecode and a D64 image containing a ready to run distribution of ContikiBBS will be made available shortly (I just need to cleanup some code, add comments etc.). Until then feel free to visit the infamous Birdbrain BBS, now running ContikiBBS 0.2.5beta (might still have minor bugs or errant behaviour - feel free to test intensely but report here if it gets broken ).

New features include:

* Completely rewritten codebase, now utilizing ContikiOS processes (thanks to Oliver Schmidt)
* New, easy to use setup program
* Login timeout and session timeout values configurable (through setup program)
* Now with PETSCII conversion (no more UPPERCASE input and output)
* New look-and-feel of the BBS shell

Curious? Just telnet to:

telnet://wintermute.homeunix.com, Port: 64
username: guest
password: guest

_________________
LOAD ":*",8,1
READY.
RUN

Fantasic look forward to setting up a telnet bbs along side c64web.com
lets give it a go.
Logged on using Telnet on my debian box, it worked great.
left a msg and read msg logged out fine.

What hardware are you using.

Thanks
Shane.

_________________
Have Fun!!

Good to hear it works. Well at the moment ContikiBBS is running in a VICE emulator which, in turn, runs on an Ubuntu Linux 11.04 server (PC Engines ALIX.1D mini itx board w/ 800MHz AMD Geode, 256MB RAM, 8GB CF Card, power consumption: ~ 7W) I also use as webserver. But of course the software works fine with a real C64 as well.

BTW: had to set up the D64 image again on the server, so don't wonder if your message is lost ... sorry for that.

_________________
LOAD ":*",8,1
READY.
RUN

I'll set up c64bbs.com with real Commodore hardware on the standard telnet port 23, If you like send me a D64 ready to go and i will run it on there 24/7.

Thanks.
Shane

_________________
Have Fun!!

Great progress!

I think I managed to crash the server though. I think after i typed read 1 at the prompt

Thanks a lot! Well, this is the reason it's still a beta release. I think after a certain amount of time the Program dies. Maybe it's something with the timers - I've put up a timer-less version today and see if that keeps the BBS running for more than just a few hours. Anyway, thanks for reporting and don't worry if you break it. Helps me iron out the bumps.

EDIT: for the next 48 hours (this weekend), the online demo runs on a *real* C64, so if you want to leave a few nibbles on a real 5.25" floppy disk, feel free to visit!

EDIT 2: Well, after 72 Hours of "online testing" with a real C64, I was able to point out a few *very* disturbung bugs regading the timers. Somehow, these cause the machine to crash after one or two hours. So if you couldn't reach the BBS it was because of that. Still working on a solution, in the meantime I've put up a timerless version of the program. Remember to "exit" the BBS and not just close the terminal window. Otherwise others will be locked out forever (or until I notice ... )

_________________
LOAD ":*",8,1
READY.
RUN

ContikiBBS 0.2.5 released!

Yes, it is finally here: the new version of ContikiBBS (told you it's coming before Duke Nukem forever! ). Special thanks to Oliver Schmidt of Contikiprojects for fixing some issues within ContikiOS. Without your help 0.2.5 wouldn't be here today!

New features include:

* Completely rewritten codebase, now utilizing ContikiOS processes (thanks to Oliver Schmidt)
* New, easy to use setup program
* Login timeout and session timeout values configurable (through setup program)
* Configurable shell prompt (through setup program)
* Now with PETSCII conversion (no more UPPERCASE input and output)
* New look-and-feel of the BBS shell

Download here: http://retrohackers.com/viewtopic.php?f=10&t=571

Want to visit the online demo? Just telnet to:

telnet://wintermute.homeunix.com:64

username: guest
password: guest

_________________
LOAD ":*",8,1
READY.
RUN

Hi,

Thanks Actually it's a pleasue to collaborate with you

I'm looking forward to include the second Contiki retrocomputing program developed my a community member into the Contiki 2.5 ...

Regards,
Oliver

That's mutual



Now, mistrmsk commented on it so here is something I want to tell you about the "getting it threaded" part of ContikiBBS. As you might have seen, the new version already makes use of multiple processes and simple process switching (login -> shell -> login). Then why can't the BBS come up with a "busy" message rather than hang up on the incoming connection? Well, there is a difference in the way a 'classic' BBS (using modems or serial lines) works and how ContikiBBS (using TCP/IP) works:

A 'classic' BBS can always identify which user is coming in through what line, since each modem is connected to its own serial interface. So user#1 is coming in through line#1 and user#2 threough line#2. Just use that info and you can implement a simple session handler, right?

As for 'modern' BBSes: on a Linux / UNIX system (using threads) for example, a telnet server opens a seperate session thread for each incoming telnet connection. The sessions are provided by threading the telnet server. So once again, there are concurrent sessions and the software can identify each user by their /dev/pty#, or /dev/tty#.

The telnet server Contiki provides (and ContikiBBS makes use of) does not do such a thing. It runs one session and that is provided to all incoming connections. So if you connect to the original (Contiki) telnet server and someone else is already logged in, both of you share the same session. If user#1 types a command, user#1 *and* user#2 will see the output of it. And if user#2 runs a command, user#1 will receive its output too. So as a result, if I would just add a neat little the person that is already logged in will also receive the message. It's somewhat disturbing, I think, so this is the plain simple reason why ContikBBS acts rather rude when it's busy.

I will not make the same mistake twice, stating that making it work a different way is impossible since the Contiki webserver is already threaded. But it is impossible for me to get that job done. If someone feels like it, they're welcome to have a look at the webserver code and use that as a basis for a new, fully threaded telnet server. Still, I wonder how much memory will be left on a C64 or Apple ][ for real BBS processes once such a server is finished. Again: I'd be the first person who would adapt to such a codebase if it exsisted. Currently, it does not and I just don't have the skills to do it - so I stick to what is possible at the moment. Even if that includes "rude behaviour"

Also on my whish list for the interested developer is a simple compression algorithm, which could improve the amount of text that can be stored per posting. If you just finisehd writing such a masterpiece in C and want to share it, feel free to do so. I'll be happy to use it!

_________________
LOAD ":*",8,1
READY.
RUN

Hi,

Here's my take on the topic from the Contiki-inside-out perspective...

uIP and thus Contiki process frames coming from the network in a callback fashion. Everytime a new connection is opened / accepted, the Contiki application can attach a "user pointer" to the internal datastructures. On every subsequent callback the application can use that pointer to distinguish connections and/or access the appropriate application datastructures. This is a very usual approach for any type of callback driven framework.

The Telnet server however stores all it's state in a global structure and doesn't make use of the "user pointer" at all. Therefore all network I/O got intermixed (as logder described) - after all the whole behaviour was sort of undefined. Therefore I added some code that rejects additional connections in order to archive a consistent beaviour.

Why is the code the way it is? The Telnet server is - once more - just a proof-of-concept hacked up from Adam long ago. It is only used to allow for remote cmdline access to network sensors for testing purposes.

So what is to be done? Have an array of the global structure holding the Telnet state. However the structure is quite large. It contains i.e. a full screen buffer. Therefore I proposed to lodger that he adds all "necessary" features to ContikiBBS and we looks afterwards where we are regarding RAM usage. If there's enough RAM left (and if questions regarding parallel access to files etc. are solved i.e. by using locks) then I'll modify the Telnet server as described above.

All this is basically unrelated to the use of processes and/or threads. It's just about removing a flaw from the Telnet server and about RAM usage.

Regards,
Oliver

Feel-good thread of the new millennium. Great work guys, I'm impressed and really looking forward to trying this out (won't be for a couple of months, sadly).

My 5 cents: I haven't looked into the source but I assume it must be possible to write a simple session-handler that gets called each time there's an incoming connection instead of launching the telnet-server directly. In this case, since I assume we're talking single-user mode, all the session-handler needs to do is counting the number of launched telnet-servers (1). If the number is zero then launch a telnet-server process. If it's '1' then just write the busy message and disconnect the incoming connection. This also assumes there's a way for the session-handler to know when a telnet-server process has been terminated of course.