Hi,

Sometimes assumptions are false

There's nothing between the core TCP/IP code and the Telnet server. And I assume that you don't want to add some string output code right into the TCP/IP stack, do you?

The way to implement your idea would be to have the Telnet server not rely on its internal state right from the start of a connection but allow him to "just" push out the busy message and disconnect without touching its internal state.

The primary reason why I haven't looked into this so far is that I consider multiple users as THE cool feature, i.e. allowing for real time chat between the users. Multiple users is btw. the feature that showcases why one wants to go with Telnet right into the C64 instead of terminating converting it to some serial protocol in a frontend - because Telnet gives you multiplexing over TCP.

If however the design goal of a BBS is single user than things are different - I'm just not a BBS guy enough to know...

Regards,
Oliver

Well, it would be extremely cool to have a multi user BBS at some point in time. When I started with ContikiBBS, I didn't know how a BBS is coded - in fact at that time I hadn't done C coding for quite a while and so I decided to take the easiest approach possible. The whole thing is a hobby, a serious hobby maybe, but still something I do for fun.

But this does not mean that the design goal can't change. In fact, except for a proper locking mechanism regarding file access, most of the code would probably fit quite well into a multi user server. And realtime chat is a feature that I find quite interesting, as would be the possibility of creating a small, multi player online game that is part of the BBS.

My personal point of view was (and still is) that I want to implement a basic set of functions / commands for the BBS first, so people have something they can "play" with. Later I can think of all the cool features like multi-user etc. These features require collaboration with other developers and changes in the Contiki codebase will have to be made. If Oliver decides to have a look at it, I'll be honored and ready to help him. But I will not demand or request such a change since it's quite complex and probably very time consuming.

As for the memory part: one irrevocable claim is that ContikiBBS should always run on a "stock" C64 with a disk drive, so that anyone can use it without the need for a SuperCPU, IDE64 or REU memory. ContikiBBS 0.2.5 uses 142 blocks on a 5.25" disk, so the binary size is about 36K. Add another 2K for buffers, variables and other runtime data, so you will probably have around 40K of memory being used during runtime. On a C64 there will be less 20K left for other processes. So even if you make the server mutli user, the number of concurrent sessions will be limited due to the speed of the 6502 CPU and the amount of memory left.

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

Hi,
I see. All that makes perfect sense to me. However it means that the final memory consumption of ContikiBBS is something that won't be clarified anytime soon.
Full ACK.
You are certainly right. Even if we'll go one day for multi-user with n concurrent connections we'll still have the scenario of the n+1st user trying to connect. Form that perspective the need for a more graceful handling of excess connection requests is always useful/desirable.

Therefore I went ahead and added it today. Now addional connections are accepted. A (customizable) message is sent to the client and after a few seconds (to give the user time to read the message) the connection is gracefully closed. I just pushed the update to the Git master.

Regards,
Oliver

If we were to take a shot in the dark, how many concurrent connections are we talking about, just a soft figure. 4 - 6 ?

It's great to see how far this project has gone. Is a txt based game out of the question for you BBS. ?

I remember playing usurper and red lord on the bbs.

Keep up the great work. I'm hoping to set it up on the Chameleon today.

Shane.

_________________
Have Fun!!

I think that handling the network traffic and console i/o for 2-3 simultaneous users or more will not be a problem, the deal breaker is disk access. Unless it can be done asynchronous (using an IRQ loader) but that would probably require severe Contiki surgery.

Pulled the changes, re-compiled the online demo: works perfectly! So now there's a short 'busy' message when someone is already logged in. Thanks a lot, Oliver!

As for the text based game: it's still on my mind but I've got to get the file I/O functions platform independent first and I also want to implement a 'text-banner' function (reading text files from disk and displaying them on the terminal). So, don't expect too much regarding multi-user capability for the coming releases. But hey, there must be something left to do for the future 1.x releases, right?!

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

Hi,

Some concrete numbers...

The ld65 linker map file tells us that the currently the upper memory limit is at $AAAE. To that we need to add the $200 reserved for the stack and the $1D4 for the ethernet driver loaded dynamically onto the heap (the latter number comes from the map file of the driver module). Our upper memory limit is $C000 so we have theoretically $117E bytes free.

If we tune the Contiki compile time options towards low memory usage (turning off logging, turning off the delayed ACK workaround, reducing the MTU from 1500 to 500) we end up with a memory limit of $9DC8 resulting in $1E64 bytes free.

As cc65 programs have way less memory on the Atari than on the C64 I introduced the option to save some more memory by linking the ethernet driver statically. The doesn't only omit the module loader but also the heap manager as the module loader is the only heap user in Contiki. On the Atari this makes perfect sense as there's only a single CS8900A based Ethernet solution. On the C64 however this means to lock out the ETH64 Ethernet solution. Certainly one could offer two variants of a statically linked binary - but I personally think this is unsexy and therefore classify it as last resort only. Anyway - the numbers are a memory limit (incl. driver) of $9963 giving $249D bytes free.

Apart from that we could surely find another few hundred bytes by i.e. optimizing the actual ContikiBBS source for low memory usage.

Now to the costs of multi session support in the Telnet server...

The Telnet session state consist (beside some small variables) out of a line buffer and a screen buffer. Currently the Telnet server is configured for an 80x25 screen so the buffers are 2080 bytes. However from looking at the Contiki BBS source it seems that it targets a 40 column wide screen as most likely we can reduce the columns in the Telnet server too. Then the buffers would be 1040 bytes - so let's say 1050 bytes incl. those addional small variables for every session.

Additionally the Telnet server code size will increase because every access to the session state now needs a pointer dereference or an array subscript. This stuff isn't as easy as it may seem so I presume a code increase of several hundred bytes for multi session support - obviously regardless of the actual number of sessions.

So that's what I can provide to the discussion. Please note that I have no idea on how much the actual ContikiBBS code would increase for multi session support!

Have fun,
Oliver

Great numbers there, Oliver. Just some input: There is no need for the server to buffer the entire screen, is there? At least the nature of classic BBS software is line based and in the case of "full screen application" it's really up to the client to buffer the screen any way, not the server. So throw away the screen buffers and save a lot of space!

Hi,

Full ACK. Just look how the webserver performs with multiple simultanious HTTP sessions when running it in VICE with "Turbo Disk" but authentic CPU speed.

Yeah, the ordinary (I think "Kernal-based" is the proper term) disk I/O isn't actually that fast on the C64 - isn't it

Some background info on disk I/O in Contiki...

All Contiki-internal disk I/O uses the CFS (Contiki File System) API. Loading the contiki.cfg TCPI/IP config file is an example of Contiki-internal disk I/O. Apart from that all Contiki sample applications doing disk I/O use the CFS. Examples are the webserver and the wget client.

This CFS API doc is somewhat old but still relevant.

The Contiki codebase contains several implementations of the CFS API. Some of them are targeted towards embedded systems using Flash memory. One is a simple wrapper around the standard POSIX API - this is the default for cc65 based Contiki targets. And there are even two specific for cc65 targets:

1) On the Apple II the cc65 C library implementation of the POSIX API needs to have quite some overhead. Therefore there's a minimal (aka small) CFS implementation bypassing the cc65 C library allowing just enough functionality to read the config file and Ethernet driver on startup.

2) On the C64 soci contributed a CFS implementation that uses proprietary IDE64 calls if an IDE64 device is found - and uses the standard Kernal calls otherwise. Because it bypasses the cc65 C library in both cases the resulting binary is smaller than with the default POSIX-based CFS implementation. So the IDE64 support comes "for more than free". Therefore soci's CFS implementation ist used for all C64 Contiki binaries I deliver - even those which don't benefit from the IDE64 support because they just load the config file and the Ethernet driver.

Regarding Ethernet driver loading: The cc65 low level module loader fortunately allows to supply a custom read() function as callback. In the Contiki framework I built for Ethernet driver loading (and cc65-stock-mouse-driver loading) I leverage that feature by setting the CFS read() function as custom read function. This way even the file reading code inside the cc65 C library doesn't necessarily use the cc65 C library POSIX calls but rather whatever CFS implementation is activated at build time

Now back to the statement above: I don't understand what you exactly mean with "asynchronous" here. Maybe you could elaborate.

And it should probably be noted that the actual ContikiBBS code doesn't use the CFS API but rather uses cbm_... functions from the cc65 C library because it works with REL files.

Regards,
Oliver

Hi,

I'm pretty sure that this buffer has nothing to do with the semantics of the application running on top of the Telnet server but rather with implementing the Telnet protocol itself correctly over the "fully unbuffered" uIP TCP/IP core. I sort of remember that the buffer wasn't there in the first Telnet server implementation - which turned out to not work correctly - and was added later by Adam in order to fix that.

If you however feel that it is superfluous you're welcome to remove it and prove that you're right - after all Contiki is open and looking for community support

Regards,
Oliver

Oliver made a few suggestions to me regarding memory and how to save some bytes. Unfortunately, after implementing these hacks, I've now got some annoying side-effects that prevent ContikiBBS from working properly. In fact, you won't even be able to log in as the program now seems to fetch empty records. But I'm quite positive that we will find a solution for this issue soon. I'm currently analysing different possible causes of these effects.

Reading the posts above, I am curious now. Are you really thinking of getting the telnetd multi-user, Oliver?! Not that I would object to such a thing...
Despite memory, file locking is an issue, when going multi-user. The easiest way to do so would be to block acces to the post and read command as long as someone is composing or reading a new message. Well, at least that's what comes to my mind as a quick hack. And then there is the problem of Commodore hardware not supporting ioseek() due to its design. So I use REL files and the 256 byte limit that comes with it (unless I want to write my own filesystem for the BBS). I'm really not too happy with the 240 characters-per-post limit. But since I never owned an Apple ][ or Atari machine, I can't say if similar limits may exist on these platforms as well. On a modern PC system it would be rather easy to make use of endless pages of text. All of this can be dealt with in a way, I guess. Come 2112 we may even have zmodem file transfer - just kidding!

Well, there is another thing I'd like to say: I'm very thankful for your suggestions, comments and support - all of you. When I started this project, after reading this thread, I didn't expect that much feedback. Especially with the very, er, "custom" code the two earlier versions were based on. Now many technical glitches have been ironed out (mostly due to Oliver providing the neccessary changes in Contiki) and there's a solid code base to build upon. I'm really curious if some of the ideas we discuss at the moment will turn real sometime.

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

Hi,

Certainly I do Maybe I'm overlooking a general roadblock and it turns out as not feasable but as I said the whole handling-TCP/IP-actually-inside-the-C64-although-it-uses-most-memory story starts to get really sexy with multiple connections.

Regards,
Oliver

Very cool, lots of possibilities.

Not meaning to derail the thread too much, but I'd love to see a way to telnet into a 64 and get access to BASIC. ASCII/PETSCII would be a pain, and multiuser wouldn't really work, but still cool to try it. I actually played around with REMOTE 64 [1] from Transactor a while back with a PC doing the bridging and it worked pretty well. Now I am hoping ContikiBBS will be a way to do it with the RR-Net

[1] http://www.csbruce.com/~csbruce/cbm/transactor/v6/i2/

Hi,

I've been thinking about the same for the Apple II several times. On that machine - without timer interrupt - the primary question is "who has control when".

Unfortunately I don't know enough about the C64 to actually judge where the issues are here. But given the existence of a timer interrupt it seems generally feasable - I'd guess it's primary a question of how much one will be able to do with the BASIC - depending on how much memory is left.

Although I'm certainly known as Contiki evangelist I'd try for something smaller here to be less intrusive with regards to the memory layout. However the usual suspect IP65 (not even talking about non-upgradable hardware like the recently discussed WIZnet stuff) has the downside of missing IPv6 support. I'm pretty sure that we will ask for that sooner than we think now. So if there would be a bounty for BASIC-over-Telnet my first try would most likely be to extract the current uIP from Contiki.

In a one-application-only (here: Telnet), one-session-only scenario with very specific requirements (here: cooperation with BASIC) pure oldschool uIP might be preferable to Contiki. However it's important to go for the current uIP that resides in the Contiki codebase and retrofit that to standalone usage. There are tons of bugfixes and improvements in the current uIP - and IPv6.

Yet another great opportunity for a community member

Regards,
Oliver

How soon?

I've thought a few times about adding ipv6 but never really stuck at it beyond a cursory glance at the RFCs. It just seems too remote. I can see the odd private home network being ipv6 but until home internet connections are ipv6, and you can put up a public ipv6 service with a reasonable confidence that everyone will be able to get to it, it doesn't seem worth it.

Happy to be corrected though!