[Java][Source] HailStorm 2.0

HailStorm 2.0 Is a multi user server framework, designed for stability
and functionality. HailStorm is written in Java.

Copyright (C) 2008 - 2009 HybridCore (Jordan)

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.

You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.

See atachment for source and info by downloading this you agree to the above license terms.

Hey just wondering what this is for before i download it

It's a habbo emulator

Quote:

---

Originally Posted by Limite

It's a habbo emulator

---

Nope its a server framework :) i just left the com.hailstorm.message class's in there from a personal project.

This is a good start, however there are somethings which are a bit iffy... One thing, you should not be wasting database queries for simple things like the max connections or the port. those things should be static (final) or loaded from a local configuration file (Like your props file). Also, your database stuff uses too many classes... You could do the same work with Database.java (Which holds your connection and possibly it's threadpool), and DatabaseClient(abstract class which runs the queries through the database class... Of course, I'm not as proficient as I used to be, so your methods may be the standard. Also, Threading is good, but not every action and every connected client needs it's own thread. Doing so will overload the processor with a high number of concurrent users. It's better to have x amount of users per thread, and an overload. If objects in thread x hits the overload, a worker thread is created to shift y amount of objects to a new thread, Z. Good start to a Framework, although some of the things here are made more complicated than they are.

Also, you're using some bad conventions. first of all, you're writing methods as 'MethodName' rather than the JAVA standard 'methodName' the only time for a capital letter along the first would be if you were to initialize a final variable, where you'd use something like 'METHOD_NAME'

Also, synchronizing the print methods could cause issues in the event that a large amount of data needed to printed to the console... Just use the date-time and it'll be fine; Nothing should really be that important in the server console that you're risking slowdown.

Quote:

---

Originally Posted by GhostSnyper

This is a good start, however there are somethings which are a bit iffy... One thing, you should not be wasting database queries for simple things like the max connections or the port. those things should be static (final) or loaded from a local configuration file (Like your props file).

---

It's quite a common practice to store configuration data in a database table. It's really a personal choice tbh, how you load configuration data.

Quote:

---

Originally Posted by GhostSnyper

Also, Threading is good, but not every action and every connected client needs it's own thread. Doing so will overload the processor with a high number of concurrent users.

---

It won't really overload the processor. Rather, the OS will be context switching so much that concurrency will actually be impaired. Also, each thread has its own stack space, by default on windows 1MB, so it can quickly cause resource starvation if threading is overdone.

Quote:

---

Originally Posted by GhostSnyper

It's better to have x amount of users per thread, and an overload. If objects in thread x hits the overload, a worker thread is created to shift y amount of objects to a new thread, Z.

---

A thread pool processing asynchronous i/o from sockets should never contain more threads than there are logical cores on the machine running it. This is because it causes context switches to become more frequent and you're looking for maximum throughput, a single cxt switch is more costly than handling quite a few jobs. If done properly, a thread pool with 2 threads can run simultaneously pulling data and processing it without incurring a single cxt switch during their entire CPU burst.

Quote:

---

Originally Posted by GhostSnyper

Also, synchronizing the print methods could cause issues in the event that a large amount of data needed to printed to the console... Just use the date-time and it'll be fine; Nothing should really be that important in the server console that you're risking slowdown.

---

Synchronization is local. That is, if you properly use a mutex to protect code that needs it, such as multiple threads trying to write to the same output stream, the only threads which will block are those attempting to gain a lock on the mutex. It won't cause a slowdown for anything other than threads that try to print to stdout in this case. Additionally, if daemonized, standard output may be redirected to a log file, and for that log file to be useful in the event that potentially useful information is logged, it's a good thing to ensure you don't get collisions because that could (even if it's unlikely) cause it to become unreadable.

makes a lot of sense... I've been out of practice for quite some time, so my knowledge is quite vague. Thanks for explaining, mate.