Another significant change is the addition of the EventManager class. This holds a dictionary of events that can be called, and is inherited from the Entity class. Rather than expose event objects as public members, the EventManager class does many things. First, it allows for cleaner code; rather than exposing the event object in the public scope of a class so that anything can access it, the manager imposes some protection. The manager also allows for easier inheritance and access of events by name, rather than by objects.

Another crucial feature are some helper functions, for serializing code that were added. Rather than serialize dictionaries multiple times in the same function, you are able to use some of these functions (found in utils.h), to do the serialization for you. This both eliminates more code, and saves from having to track down bugs as much. Rather than risk doing something wrong in a deserialization or serialization, you can call the functions that have been tested and use the same code.

With those three improvements in place, the development of Aspen has sped up considerably. The next couple big projects on the to-do list consist of adding scripting to objects, and working on help, editing and olc. As always, contributions are always welcome, and stay tuned for more updates.

The client will begin the negotiation by sending an auth command, providing the user’s username as an argument. After this is done, the server will search through the list of keys in order to find the user’s public key. If no key was found, the server will reject the user and block the connecting address for a set amount of time. If the user’s key was found, the server will generate a 512 bit string, which it will encrypt using its private key, and the user’s public key. The block of encrypted text will be sent to the client, which will decrypt in reverse (by applying first the client’s private key, then the server’s public key. The user will then send the unencrypted text back to the server to complete step 1 of the authorization process. If step 1 fails, the server will disconnect the client and block for a set amount of time. If the string successfully compared to the generated string, the server will proceed to step 2.

Step 2 will negotiate a salt to be used in encryption of data to and from the client, and leaves two options. The server can either negotiate a one-way salt for the stream from the server to the client. The client would then negotiate a salt that would be used for data from the client to the server. The last option would be to let the server negotiate the salt for the full stream, and use one single salt for encryption.
The salt will be negotiated using an Authentication Protocol, which will be either SRP, or EAP.

After the encryption salt is confirmed, both client and server will switch to this for encryption of streams. Further commands both to and from the server will be encrypted. Text may also be compressed, which will be negotiated after step 2 has taken place. The client can either choose to enable or disable compression, which will force the server to flush it’s buffer for that client (when possible), and send a confirmation. After receiving the confirmation message, the data will be assumed to be in it’s reverse state.

Private interaction between users (either for sending of the hashfile, or actual files will also be encrypted. The clients will negotiate a salt for encrypting using the authentication protocol, which was used in step 2.

I am open for ideas, mainly to improve security, and make this a stronger setup.

Edit:

A couple of major changes. First, the server won’t actually kick until after step1, and will try to use the same amount of time, whether or not step 1 failed. This makes an attacker guess more, without telling them that user failed and letting them work at that before going on to step 2.

Secondly, two sets of keys will be used, and the data won’t be sent back unencrypted. While highly unlikely that an attacker could crack the text, we’re giving them both encrypted and unencrypted data. So they would have to broot-force two pairs of keys, and use those to sign the unencrypted text and compare to the spoofed keys. As a result, each transaction will use two sets of keys. Both the client and server will have a key-pair (private and public), which will be used for signing and encryption.

So, we keep going through the circle. “I can’t help you until I have a serial number.” “Mam, I am blind; this means that I have *no* sight, and can’t peak at the bottom of my computer for the numbers.”

At one point, I got frustrated and made the comment, “Excuse me while I go pop a new set of eyes in so I can read this number for you.” She responded, “OK,” and patiently waited, for what I’m not sure. I guess she thought that I was actually going to go pop in a set of eyes.

Eventually our tech support agent says, “If you are blind, how do you expect me to believe you can use a computer?”

I wouldn’t have minded if she was asking to know, But the tone and the attitude behind how she said what she said was condescending. By this time, I was getting a bit heated. I promptly asked if she had access to Google, and told her to search for “screen reader.” First result is our trusty Wikipedia, which she spent several long minutes reading. After this, she tries to play it off with, “will you please hold, while I check on something for you?” Seems she still wouldn’t give me information about the recovery disk, but the event was amusing, all the same. I would’ve loved to pop in my eyes and catch her reaction at the end, anyway.

Taking the latter option is most of the time the quickest, but leads to more problems later as development on the system grows. Not only do coders have to contend with currently-running modules, but they either have to work around, or work with the modules that are no-longer needed. The end-solution is that more than one module will end up in existence to perform the same task, but only one is needed.

Aspen solves this problem by allowing for a modular approach; coders and users can easily install a module in five quick steps. If you have obtained your module from somewhere else, you should unextract it in the src directory. This should create a directory with the module name, which contains at least three files. The first file will be called ‘include.mod’, and this is where a list of files to be compiled is. The second and third should contain a source file, and a header file for the main module. More source and header files are often seen in larger modules.

If you are creating a module for the first time, you will need to set up these three files by hand. The include.mod file looks something like:

S_FILES += MyModule/MyModule.cpp MyModule/file1.cpp MyModule/file2.cpp…

Please be aware, you will need to use the module directory name in the path. This allows the top-level Makefile to change to that directory and compile the files you specified. Next you need a main source file (MyModule.cpp), and a header file of the same name. In the header file, you should include ‘../mud.h’ and ‘../conf.h’ and also define an initialization function, as well as anything else that belongs in that header. Within the source file, you should define the initialization function. This function is what will be called when the mud boots up, and your module is loaded. Please be sure to log the fact that your module was loaded, so that it will be shown in the system log, and things can be debugged easier.

Next, we will add our module to the mud, which is the same whether or not you have installed a third-party module, or your own. Navigate to the file called ‘Makefile’ in the main directory, and under the modules list add the name of your module. This should be the name of the directory your module is found in, not the name it’s self. This done, you will need to add a define near the bottom of ‘conf.h’. This define will tell the mud whether or not to load your module.

If you have a module called MyModule, your define may look something like:

#define MODULE_MY_MODULE

Please be sure to include the ‘MODULE_’ prefix, to avoid define conflicts.

Lastly, we add the module load line, which will be executed when the mud starts up. In module.h, add something like the following:

#ifdef MODULE_MY_MODULE
#include “MyModule/MyModule.h”
#endif

In module.cpp, you will need to add the load function like so:

#ifdef MODULE_MY_MODULE
InitializeMyModule();
#endif

Please note, this should be in the initialization function, along with the other modules.

Adding modules is a quick and easy process, compared to adding code to other systems. While some of your code may need to alter or add to the core of the mud, you’ll find that for the most part you can add modules to accomplish your task. This allows for easy debugging, and also allows you to eliminate huge code setups where multiple systems are tangled together.

While it is possible to allow for dependencies on other modules, please make sure that your modules don’t rely entirely on each other, unless one module is part of another. While this is sometimes hard, allowing for your modules to become tangled together also defeats the main intent on the modules to begin with.

For those in the VI community, Linode offers many features that most companies do not. While they have a custom control panel, they have worked to make it fully accessible to someone using Voiceover, Jaws, Window Eyes, or any other screen reader. They also provide many more key features, which I will be discussing in this article.

Lish is one of Linode’s key features. Using the Lish either over a SSH connection, or through their website, you are able to log in to your server and easily manage it, whether or not it has a network connection. This is extremely useful in situations where you are configuring networking or tweaking it, and you lock yourself out of SSH, or disable the network card entirely.

In this article, I will be going over the installation of a Linode via the Linode control panel using jaws. Starting from http://members.linode.com, I have already logged in and am currently on the front page, the title of which is “Linode – Linode Manager.” Arrowing down from the top of the page, you see a link called “Linode Manager,” which is just a link back to where you’re at, and then a greeting which tells you which account you’re logged in under. After the greeting, you will see a link to take you to your profile, and a link that allows you to log out of the current account. Beyond that, is a list which contains general links, a link to your Linodes, your DNS manager, account information and support. After the list comes a link to add a Linode to the account, and a table if you already have a Linode.

Each account can hold multiple servers, which allows you to create clusters if you wish, or use each server standalone. Within this table is a list of servers belonging to the account. As you enter the table, the heading looks something like, “Linode, status, plan, IP Address, Location, Host, Remove, and Edit.” Using your table navigation functions, you can easily navigate by column. Starting from the left, you see a rename and then a set of numbers which tells you which Linode you have. The rename function allows you to give it a better name, such as mail server, IRC server, etc, for easier identification. The status basically tells you if it’s running, powered off, or rebooting. Arrowing over, the plan tells you what Linode plan your running, the specifics of which can be found on Linode’s home page. Next comes the IP address, which you get when you sign up. Unlike some VPS systems, you get your own IP address, which allows you to open any ports you choose. To the right of that is location, which is basically which data center your located in, and the host which shows what server your running on. After that comes the two self-explanatory options, edit and remove. Edit allows you to edit your server, while remove will cancel that server, and add funds back to your account for the time you haven’t used.

After you have an understanding of the layout of the website, it is time to continue on to deploying your Linode server. From the table discussed previously, you can either click the link with the name of your server, or the edit link to the right of that. Doing so brings up a page that shows the statistics for that server. If you don’t already have a server created, arrow down to the deploy link and hit enter.

From within the deploy page, you have several options to set. To get to the section we want, we can use h key to jump to the headers, or just the number 2 will take you to the first heading of level 2, which is the one you want. Arrowing down you see distribution, and then a combo box with a list of Linux distributions that you can deploy. Hitting enter to jump to forms mode if Jaws didn’t do it automatically and then alt+down arrow to open the combo box will let you arrow through your choices. You will want to go up to the top, as you are placed in the middle by default. After you have chosen your distribution (Debian is recommended), you can tab over to set your disk size. The panel by default gives you the full disk-usage possible, minus a 256 MB swap disk, both of which you can change. Tabbing over lets you set the afore mentioned swap size, which is 256 MB. Tabbing again allows you to set the root password, and once more requires that you confirm. Tabbing over once more is a button which allows you to deploy your distribution. That’s it, your deploy is a pretty simple process. You can SSH to your IP address using root and the password provided by you on deploy in order to get access to your system.

After you have successfully deployed your distribution, you should look at securing your system. The documentation on the Linode’s library page (http://library.linode.com), has distribution-specific documentation on getting started. The main things you will want to concentrate on are, Creating yourself a user account, disabling root logins via SSH, installing something like Denyhosts or switching to public-key authentication, installing a firewall, disabling unwanted services and updating to the latest version of packages, if your distribution uses a packaging system.

If you liked this article, telling people about this service would be appreciated. If you would like to get a Linode of your own, using my referral code on signing up would be greatly appreciated; the code is: 7bb9ad2d4d5dd2bdb77593f6fc17b0e498b3970e and the direct link using the code is:
http://www.linode.com/?r=7bb9ad2d4d5dd2bdb77593f6fc17b0e498b3970e

As I will be posting utilities and small tutorials on tasks using the python library, I thought it fit to start off with some boilerplate code. The goal of this article and script, is to give you something you can easily build off of, while maintaining flexibility and ease-of-use.

The code can either be downloaded from this article as a python file, or copied and pasted from below.

#!/usr/bin/env python
#begin boilerplate code:
#You can append other imports after this.
import sys,optparse

if (__name__ == "__main__"):
#we call the main function passing a list of args, and exit with the return code passed back.
sys.exit(main(sys.argv))

As you’ll notice, the first line just tells the shell to use the python interpreter. By using env, the shell will invoke whatever version is the default on the users system; this makes it easier than specifying a specific version in the path, as the user may or may not have that version. After we tell the shell what program to invoke for parsing, we import two modules: sys and optparse, which will both be used later in the code.
For those familiar with c or c++, the next line may look familiar; we declare an entrypoint for the program. While this isn’t needed, I prefer to include it for readability purposes. The main function takes one argument, which is an array of arguments passed to the script, with argv[0] being the name of the program, as it is in c or c++ programs.
Directly inside the main function, we declare an option parser, and add one option to it; that of the quiet switch. This may or may not be used, in most applications it would be intended to stop all output going to the console. This may be useful for example, if the user were running your program from within a script, or as a daemon. After we feed the option parser it’s switches, we parse the options and end up with two more variables. The options variable is a single object, containing the fields of the options that were set, or provided as defaults to the option parser, while the args variable is simply an array of args that was not parsed from within the option parser.
By now, the main function has three variables within it’s scope: an argv variable, holding all the arguments passed to the program. An args variable, which holds the arguments passed to the option parser that weren’t parsed (if any), and an options variable that holds the value of the options.
At this point, you would insert your program code, and return with an exit code, which will be passed back to the operating system. Returning 0 signifies a successful program run, while returning anything else signals an error; this may be useful for passing an exit status back to the calling script.
Directly after the main function, is an if statement to insure that we aren’t executing within the bounds of a function, and then the main function is executed, returning the exit code back to the shell, and passing along the arguments that were passed to the script.
I hope that this code will be of some use in the future for your application development in python. The tutorials and code samples beyond this point will all be built off of this boilerplate code, so you will know what to expect when reading the code in the future.
In the next article, I plan on creating a parser that will take the links either from a URL, or an html page, and parsing out the links. The user will be able to determine whether the links should be passed to an output file, or displayed directly on the console.

One other problem I’ve seen with this mud that seems to be the biggest so far is the enthusiasm for age 400 players (max age players), who like killing newbies. Besides repeated attempts to talk to the admin to make this work better, nothing is getting done about it. There are numerous maxxed players who go out of their way to kill newer players because they have nothing better to do. While you do not lose anything when you die, it can get rather frustrating when numerous players find it amusing to kill you. Besides the fact that the newer players do not stand a chance against these players, (most die in one shot), they don’t have the chance to run generally, either. I have seen many players become discouraged and quit the game after dying to someone who they can’t do anything against three or four times.
It has been argued that the players who kill the newbies lose primal, which is true. However, the primal that they lose doesn’t mean anything to them as they won’t be spending it due to the fact that they are at maximum age and can not age anymore. Characters like Xig in particular don’t care about the primal loss as much as they want a win to be recorded on the bot that keeps track of PK records. While this isn’t a part of the mud, it is a bot that one of the admins set up to keep track of player vs player scores, and currently counts for more than kills to deaths, which are based on age. While people can easily check someone’s pk record using the bot, the person’s kill-to-death ratio which is built into the mud is currently not viewable by other people.

Another point that has been noticed and is currently a hot topic is the use of bots. While killing things is fun for the first 50 or so trains, people soon resort to botting as a way to gain age. The benefit of 250 daily kills, (which is the maximum before the primal, or experience awarded is decreased) currently far outweigh the benefits of doing maps or using boost to level. While the admin has followed a no rules idea, he seems to be actively trying to stop bots by hard coding anti-bot mechanisms rather than finding a proactive solution to make bots less of an issue.

GodwarsII as a game has a lot of potential to grow and expand, but the expansion needs to be welcomed. Newer players need to be able to learn at least a bit about the game and have a chance to pk with someone around their own age before they are forced into a situation where they die in one shot and have no hope in retaliation to protect themselves.