Im Writing a Telnet Server - Access is so tempting!

Hey Guys,

I wrote a Telnet server quite a while ago (about 1 and a half years ago), and it was (and still) is pretty damn good. I started building a whole new version of the telnet server about 7 months ago, and I stopped (I got bored).

I was just looking at it today and thought 'Christ this has potential' - I mean it’s almost finished, it just needs cleaning up (I don’t know why I stopped writing it in fact, its sooo close to completion). Anyway all of the user accounts etc. are stored in INI files - I didn’t know much about DBs back then.

Anyhow, I think it would be an excellent idea to convert it all into an Access DB - as it would be so much faster and more efficient. However, the main con is that not everyone has Access, so it will mean that some people won’t be able to use the server. Do you think that all of the Pros out-weigh this big Con, or not?

I mean at the moment, with it running off of INI files, the whole application is stand-alone; it has no Software dependencies. But if I introduce Databases, the server will require Access in order to run :-(

What do you think? Keep the INIs, or convert it to Access and accept the fact that it will have fewer users?

(p.s. Im making it freeware)

I'm confused about the relationship between a telnet server and Access. To me there isn't any relationship between them. Unless you are not using the actual windows user accounts for telnet login.

If you do not mind insisting on MDAC, you can certainly use an access mdb file from VB via ADO without needing Access itself on the machine.

The telnet server does not use Windows user accounts - it works on its own level of security, and all of the accounts and account privileges are stored in INI files. That's what makes the server so different, it doesn’t need you to setup lots of Windows accounts for all of your users, as all of the accounts are setup inside the server (so it actually requires less system resources). It’s pretty much like a remote OS (except for the fact that the server runs on Windows); I suppose you could say that it creates its own little environment. It’s a shell account server more than anything, so the idea is that lots of accounts can be setup with very little effort, and it can handle lots of simultaneous sessions.

Access comes into this because I am thinking of storing the user accounts, and other information inside databases… But thanks, I never knew that they don’t need access in order to use ADO; I will give it a go

as far as I know, they do need Access drivers to be installed and such drivers come
with Windows anyway (IE or Outlook, not sure) so you don't have to worry about it.
however note that Access is very poor when it come to lots of requests in the same
time: so in my opinion it's not fit for your case. you can use Text File Driver, and work
with text files as though they were database.

(I'm not sure the Text Driver is more stable than Access, but at least it means
less complicated code for you and less changes in the code)

I don't know why Shadow would recommend against and access db in favor of a text file, but each to his own I guess

MS has a redistributable MDAC if you don't want to rely on every machine having the proper ado drivers, you can get it from www.microsoft.com/data and you can integrate the mdac installation within most installers so the user will automatically check/install the correct mdac version as part of your program's setup.

I have a couple questions, one is would be how you protect the login information, if someone gained access to the computer a text file would be very insecure and an access db only somewhat better, and two is how do you map your telnet users to windows user accounts for file permissions, etc. Just curious.

It’s hard to explain - but just think of it as an entirely separate OS from windows. The CLI (command line interface) is structured in a way that resembles a DOS/VB hybrid – I love it!


Basically there are 4 separate user levels, which are:

-Guest (they can do bugger all)

-Standard (Can access their own folder, and all of its subfolders - they don’t have any access to possibly harmful commands)

-Service Admin (They can access all of the user accounts within their domain - explained later. And they have access to more powerful commands like kicking users, modify accounts, etc)

-System Admin (There should only really be 1. They can do anything, and they don’t have a root folder unlike the other 3 accounts, they can explore the whole PC).


With DataNet (the telnet server) you can have multiple 'domains' (they are not actually domains, this is just what I call them). Each domain can be fully customised (you can enable/disable certain commands in each domain, create startup scripts, etc); you can completely customise each individual domain. When a user connects to the server, they are asked which domain they want to login to. EG you could have a 'communications' domain, which has the sole purpose of communication between users (for example, you could just enable commands that are related to communication, like the Chatroom command). You could customise that domain even further by making it boot up into a chatroom when a user logs into it - thus making the domain more of a chatroom channel. Each domain has its own separate user accounts, and these are what the folders are Structured like...

Let's say DataNet (the telnet server) was installed here:
C:\DataNet

And let’s say you created 2 domains, 1 called 'TestA' and the other called 'TestB'. They would be located here...
C:\DataNet\Domains\TestA
C:\DataNet\Domains\TestB
The above paths would also be the root folders for the 'Service Admins' of each domain. The service admins are there to administrate their own domains, and cannot go out of their root folders (duh).

Now, let’s say we have a user called 'Steve' that belonged to the 'TestA' domain; his root folder would be here:
C:\DataNet\Domains\TestA\Users\Steve

As far as extended file permissions goes, there's just the bog-standard 4 (Archive, Read Only, Hidden and System) - the server is designed to be more of a shell account server - that is why it is structured in the way it is. It’s a very adaptable bit of software, because the 'command library' (as I call it) is run on plugin-DLLs, so the more advanced guys like you lot can actually write your own commands for the server.

That probably makes BUGGER ALL sense, but it took a while to write, so even if you don’t get it, just humour me ok? lol

I recommend against Access because I see too many problems with
that database when used in web applications - and here it's quite
similar environment as far as I understand.
sounds like pretty complex system there, Loz... question is if Steve
can access the computer, what prevents him from opening the text
files (or database) and getting access to all the sensitive information?

Because Steve's root folder is:
C:\DataNet\Domains\TestA\Users\Steve

And he cannot come out of it. He can obviously make his own subfolders, and go into them, but he cannot stray out of his root folder. Its the same for the Service Admin - they cannot come out of their domain's root folder (the domain is their root folder because it allows them to go inside other user's folders from their domain, like the TestA Serivce Admin could access Steves files). PLUS all of the commands that have the potential to be malicious are disabled from the Standard Account (like process management - in fact, even Service Admin cant use that command, only the system admin can!).

I agree its a complex system when it comes down to writing it, but its just so easy to use - you should see some of the data processing techniques I use for inbound and outbound data. Because you can’t do multi-threading in VB (well you can, but its very hard!) I made 2 completely separate ActiveX EXE files that manage all of the inbound and outbound traffic; this means that they run on completely different processes from the server itself. After much tweaking I made the server immune to flooding!!!

but what if Steve has direct access to the computer where the telnet
server is running? or not Steve, just some other person? how the files
on the server are protected?

by the way, when you first did that was it just for fun, or did you get
it as assignment or something like that?

I see what you mean now Shadow, and the answer is that there is no level of security on the server itself (at the moment anyway), someone could walk up to it with a USB stick and steal all of the account data etc.

But to be honest, think about shared webservers. Some disgruntled security gaurd could come up to your webserver and steal all of your ASP files, couldn't they? Eitherway I am going to secure it a bit more from the server's end - so apart form Password Protection on the MDB file, anyone got any other ideas?

lol - If anyone has access to the server with bad intentions, then the telnet server is least of your worries - they could hit the thing with a sledge hammer if the wanted to!

ok, fair enough...

so what you say is that you need the database only on the server? if so, anyone will
be able to use your system, even if he does not have any drivers for Access database.
just like you don't need anything installed on your computer when you browse to
websites that are using database.