But how about chatting to people on MSN or ICQ from an IRC window? or AOL or Y! through an ordinary web page, nothing needed to download? That would probably be a bit more interesting.
Well, welcome to M-Chat.
M-Chat is a server (actually a group of servers working together) that allows connections through all of the already mentioned protocols, and more.
There are many many other chat servers out there, many good, and some of the good ones are even as free as M-Chat. There are also ways of chatting between some of these different services, or chat sites that come with HTTP and IRC already set up.
So why M-Chat?
There are a number of reasons. Most of the features you'll find in other chat systems, but not all in one place.
The history of this system.
If you haven't been to www.alamak.com and chatted there, it may be a good idea to, because this project started out a long time ago as just HTTP and IRC, to fix problems I saw at Alamak, and to improve the server the way I think would be best.
Since then it has gone from something I want to run so I have have a better server, to something that I'm going to actually give away, and hopefully be far better than any other free cxhat system, and most likely many non-free versions too.
As it developed, I have looked at other projects, not just chat systems, that may give me ideas or resources. Hopefully this server will provide features like SMS, a fully featured webmail system (think hotmail or mail.yahoo.com), homepages, NNTP news servers, and many other things. If you enable these options or not, and if you charge for them, is entirely up to you. if you make millions out of it, then good, and I'd like to know about your successes (and failures, they might help me change things for the better). However a donation to help work on the system, or just as a thank you, or whatever, while not necessary, would be greatly appreciated 8^)
The level system, as well as the rules, and commands, are based on those at Alamak, though improved on a great deal.
Notes/issues/points of interest.
This system may include some basic cryptology information and/or routines. It should not be an issue, but it is the responsibility of the people who download and use this software to ensure they do not break any laws, and any legal issues arrising are wholey and completely the responsibility of the downloader.
As soon as you start installing addons (including games) from other people, or working with different versions of software, you run a higher risk of having errors. I'd like to think that everyone who writes code that can be added to this project is competant enough to make good, portable code (and I expect that if people do, some of them will be a lot better than me), and that my code will be compatable across a number of version differences, but I don't think it's that likely. One or two releases difference and code from people who know the software well, I'd say is good, but the further from there you get, the higher the chance of problems.
You will need to have the core of the program to use any of the other parts.
That should be all you need. really. Although it's not really a good idea to run just on that.
The best thing to do first off is make sure you have the most up-to-date versions of all applicable software. OS, perl, database (if you use it), and parts of the server. This should be common sense.
Because some of the immature people who may get kicked off can get ahold of script-kiddie tools, the better protection you have against this sort of thing, the better. A properly configured firewall and virus scanner should really be requirements for any computer connected to the internet for more than a few minutes a day, and especially for a server. If you have a type of firewall that can discard packets depending on IP, port, info, and such, and the server can put information into it, you will be immensly safer, properly secured, the only thing anyone could do is a DDOS or DrDOS attack, there's not really any way of dealing with this at the server. Sorry.
It would be advisable to put your long-term info into a database. The server can use plain text files, but that's a bad idea. For security and performance. This server will come with interfaces to a number of databases, and developing interfaces (using CPAN/PPM perl modules hopefully) to more should be very simple.
The more RAM, HDD, CPU power, and bandwidth you have, the better. The more active your server, and the more system intensive things you do (like compressing data), the more computer power you'll need. If you get to the stage where you'd have to buy a more powerful computer, my opinion would be to get several cheaper computers instead of one powerful one (which would have more power combined for less price), network them, and have parts of the server running on different computers. On a small LAN, the chance of a netsplit-like problem is a lot lower than on the 'net, but still higher than on one single computer. When doing this, where possible due to performance issues, the core part of the server should be run on the most stable computer, as if any other part goes down, only one protocol goes down, but if the core does down, everything goes down.
If you use this software, or like it, there are some good things you can do to help.
Nothing here you have to do, but it would be nice, and it will help the development.
Make a donation. Money makes the world go round. You can specify what it's for if you like, if you are putting up the money, I'm far more likely to work on your favourite area. There's no garuantee though, but if you say it's only for a certain project, and I dont want to work on it, I'll return the money, Or get in touch about a similar idea or project I have.
Dealing with bugs. If you find a bug, please let me know. Or, if it is related to coding that someone else has done, like games, mod packs, or even if someone else becomes a developer on the core, then you should make sure you talk to the right person. If they think that it's an issue with the programming in the main part of the program, they can bring it to me.
Reporting bugs. If I get an email like "this server crashed. what's wrong?", I wont even reply to it. If you're reporting a bug, include info on your computer, CPU, RAM, HHD, versions of perl and database software, what parts you have installed, what version of the server and other parts you have, what alterations you or others may have made, when and where the bug occured, if it's a constant thing, or if it only happens some of the time, and most important of all, HOW TO REPRODUCE IT. If I can make it happen on my system, I'm most of the way to finding and fixing it.
Bugs and Versions. If you have a bug, and you're not running the latest version in your choice of distribution (stable, dev, or raw), upgrade all parts to their newest version and see if the bug is still there. It may well have been fixed, even if it's not in the changes or bugfixes info. Note that this does not apply to seasoned releases, as any release that's been declared seasoned should be completely stable. The only issue here is if an old version that did work no longer works with a newer version of perl or your OS or whatever. And Games and addons and such may well require some of the features in the newer version, although the software SHOULD detect this, issue the error, and not use the addon. Also please check first to see if the bug is already listed. If it is, and you have more information that is listed, please let me know that it's more info on an old bug, so I can easily work the onformation together. Having several bugfixes on the same bug may end up being counter productive.
Best reaction to bugs. Reporting a bug with all the relevant information would be good, actually looking into it, finding the problem, and maybe coming up with a fox would be far better. If you email me with the information about a bug, and how to fix it, the fix is likely to go into the code immediately rather than when I get to it. People reporting bugs will get a mention (unless they ask not to) in the documentation, the more work or harder the problem, the more prominant the thanks. And who knows, if enough people make donations or pay for support, I may be able to offer rewards for bug fixes some day.
Support. If you want support beyond fixing bugs and portability, you may not have much luck. If I think it's an issue many people may come up against, I'll probably write some info on a web page or make a small tool to deal with it, but even then it may take some time. If you need help right now, you probably need paid support. The more work there is, the more it will likely cost, unless it's something I wanted to work on anyway, in which case it will be far cheaper (as you're paying for me to do it sooner, rather than just to do it).
So, you think that this as an awesome project, and can't wait to start using it. Or you think that a few of the tools included may help you with something else. Where and when can you get it?
Well, where is easy. This project is on sourceforge.net, and is likely to stay there. If need be, the project may be moved, and the sourceforge site made a redirect page.
As for when, well, considering current progress on the servers themselves is going (some of the time I'm working on extra tools rather than the servers), there probably wont be a real release for some time yet. The first release will probably have a working core server, and either IRC or HTTP, with a few basic tools, and database access. Once that is out, I'll work on getting more databases supported, more servers, increase the stability and so forth. I'd like to be able to release a huge number of games, but the work to make good games libraries will take a lot, and will have to be done after the rest of the framework is in place.
The first working server release may, or may not, happen this year. Yes, it may well be 2004 before the first release is out. Because of the way I want to write this, I can't do a partially complete release for testing, the first release will have to be a fully working version of the core and IRC or HTTP, with database access, and config support. Right now, the design of the server and the communication between servers is still open to alteration, current plan is for a extended IRC numbers system, which will help with IRC communication, and the number system will make it easier to use lang packs.
Until the theory is worked out, not a great deal of programming can go into the core, the most anyone else can do right now would be to get in contact with me and talk about this, especially if they have experience with IPC, perl, chat servers, IRC (on the coding side), or the other supported protocols. But anyone who has ideas and no experience at all outside of using chat servers can no doubt help, so feel free to contact me. Once there is a bit of an interested community, mailing lists could be used for everyone to discuss ideas.
Once the theory work is done, there may be some work other perl coders can do themselves, but as I would rather write the first release myself, it would be interfaces to other databases, or helping test ideas and code on other systems, and the like. Of course, anyone who can translate language packs will be welcome to help there, the (Australian, since that's what I speak) english lang pack will be there as a reference. However, until the first release, you can expect the structure to change, and their help will most likely still be needed. Also likely to be used will be small graphics, possibly gifs, but png would probably be a lot better, anywhere where they're still under patent, people using them can be charged for displaying them on their website.
Once the first release is out, anyone will be able to start making addons, games, mods, database interfaces, other protocol interfaces, and anything else. Although until the release of a reasonably developed gaming framework, not too much can be done there.
Assuming this project is still on sourceforge when the gaming framework is released, I plan on having a new project registered, for the people who wish to develop games, so they can do so without my interference. Hopefully they'll want to discuss ideas and protocol and such with me, but if they dont, then so be it. If I think games and/or gaming libraries are good enough, they will be made available as part of the main system.
Information on how M-Chat update servers and version control work will also be made available to those interested (and quite possibly be improved on by some people).
Once it is out, which version/distribution should I get?
The newest version, from the main server, of course. The update script which comes in the toolkit can check the update server, finding out which modules have a newer version. Eventually it's my hope that the updater will become as sophisticated as PPM for activeperl, and be able to use a number of update servers, as the main one will not carry much in the way of alterations/mods/games.
As for which distribution, that's more an issue of personal choice. At the moment the plan is for 4 distributions, seasoned, stable, dev, and raw. Raw will include all the newest features, things being worked on, anything that's alpha-test quality will probably be here first. If you want to be testing and expect your server to fall over often, this is the distro for you. This is about the quality you get when you download nightly tarballs or cvs code. Every now and then all the work on the server will be put together and made into a dev distro. This can be considered beta release, most of the bugs should be worked out, but only most. This should be where the majority of testing occurs, and any problems fixed. Once we're confident that the bugs are out, a stable release can be made. If you want to run this as a chat server, as opposed to a test server, this is the distro for you. Once it gets into a stable release it should all work, and be forward and backwards compatable as much as is possible, working with previously designed mods. Unless you require a distro that wont fall over or have any issues left, this one should do you. Once a stable release has been out for a while, if no problems are found, and it seems to work fine, it can be made into a seasoned release. Seasoned releases will be the most stable, but will be out of date compared to current code. Hopefully seasoned releases of core should roughly correspond to seasoned rleases of other server parts, to tools, and games, meaning using seasoned release on all parts (and config only allows you to use one distribution type) should not cause too many, if any, version incompatability issues. Any found should be listed, if not listed, please let the developer know so they can put it on the web for other people to read. Do not expect any problems you find in seasoned releases to be fixed, if there are any they are probably fixed long since in more current distros, the msot that will happen with a problem in a seasoned release is that it's taken down or a warning put on the relevant web page.
How do I keep it up to date? And once I have the files, how do I message all users, shut down the server, upgrade, and reboot the server?
All you need to do to keep the server up to date is to run the update tool, once properly configured, it can run automatically. I should even be able to be run in batch mode, so simply setting cron or task scheduler to run it in batch mode during the quiet part of the day should be sufficient.
The updater tool will also replace old files ( you can keep them in a backup directory if you wish, and restore manually in case of a problem) with the new ones, meaning the next time the server is run, it will be most current. The updater can also, if enabled, access the running version and overload the modules that have been changed. This means that apart from a short slight drop in performance, there should be no decrease in service. Please note that this very cool idea may not work too well on all systems. Before you do this, it would be nice to log on as an admin or with the control system and do a system-wide broadcast that an update is occuring, and if connections are lost, the server will be up again momentarily. If a problem occurs doing a hot update, or has in the past, let us know with the rest of the relevant info (see reporting bugs), and do a cold update. Use the control interface to (preferably) let people know an upgrade is in progress, then shut the server down, run the update tool, and re-load the server. If you still have problems, revert to an older version by replacing the new files with old, and let somoene know of the problem and relevant info.
What about updating games, or addons, or other files?
Assuming they have the right files where you can get them, you can just add the URL to the updater and it can check them too.
Anything I haven't covered? Questions? Comments? Want to help? Let me know.
This project hosted on , using Activestate's ActivePerl port of Larry Wall's perl.