TridentSDK - A Multithreaded Server Alternative

TridentSDK is the successor to the Bukkit/Spigot projects. Following the news of the "takeover" of the Bukkit project and the DMCA takedown of Bukkit, and therefore Spigot (we are quite aware of binary patches), we realized that someone needs to step up and create the best of server software for Minecraft after the decline of both projects. The result was TridentSDK, the development kit that is implemented by the server, Trident.

The project is generously sponsored by Gazamo, providing us servers for our website and utilities for the developers. We are grateful to the community who has heard about our project for submitting pull requests, starting, watching, and forking our project. We primarily use IntelliJ IDEA from JetBrains to develop, although some of us have stayed with Eclipse.

Trident is a concurrent, multi-threaded, and obviously thread-safe implementation of the Minecraft server and TridentSDK. This implementation will emphasize these 3 main points; Performance, Stability, and Simplicity, allowing for an efficient, community-based software.

Recently, we've had many developers come and go from the project, however we have now built a hard-working team looking to enhance the Minecraft community. Here are their names and their self-written introductions;​

1. Mazen
   Hi, my name is Mazen (though aliases are mazentheamazin, and MazenMC), a software engineer and the lead developer as well as project lead of Trident. Since I was a child I loved technology and have always wanted to learn about the architecture behind it as well as all the little details. Within the past couple of years, I've been enjoying becoming fluent multiple programming languages from C, C++, Java, all the way to Go. I've been working professionally in the field of software engineering for almost 2 years and in doing so expanded my knowledge on the real world greatly.
   
   
2. AgentTroll
   I'm a programmer from Seattle, Washington. My online name is Pierre C (not my real name), and the various usernames I've used are xTrollxDudex, AgentTroll, AgentTrolldude, etc... Basically, I'm this immature Asian that loves computers and rice (typical, right?), and yes, I do wear glasses! Most of my time is spent on Cross Country running or playing club soccer (some of you may have seen the PacNWSC jacket I've posted on Twitter, and EastsideFC sucks). I am primarily a back-end with 2.5 years of Java experience. I expert on concurrency, performance, testing, and correctness. So yeah, that's pretty much it.
   
   
3. UltimateBudgie
   Yo, it’s Budgie here. I’m 18 years old, live in Australia, and am about to finish school. Programming has always interested me, and ~2 years ago I chose Java as my language of choice... and here I am now. I really love the language (hate them java haters!), and once I found the Bukkit API I was hooked. I’ve helped make a similar project to Trident for CubeWorld (Called Glydar), but as CubeWorld is dead... here I am now! I like working with the nitty gritty protocol/implementation details, so that’s where you’ll see me. Outside of the computer world, I have a few hobbies, such as Piano and Running (but I don’t have much time because of school)... And I’m a bit of a health freak in general. Catch you around!
   
   
4. Vilsol
   Hey everyone! I'm 18 years old, and I am currently studying in University of Portsmouth. I live in UK, but I am originally from Latvia. I am the main developer for this website, so please report any troubles to me. I have been coding for almost 8 years now, and my most stable languages are Java, PHP, C++, Lua, Python, and others. Even though I have been programming in Java only for around a year, I managed to pick everything up really fast. Welcome to Trident!
   
   
5. TigerReborn
   Hi, I'm TigerReborn. I am a 15 year old freelance plugin developer who has been working with java for awhile (I think like a little over a year). I started working with Minecraft a long time ago, and for a long time all I did was moderate/administrate servers (and I did a fairly good job). Eventually, that got boring and I thought that I'd go and learn how to make Bukkit plugins. ~8 months later, and here I am. Thats all.
   
   
6. Mythbustma
   I'm Mythbusterma (myth-bus-ter-m-a) a.k.a Myth, I'm 19 and currently stuying computer science at Michigan Technological University. I've been writing code since I was 14, when I taught myself C++. Still a C++ elitest, I also learned Java about 3 years ago to develop for Androids, and I started developing for Bukkit about 3 months before its demise. I then came over to Trident, as it seemed like the most stable and long-term solution, without having to wait for server updates or Forge updates.
   
   
7. stuntguy3000
   Hey there! I am Luke Anderson, a 16 year old Australian freelance programmer, gamer, and overall cool guy. I have been a programmer since I was 10. I have done a lot of work in PHP, and for the past two years focusing my time onto Java. I have been doing freelance work for 6 months, and have joined the Trident project to contribute my skills to improve the API for all future developers to come.

FAQ:

Why are you creating your own implementation from scratch when ones exist such as Glowstone?

We created TridentSDK with knowledge that implementations such as Glowstone exist, however have conflicting thoughts about design as well as their visions and us as a team did not see a place for a community to exist (varies amoug projects). This does not mean however, that we are 'against' these projects in any shape or form. We are all here to improve the Minecraft community and that's what matters

Okay, this project may be cool and all but how far is it really going to go?

While we're aware of the project size, and the dedication as well as time required to construct the project, us as a team are willing to provide the time and effort to bring the project to a functional state. We've been recently been working hard to make this project become a reality, and contributions from the community are greatly appreciated for that reason.

Wait, this is open source... Doesn't that mean development will be really slow?

Great question, not necessarily. Due to that every team member is a volunteer and is not paid for their work, they have the freedom to say "Sorry, can't do that. I'm busy", which has been the case for some of our developers. At TridentSDK, we respect that our developers have much higher priorities such as school, work, etc. and make sure that they're not pressured to do free work. We also make sure, however that they will have time available in the future to contribute and that their knowledge will be of great use to improve the project.

Will you support Bukkit plugins?

This has been discussed among the team multiple times and the simple answer is yes. When we will is a bit iffy, we will not NATIVELY support Bukkit, however will provide a wrapper. Keep in mind though, this isn't our biggest priority due to the fact that re-implementing the Minecraft server has a lot of tasks on the TODO list.

Wait, this makes no sense... Why do you call the project an SDK when it's actually an API?

We plan to be an SDK in the future as the project develops further. Our plan is set to provide testing utilities, IDE plugins, as well as developer environments to test your plugins in the SDK.

How will developers write their listeners and commands in Trident Plugins?

Currently, we do not have any set design for commands, however we do for listeners (will be updated). Listeners and commands will be dynamically registered, however you may put an annotation to ignore the listener or command from automatic registration and can be manually registered. The events system is quite similar to Bukkit's, however much faster.

Hehe, what if I put a Bukkit Plugin in the plugins folder?

I will smack you with a PluginLoadException

You can head on our forums by clicking the logo above, and feel free to provide any questions here or there. I'll be happy to answer them and will update the FAQ accordingly

 

first!!! vouch

 

Reserved.

 

Nice! Been waiting for a post about this. Also glad to hear that Bukkit plugins is planned, so I(or any other server owner using this) won't have to find alternatives for every plugin.

 

Gamecube762
Haha, thanks! As we wanted to create a custom forum software for our website (thanks Vilsol ), we wanted to make sure that was functional before posting TridentSDK around

 

Looking forward to it!

 

I can vouch for these guys. Really great developers. I expect great things

 

Sounds like it may be a cool project, but the API is too much like Bukkit and will suffer the same pitfalls. In fact, there are quite a few places where code was pretty blatantly copy+pasted. You've also got some rather peculiar design decisions which may not quite work out well.

Oh, and let's not forget vehicles. What is a vehicle, and what purpose does it serve?

 

1. That was actually from a PR opened here: https://github.com/TridentSDK/TridentSDK/pull/12
2. I don't see the issue there, mind explaining?

3. https://github.com/TridentSDK/Tride...tsdk/api/entity/vehicle/package-info.java#L28

 

xTrollxDudex

I know this might take a while, but I've been wondering for a while now. Where should I start learning how to make API's such as bukkit, spigot, etc.

 

Just learn Java or whatever programming language you wanna use.

 

Regardless of the origin, it's part of your project, and part of your API. Just because someone else copy+pasted it doesn't mean that it isn't part of your project. In addition, comments such as "[10/14/14, 11:30:33 PM] troll.dude.3: Pfft we just accepted it because it was a materials class" really show the quality of API that you're striving for. If you're not going to design an API, you might as well not make an API.

It looks like the recent license change moved my line number reference, I was referring to the World object. Aside from the concept of Location being serializable being flawed(serialization can fail based on whether or not the World exists), the current code will fail to serialize. Java can't serialize your world object.

You also implement Cloneable without overriding the method to provide a public clone() method. The default implementation of clone() found in Object(shallow copy) may work in your case, but it's no use if people are unable to invoke the method without reflection.

Is there really a purpose to that distinction, or is that being done purely because Bukkit did it? Bukkit's API was significantly hindered by this nonexistent differentiation. Every Entity in Minecraft can be mounted, vehicles are not a special case, and treating them as such is a terrible idea.

I feel like I should also mention that if you're creating a "concurrent, multithreaded, and obviously thread-safe implementation of the Minecraft Server" you may want to consider implementing a thread-safe EventManager. Aside from hilarious flaws, it shows no regard for memory visibility or the stateful nature of the class.

And let's not talk about the scheduler...

 

evilmidget38
Hey! Thanks for the constructive criticism and to take the time to write it, I will take them all to heart and make sure these issues are fixed ASAP. There are a few things I noticed which I thought I'd comment on though;

Completely agreed here, it's no use for a project to point fingers to people who've made the PRs as it is ourselves who've accepted them. Also, his comment was merely a joke hence the "Pfft" (which displays sarcasm).

Ah, my bad there. Will fix, if you do notice any more thread-safety issues that Troll didn't catch please make an issue on our JIRA to fix it

 

You have issues disabled...

 

evilmidget38
Derp, was meant to reference to our JIRA. My apologies.

 

evilmidget38

Thanks for looking into our project and for your comments. I, personally, was unaware of the issues you pointed out, and will be fixing them in the coming week. If you have any more comments or things that seem out of place or just inefficient to you, please let us know.

Also, what, in particular, is wrong with the scheduler?

 

I'll make a list. While some of the items at the beginning of the list are some of the most glaring issues, the list is not ordered by significance.

1. The basic idea that the entire scheduler is built around: distributing work across ExecutorServices. What you have so far is a VERY inefficient method for scheduling tasks. If two plugins that happen to share an ExecutorService(or in our case, a single thread) both schedule a task, one of them gets to wait for the task to complete. If a plugin schedules a task that takes 5 minutes to run(which is a perfectly legitimate thing to do), it would seriously screw over all other plugins. In fact, I've written plugins before which have an asynchronous task that continues to run until my plugin is disabled. Having two plugins like that could completely remove asynchronous task functionality from a server.
2. Arbitrary threading limitations. Why only two asynchronous threads? Just use a CachedThreadPool(Executors.newCachedThreadPool()).
3. getCachedAssignment is not thread-safe. If a task were scheduled during a tick, you could get an inaccurate count of plugins bound to each ExecutorService in your "thread pool", which means it's inaccurate in addition to being ineffective.
4. It's really cute that you think that because a TimeoutException has any sort of effect on the status of a task. All it means is that the computation failed to complete within the time limit specified. The task is still going to prevent the process from ending.
5. Modification of final fields(something done not only in the scheduler), even with your "fast reflection" is heavily discouraged by the JLS. And by heavily discouraged, I mean that there's a very good chance it's not going to work right.
6. Some of your schedule methods return null for some reason?
7. Some of your schedule methods put the task into the wrong queue.
8. Elements are never removed from cancelledId. While the integers representing cancelled tasks are hardly significant in size, a plugin which cancels a lot of tasks can certainly leave a dent on memory usage as time goes on. In other words, you have a memory leak.
9. cancelledId is a CopyOnWriteArraySet. Searches through it(which are done incredibly frequently) occur at O(n), and as the size of the collection is continually growing(see point 7), the average case is going to increase as well. In fact, because the relevant part of the backing CopyOnWriteArrayList is going to always be at the end, the average case is going to be very close to O(n), as the search always begins at the beginning of the List. So you've got not only a memory leak, but also a growing performance issue as well.
10. If the interval for a task is set to 0, it is possible to create an infinite loop of running that task. RIP server.
11. Speaking of intervals, why is there an intrinsic lock on the mutator and accessor methods for the interval? You've already got an AtomicLong, synchronization there servers no purpose. In fact, you don't even need an atomic long there, a volatile long would suffice.
12. Speaking of synchronization, is it in your style guide to never use the synchronized keyword with a method definition? Through the entire scheduler your use "synchronized (this)" which is the exact same as putting synchronized in the method definition.
13. Looking over the usage of intrinsic locks, I believe that there are numerous places where they could be removed and the scheduler slightly altered to allow for better liveliness. In fact, if currentId was changed to an AtomicInteger, the intrinsic locks could be removed.
14. Regarding API design, abandoning standard Java concurrency support for your own alternative to Runnable is going to make the scheduler seem incredibly foreign to anyone interacting with your API. This alternative to Java's standard concurrency support also fails to provide anything that justifies abandoning Java's standard support. Everything it offers can already be done fairly easily.

There's probably more issues as well, but I don't feel like I can handle staring at that class any longer. It's agonizingly terrible. I imagine if you replace lines 43-343 you might get something half-decent.

 

evilmidget38

Thanks for your feedback, I'll address the issues, a couple of points however.

1. I realize now that my attempts to make one plugin stay on one thread is misguided, and was probably out of my mind when I wrote that.
2. Regarding the CopyOnWriteArraySet, what would you recommend as a thread safe set or list?
3. The synchronized (this) is a change one of the other contributors made that I very strongly argued against.

Again, thanks for your insight.

 

how far is this project so far? looks very nice!

 

mazentheamazin Hello Mazen, why should people choose Trident over Spigot? Spigot are now doing a full recode for 1.8

 

bwfcwalshy
Hi, we're aware of such and are happy to answer your question. Currently, Spigot uses NMS (or Mojang server code) which has flaws in itself and is generally not efficient enough. Trident looks to bring the full potential out of what could be a new generation of Minecraft servers, and is willing to work hard to get there. Trident is having a plan to support easy mod implementation with support with Forge, and looking to make the Minecraft server to be as flexible as possible. Our server is also multi-threaded, providing an efficient way to handle tasks and avoid lag wherever possible with large player load.

 

mazentheamazin Thank you, I was torn between which to use I am leaning more towards Trident. I hope it lasts and it works well, thank you for answering maybe put it in the OP.

 

bwfcwalshy
No problemo, and thank you for the feedback

 

Looks like a very nice setup. Definitely a solid team.