Thread: Common Misconceptions

Page 1 of 4 123 ... LastLast
Results 1 to 10 of 39
  1. #1 Common Misconceptions 
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Basically there are a huge number of common misconceptions floating around at the moment.. and I just want to clear a few things up. You'll find several nice hints and tips in here to, to improve the way your server works.

    Lots of this stuff could also apply for 317, however, there are a few specific cases for 508s which I don't see happening in the 317s. Plus I'll probably add stuff more 508-specific in the future. Just need time to write it all hehe .

    Misconception: You need to call the java compiler once for each package

    This is not the case. In fact, you only need to call the compiler for one file. The server.java file. In a clever way, it'll automatically recurse through your classes and resolve dependencies. This is why the 508 'compile' batch files seem to take such a long time to run. It's because they are compiling things over and over and over again because instead of putting this all on the same command, Pali split it up into separate commands. There is one exception to this: classes loaded through reflection. On rs2hd for instance, packet handlers are loaded through reflection so you must compile these manually, same for the logging system. This is NOT the case on Pali's server as the packet handlers are NOT loaded through reflection.

    Misconception: You need to set your CLASSPATH

    Nope you don't. The CLASSPATH environment variable is used by Java to find class files. The PATH environment variable is used by Windows to find executable files. You only need to set your PATH with the path to the directory containing the javac executable, not the CLASSPATH too.

    Misconception: The client needs to be set to game1

    It needs to be set to game0, else some features (such as character colours) will not work. Pali set his to game1 out of mistake apparently.

    Misconception: Removing RSA and the ISAAC cipher is good

    Sean has made great points about it in this post, I'll just link to it to save repeating it here.

    Usage of getters/setters

    Many people are writing classes like this:

    Code:
    public class MyClass {
        private int myMember;
        public int getMyMember() {
            return myMember;
        }
        public void setMyMember(int myMember) {
            this.myMember = myMember;
        }
        public void doSomethingElse() {
            // usage of getMyMember() here
        }
    }
    It is not necessary to use getters/setters inside the class they are declared. It's just untidy. The reasons getters and setters are used is because it allows the way the class works internally to be changed without external programs using your API breaking. There is little reason to use the getters/setters internally.

    Misconception: Cache versions and client versions are the same, and update keys are related to client version

    All wrong. The cache has no revision number, although you could refer to it by date I guess. Multiple clients could use the same cache sometimes, sometimes there could be a single client using a single cache.

    Update keys are related to the cache revision and not the client revision. super_ has topics about it here and here.

    Misconception: NIO == stable

    Not necessarilly. I'd wager it's still possible for the community to completely mess it up (like our wl-style servers today). Normal IO has proved to be fine (with some modifications to the kernel - NPTL in the case I am mentioning) - e.g. mailinator uses normal IO and can support thousands of connections.

    However, in general, NIO is probably still going to be more scalable, however this stuff depends heavily on the OS/hardware/etc... thiefmn made a topic about it here. He also talks about using the server JVM vs the client JVM, the server JVM takes longer to startup but after that is much faster (although does take more memory too I think). Speed is the essence here (in order to reduce lag), so a slower JVM startup and slighty more memory usage is a good price to pay imho.

    The IO isn't always the thing that can help. You can also mess up stability in other ways, e.g. not dealing with exceptions or synchronization correctly.

    This kind of leads to my next point, about:

    Misconception: Networking libraries/frameworks/etc

    Right Blake has basically said raw NIO > * while he was here. This is not always the case. Some of these libraries are very cool and contain fairly complicated features..

    E.g. in MINA you can do this:

    Code:
    session.write(obj).addListener(/* a class can then be called back when the operation is complete */);
    Example, used in rs2hd:

    Code:
    public void sendLogout() {
        player.getSession().write(new StaticPacketBuilder().setId(104).toPacket()).addListener(new IoFutureListener() {
            @Override
            public void operationComplete(IoFuture arg0) {
                arg0.getSession().close();
            }
    });
    Here, we write the logout packet and then wait until it is sent, and then close the connection. Doing this in NIO itself is quite complicated, especially as the write has to be done in the selector thread first and then after it has successfully completed, it can then be closed.

    Also, these frameworks allow very rapid development in comparison to writing your own networking code from scratch. They are likely to have been extensively tested, have a good community of tutorials/a place for help, bugs will be found and fixed in future updates without you doing a thing and they remove a lot of your work!

    Misconception: Don't just catch exceptions and do nothing!

    I've seen loads of code that is just catching exceptions. E.g. for instance:

    Code:
    try {
        // do something here
    } catch(Exception e) {
        // does nothing or just prints the error out
    }
    This is very bad practice. The more 'correct' way to do this, is by throwing the exception (instead of catching it) UNTIL you get to a point when you can deal with it correctly.

    For instance, if we have something that *could* throw an exception in packet parsing a equip packet.

    Here is what our stack trace may look like:

    1. Equipment.equipItem()
    2. EquipmentPacket.parse()
    3. Player.parseIncomingPackets()
    4. Player.readIncomingData()
    5. Thread.run()


    equipItem can't really deal with the problem. Instead, it should throw exceptions up that chain until it gets to a suitable point.

    Imho, a suitable point here would be parsing the incoming packets. Then you could take the action of disconnecting the player (as a packet is corrupt or they are trying to crash your server).

    Equally, if you have problems loading a file on server startup say (e.g. IOException), do NOT continue starting the server. Let it print the issue and not start, it'll make debugging/finding issues MUCH easier.

    Exceptions shouldn't be ignored, they represent exceptional circumstances and if you ignore them you could end up with some funny, hard to debug issues!

    Misconception: XML is always good

    Truth is it isn't. It's slower to parse (e.g. on rs2d the ~13,000 item definitions take around 8 seconds to load in XML but less than a second when I'm doing it using a custom binary format and a RandomAccessFile).

    It's a bit like the mapdata, packing it from thousands of txt files into one binary file also made an improvement. I'd reccomend converting anything you have using xml (or another slow text-based format) into binary.

    You can still have xml files, but have a tool that converts it into the appropriate binary format (look into the latter rs2hd revisions for info on this).

    XStream, a libary I used in rs2hd which a few other people have followed now, is a large memory hog and this can save a lot of memory while you are loading the data.

    Suggestion: Run time-consuming operations in other threads

    Unfortunately I've yet to see this in few servers (other than rs2hd). With more and more cores on CPUs becoming available, this should be a high priority. If we keep a servers the same they are (running everything in basically one thread), they won't be able to take these new developments and use them to their advantage.

    However, you do have to deal with synchronization/concurrency and if not done correctly (or if you have a lack of it), you can end up with funny issues, deadlocks, etc which are very hard to debug.

    If you are up to it though, one of the things that I'd have as high priority is player game loading/saving. Reading and writing to/from the disk is relatively time consuming compared to reading/writing to/from RAM. If you have more and more players on, it'll be taking longer to process your game logic (as you probably have auto saving and such, and saving/loading as people login/logout). In fact I think in Pali's 508 base it's done in a different thread anyway although I'd still do it differently to him.

    This is a typical scenario in which you want one thread producing events (e.g. a load/save request), and this thread is our game logic thread, and one thread consuming events, and this thread is our loading thread.

    The solution? Instead of writing lots of code from scratch, we can use a class in the Java standard library: a BlockingQueue. It is designed exactly for this situation.

    I'd reccomend looking into it, and making these requests take place in separate threads. I tend to use a LinkedBlockingQueue as there are virtually no capacity restraints, however, you can also use a fixed-size ArrayBlockingQueue (which allows you to put a certain number of items into it without blocking then it will block). Specifically, you should look into the offer and take methods.

    Redudant null checks

    A lot of you check for player objects (and even this!) being null when it's not needed.

    TODO

    Collections framework

    TODO

    Conclusion

    That's all I can think of at the moment, so hopefully it'll give you a clue on what things you should and shouldn't be doing. I may have made some mistakes, it is a high probability so feel free to correct me and suggest more things you think we should be heading for as a community. Feel free to ask questions if you wish.

    Enjoy!
    .
    Reply With Quote  
     

  2. #2  
    Member Common Misconceptions Market Banned


    Luke132's Avatar
    Join Date
    Dec 2007
    Age
    35
    Posts
    12,574
    Thanks given
    199
    Thanks received
    7,106
    Rep Power
    5000
    Good topic Graham, don't have time to read it all now but from what i had a quick glance over, some good info there.

    Attached imageAttached image
    Reply With Quote  
     

  3. #3  
    Registered Member
    Hotyute's Avatar
    Join Date
    Jan 2008
    Posts
    2,016
    Thanks given
    7
    Thanks received
    92
    Rep Power
    1482
    nice


    Reply With Quote  
     

  4. #4  
    Renown Programmer

    Sean's Avatar
    Join Date
    May 2007
    Age
    32
    Posts
    2,757
    Thanks given
    264
    Thanks received
    1,090
    Rep Power
    4393
    nice explained graham free taco
    Reply With Quote  
     

  5. #5  
    Programmer, Contributor, RM and Veteran




    Join Date
    Mar 2007
    Posts
    5,147
    Thanks given
    2,656
    Thanks received
    3,731
    Rep Power
    5000
    Thanks, and I'm planning on writing more just need to find the time hehe .
    .
    Reply With Quote  
     

  6. #6  
    Brown
    Guest
    Thanks. Read evey single bit of it.
    Reply With Quote  
     

  7. #7  
    Registered Member
    Kelvin's Avatar
    Join Date
    Jun 2007
    Posts
    1,433
    Thanks given
    48
    Thanks received
    33
    Rep Power
    269
    nice graham, i readed everything also thanks for clearing some stuff up.
    Reply With Quote  
     

  8. #8  
    Banned

    Join Date
    May 2008
    Posts
    2,583
    Thanks given
    99
    Thanks received
    22
    Rep Power
    0
    Good thread. Im a try game2 lol, see if my character turns purple O.O
    Reply With Quote  
     

  9. #9  
    Banned

    Join Date
    Feb 2009
    Posts
    1,533
    Thanks given
    4
    Thanks received
    34
    Rep Power
    0
    I wonder what the purpose for game1 and game2 are anyway, I'm guessing they're used for internal development.
    Reply With Quote  
     

  10. #10  
    Banned

    Join Date
    May 2008
    Posts
    2,583
    Thanks given
    99
    Thanks received
    22
    Rep Power
    0
    Yeah, and game2 doesn't exist. Tried it. Its game1 and game0, game0 is the correct version. Game1 is where things are changed around(Probably jagex testing things for future updates?)
    Reply With Quote  
     

Page 1 of 4 123 ... LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •