[Java][Source] HailStorm 2.0

Results 1 to 7 of 7
  1. #1
    Chasing 99 Red Balloons Jordan is offline
    MemberRank
    Jan 2008 Join Date
    UKLocation
    1,763Posts

    [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.
    Attached Files Attached Files


  2. #2
    Proficient Member kcs-5 is offline
    MemberRank
    Nov 2007 Join Date
    127.0.0.1Location
    158Posts

    Re: [Java][Source] HailStorm 2.0

    Hey just wondering what this is for before i download it

  3. #3
    ★★★★★ Limite is offline
    MemberRank
    Feb 2007 Join Date
    facepunchLocation
    2,402Posts

    Re: [Java][Source] HailStorm 2.0

    It's a habbo emulator

  4. #4
    Chasing 99 Red Balloons Jordan is offline
    MemberRank
    Jan 2008 Join Date
    UKLocation
    1,763Posts

    Re: [Java][Source] HailStorm 2.0

    Quote Originally Posted by Limite View Post
    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.

  5. #5
    right + down + X GhostSnyper is offline
    MemberRank
    May 2006 Join Date
    AZ, USALocation
    2,819Posts

    Re: [Java][Source] HailStorm 2.0

    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.
    Last edited by GhostSnyper; 16-09-09 at 06:36 AM.

  6. #6
    Ginger by design. jMerliN is offline
    MemberRank
    Feb 2007 Join Date
    2,497Posts

    Re: [Java][Source] HailStorm 2.0

    Quote Originally Posted by GhostSnyper View Post
    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 View Post
    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 View Post
    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 View Post
    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.

  7. #7
    right + down + X GhostSnyper is offline
    MemberRank
    May 2006 Join Date
    AZ, USALocation
    2,819Posts

    Re: [Java][Source] HailStorm 2.0

    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.



Advertisement