1. Guest, as per the stickied thread, this forum has not been in use since 2014. All bugs and feature requests should be posted to JIRA.

Feature Bungee Network.

Discussion in 'Bugs & Feature Requests' started by Asphodan, May 7, 2013.

  1. What would it take to allow BungeeCord to connect to another BungeeCord?

    One might ask: Why?

    For my example, we'll take a server that is under steady DDOS attacks. Attack hits the server, server goes down, life goes on.

    Now, in most cases, this can be waited out or we can do something about it - split the load. Bring up multiple VPSes, put BungeeCord on them and point them at your servers. This raises costs, but can generally be effective. For basic servers, this works well.

    Now let's take into consideration BungeeCord's growing library of different plugins; they have a single BungeeCord in mind. BungeeBans maintains a ban database, and if someone connects to that BungeeCord then they're subject to it.

    However, in our example, what if there are multiple Bungee instances and someone connects to another one of those servers? Now they've bypassed BungeeBan.Same with BungeeChat+, if you connect through a different Bungee server then your chat will not be synced with the other ones.

    This can be mitigated by various levels of syncing; MySQL for databases, maybe IRC for chat. Not ideal, when BungeeCord is a perfectly viable system already. But it does not scale well for additional frontend.

    So on to the solution: Bungee connecting to Bungee. We could have a single Bungee server (Prime Bungee), that communicates with all of the Minecraft servers, and multiple Bungee instances (Proxies) on VPSes.

    If we have BungeeBans, BungeeChat, and all the other various Bungee plugins we might need in the future on Bungee Prime - it can communicate with the various proxies, removing the need to adapt around limitations.

    I know there are networks that redid their locations.yml to be in a database, this would no longer be necessary - Locations.yml would be read/set by the Bungee instance closest to the MC server, the Prime.

    I've asked about this before, and was met with responses roughly equating "Why bother?"
    I still think this is a perfectly acceptable route to attack mitigation, when compared alternate solutions.
    • Like Like x 1
  2. PhanaticD


    or just tunnel to one bungee instance. and I believe andyhuang the person who posted this method tried it and it didnt work that well
  3. I know it doesn't work well, because there's no support for the finer data sharing.

    I'm requesting that Bungee team make effort to make it more possible.
  4. The servers that did this chose to move it to a database because after about 2,500 players, BungeeCord can't handle it on one machine. Very large servers need to run multiple Bungee instances on seperate machines. I don't think you'll find a single Bungeecord server who would use that setup if they can't load balance on one machine.

    Furthermore, multiple proxies are not exactly the best anti ddos protection system out there. I know, I have tried to set one up, and it sucks. Not only does it lag horribly, but you're piping data across another tunnel now, which means an additional point of failure. One only has to look at Transhit (see what I did there?) Shield's performance to know why the VPN proxying does not work.
  5. md_5

    Administrator Developer

    We would go p2p on Bungee clustering; all Bungees connect to all servers. Adding an extra Bungee in between makes no sense.
    See the github issue to continue discussion.