It is currently Fri Oct 31, 2014 7:31 am

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 100 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next
Author Message
 Post subject: Re: Status Update!
PostPosted: Thu Apr 14, 2011 7:30 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 845
lodger wrote:
Don't worry, though: the next version of ContikiBBS will be released long before "Duke Nuke'em Forever" hits the shelves! I promise!


:lol:


Top
 Profile  
 
PostPosted: Fri Apr 15, 2011 10:26 pm 
Offline
User avatar

Joined: Mon Jun 15, 2009 6:55 pm
Posts: 79
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.


Top
 Profile  
 
PostPosted: Tue Apr 19, 2011 11:09 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
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


Top
 Profile  
 
PostPosted: Fri May 06, 2011 11:44 am 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
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


Last edited by lodger on Fri May 06, 2011 7:05 pm, edited 4 times in total.

Top
 Profile  
 
PostPosted: Fri May 06, 2011 1:59 pm 
Offline
User avatar

Joined: Sat Feb 10, 2007 7:30 pm
Posts: 338
Location: Brisbane Australia
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.

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.


Top
 Profile  
 
PostPosted: Fri May 06, 2011 5:43 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
zap wrote:
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.


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


Top
 Profile  
 
PostPosted: Sat May 07, 2011 2:46 am 
Offline
User avatar

Joined: Sat Feb 10, 2007 7:30 pm
Posts: 338
Location: Brisbane Australia
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

_________________
Commodore 8bit Web Services http://cbm8bit.com
Try our new browser driven disk image editor.


Top
 Profile  
 
PostPosted: Sat May 07, 2011 5:51 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 845
Great progress!

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

:)


Top
 Profile  
 
PostPosted: Sat May 07, 2011 10:56 am 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
RaveGuru wrote:
Great progress!

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

:)


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


Top
 Profile  
 
PostPosted: Fri May 13, 2011 12:35 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
ContikiBBS 0.2.5 released!

Yes, it is finally here: the new version of ContikiBBS (told you it's coming before Duke Nukem forever! :D ). 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


Top
 Profile  
 
PostPosted: Wed May 18, 2011 1:11 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 69
Hi,

lodger wrote:
Special thanks to Oliver Schmidt of Contikiprojects for fixing some issues within ContikiOS. Without your help 0.2.5 wouldn't be here today!
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


Top
 Profile  
 
PostPosted: Thu May 19, 2011 8:56 pm 
Offline

Joined: Thu May 17, 2007 3:00 pm
Posts: 72
Location: Duesseldorf, Germany
Oliver wrote:
Hi,

lodger wrote:
Special thanks to Oliver Schmidt of Contikiprojects for fixing some issues within ContikiOS. Without your help 0.2.5 wouldn't be here today!
Thanks :) Actually it's a pleasue to collaborate with you :!:


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
Code:
shell_output_str(&shell_process, "bbs is busy\n", "");
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


Top
 Profile  
 
PostPosted: Thu May 19, 2011 10:43 pm 
Offline

Joined: Wed Dec 05, 2007 2:15 am
Posts: 69
Hi,

lodger wrote:
:!: 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" ;)
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


Top
 Profile  
 
PostPosted: Thu May 19, 2011 11:10 pm 
Offline
User avatar

Joined: Mon Feb 13, 2006 7:44 pm
Posts: 211
Location: Toronto, Canada
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).


Top
 Profile  
 
PostPosted: Fri May 20, 2011 7:12 am 
Offline
Site Admin

Joined: Wed Jan 11, 2006 12:22 pm
Posts: 845
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 100 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6, 7  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group