BungeeCord... 2.0? It needs many improvements...

Discussion in 'BungeeCord Discussion' started by imAverageNoob, Apr 21, 2021.

  1. Hey guys! Well, I'm here to criticise BungeeCord, and try to give possible suggestions to fix the issues.

    You might say i love bungeecord its da best or something ugly like that. But, try to look at this post unbiased, please, as there are many issues with BungeeCord that almost everyone knows and ignore it, just because BungeeCord is too popular.

    So, moving on:
    1. Open-source code, but not open-minded
    This is something that BungeeCord needs to improve. Although the source code is available for everyone to see and improve upon, however, for a long time md_5 hasn't been really open to contributors outside of the eco-system, and this makes BungeeCord not really open in its codebase. Like, all the codes are from md_5, and if you are reading this, md_5, I can see that you are (almost) never going to merge a pull request if it was made by someone outside of the SpigotMC dev teams, despite them having a real advantage over the old code.

    Oh, and by the way, md_5 is even hostile to simple fixes to bad code. md_5 is almost always rude in his words, and you can probably see that if he replies to this post.

    2. Not so lightweight API
    I guess everyone knows this. BungeeCord has a heavyweight underlying API which makes it easily outperformed by other L7 Minecraft proxy implementation. Well, I'm gonna skip this as many people know it. Please revamp, or completely renew the underlying API.

    3. Does not support non-Vanilla clients natively
    Well, again, literally all people around the world knows this. md_5 does not even want to support Forge, so don't talk about Fabric. I can't think of a fix for a big project like this, though, sadly.

    4. Code quality?
    Bruh, seriously, don't even talk about this. The code looks messy, and the code quality is not that high either. If BungeeCord uses FindBugs/SpotBugs there would be something like 100+ bugs reported. Is md_5 gonna improve the code, or is md_5 going to use @SuppressFBWarnings?

    5. Easily affected by attacks
    Well, I wouldn't blame BungeeCord for being affected heavily by attacks, considering the popularity of the project. However, these attacks could easily be mitigated even without the use of plugins, it's just that md_5 doesn't want to make BungeeCord even worse in its weight.

    Also, I'm not talking about bot attacks. I'm talking about packet exploits. These can be mitigated easily by not making the console spam exceptions, and for advanced packet exploits... I'm not a protocol expert, so it's time for md_5 to find out the solution.

    6. Performance
    Well, uhm... By switching to Waterfall you will be able to get at least 5% performance increase. Guaranteed. BungeeCord is too heavyweight, and this is the main factor that causes BungeeCord to be laggy. By using multithreading, BungeeCord can be easily an asynchronous software implementation, and thus bringing the performance up at least by 20%.

    Well, I wrote this in something like 15 minutes, so don't blame me for having a post with lower quality. Please review this seriously, md_5, and one day I'll switch from (the speed of an object moving) back to BungeeCord.

    • Like Like x 1
  2. Firewall.
  3. Yeah, I am sure when he reads this he's going to be super motivated ..

    Funny though, I've had stacked up quite a few tags and responses, direct msgs, etc with him over the years on this site and they've been fine and friendly.

    I think a lot of people also confuse being direct, correcting, to the point/blunt as hostile/rude. A lot of people love to sprout the crap like they do but then don't like it when they get called out on it or get a correcting follow up.

    Seeing what is out there in this gaming community of Minecraft for proxying, there's been quite a bit of development to bigger and better steps to help communities run their networked servers. I am sure md_5 is aware of them, and with constructive feedback vs judgy criticism there's probably space at some point to make some steps. But he's in my opinion also free and this might also be possibly the case, to just think: I just do what I think is what is the minimum to achieve this, and there's enough projects out there made from scratch or that can fork this and extend on it; I can leave it up to them. Or, it could just be time constraint, there's already enough to do I am sure.

    Anyway. You've made some valid points in regards that time moves forward, Mojang's game is growing and through the years the desires of server owners have adjusted and we've all learned what is possible and started to have wishes that go beyond what was originally created.

    Who knows, hopefully the future brings some fancy new stuff.
    • Agree Agree x 1
  4. Andre_601


    I mean..... Velocity is a thing... Just saying

    This.... isn't easy. You essentially demand a complete recode of the entire BungeeCord codebase to put it simply.
    And if what you say is true will MD_5 probably not bother with people providing PRs for this recoding.
    • Winner Winner x 1
  5. there is already bungeecord 2.0 ( just that it isn't compatible with bungeecord 1.0's plugins )

    We need to mention that it was written in java 7

    BungeeCord is already multithreaded.
    • Agree Agree x 1
    • Funny Funny x 1
  6. Andre_601


    I agree on this.
    I myself had this before where people assume I was an asshole when in reality I was just straight up honest and don't try to "talk through the flower" to not people. If you want feedback, you WILL need to accept some more direct responses. And if you can't handle this... don't work in the open-source area I would say...
  7. Andre_601


  8. I was writing this when you did your post so the joke isn't relevant anymore :/
  9. electronicboy

    IRC Staff

    if you skimp on API, making stuff faster is easy, e.g. rip out the scoreboard stuff for some sweet perf gains, but, then you lose the ability to do scoreboard stuff on the proxy without everybody reimplementing it, Velocity wanted to go without a scoreboard API for that reason, but, last I knew was adding it because there is a good demand for it

    non-vanilla clients is also a headache, forge broke support here, not the proxies, downstream we do aim to support forge, but, are currently in a sore spot where forge broke all hopes of that, with my health being trash I've had little self interest tryna take this up, however have spoken to lex in the past before he even made these changes about ways we could improve compat, but, nothing was really done there, so, somewhat disheartened. Supporting every up and coming mod platform takes a good chunk of effort too, many are surprised that fabric is getting as big as it has become.

    "not throwing exceptions" is also caveated, exceptions have been optimized in a good chunk of areas, but, a lot of comes down to "you're exposing something to the internet and expecting it to actually process network connections", tryna figure out how to boot malicious actors as early as possible is always a struggle to the point that there are companies literally making millions tryna solve this issue. avoiding exceptions is trivial if you wanna double the amount of work by tryna validate every form of data, sometimes 'let it blow' is the fastest option

    Bungee, is, already multithreaded, there are some caveats here in terms of how netty works, but, that's technical in nature and potentially much more complex to solve, especially as people generally don't want a proxy using hundreds of threads for handling stuff, something which is marginally more acceptable on web servers dealing with thousands of requests

    many of these things are easy as all heck to oversimplify, many issues are trivially solvable if you don't care about wider compat or only care about specific environments, there was a PR which helped solve some of the recent DoS issues but potentially broke many over aspects of support for stuff, which is great if you're running a vanilla server but stood a good chance of breaking a huge host of wider issues, yet people acted like it was the most important thing to pull.
    • Informative Informative x 1
  10. Or just inject into the bungeecord logging system thru a plugin to prevent those exceptions from getting triggered. Like my plugin does, without my plugin, 1000 unexpected packets per second attack bungee crashes in 30 seconds - 1 minute, with my plugin, +40.000 unespected packets per second in 3 core server, only 30% cpu usage due to incoming connections, 0 lag and no crashes.
  11. Which plugin?
  12. Plugins are not a permanent solution.
  13. They are when you block the malicious connections thru the Networking layer (IPSet (iptables))
  14. For something that's so bad, BungeeCord seems to chuck along just fine.
    Can't really blame MD5 for being critical when looking at new PR requests. It will be pushed out to quite a couple of servers, and should not break anything.

    PR / Branch or shut up
    The API is what makes spigot / bungeecord so useful. Sure you can make something faster, but it won't be as versatile

    Asynchronous and easy never go well together in my opinion :D
    • Agree Agree x 1
  15. Projects with developers outside of the team opens a room of possibilities for them to improve. Why don't BungeeCord (and also Spigot) be like that? I respect the fact that a new update must not break any old things, but in case it does, then I guess the plugin devs should be pushing out newer versions of that plugins anyway.

    There can be a way to not to make plugins break after a new update: Make 2 separate branches. One is the stable branch, and another is development branch. The plugin devs should be focusing on the development branch changes, and update their plugins accordingly. This is how to achieve something like "updated BungeeCord that breaks old plugins" while having the "old plugins being updated to adapt to the changes and work well".

    Port it to Java 8, then. Java 7 has officially reach its EOL, and almost everyone is using Java 8, a Java LTS version that has its support extended to 2030. Or even better, move from the old Java versions to a newer one and have many better QoL improvements, and is currently the minimum Java version must be used to run PaperSpigot, 11. Java 11 offers better performance (as usual), and moving from 8 to 11 doesn't require much effort (90% of the code in Java 7/8 should be compatible with 11).

    By the way, if migration breaks, then why don't take the chance to fully rewrite the API?
  16. Because of time, unless you are willing to spend LOTS of time on this it's nearly impossible.
    Also, it would just about break every single BungeeCord plugin out there, and I am not sure if that's worth it at all. Forcing authors to 'simply' update their resource does not work.

    The beauty of the Spigot / Bungeecord API is that it's consistent and almost never breaks between updates.
  17. While you're technically correct, it is my opinion that when a software has such a commonly misunderstood, misread setup procedure, with severe security impacts as a result, the software should become more mature and strict, and prevent the user from making these kind of errors. Velocity does this. Velocity, since 1.13, is integrated into Paper and uses a key system. Although likely not completely foolproof, at least there is considerable effort into raising the minimum setup security; something which Bungeecord has put fuck-all effort into despite this being a problem for years. I suppose putting a little effort into reducing the amount of kids that have their server hacked isn't a priority; and people wonder why we're moving away from Spigot?

    Don't even get me started on backwards compatibility; not willing to break a single thing for years is not an excuse not to improve your shit.
    • Winner Winner x 2
  18. Andre_601


    Uh... No?
    Java 8 officially found EOL in January 2019. This is literally what searching "When will Java 8 end?" returns:

    But to be fair, Oracle does a shitty job at explaining stuff, since they themself say that Java 8 will receive updates indefinitely (Although I assume those updates require manually changes on your end (A manual update) compared to automatic ones)


    Don't quote me on this, but if at all should BungeeCord actually use Java 11 as it is the current recommended LTS version to use... I guess.
  19. Andre_601


    And I don't think we need to mention stuff like horrible Javadoc documentation, shitty deprecation policy (Essentially what you mentioned), awful implementation of user-requested features or simple MC version support (Just look at how BungeeCord "supports" Hex colors) and so on...
    For someone like me who loves a good looking API and that feels like API's docs are an essential part to the code itself is BungeeCord kind of a joke at this point.
    • Agree Agree x 1