[FIX] SocketBuffer v1.1 - Buffers traffic to limit number of packets

Discussion in 'Bukkit Tools' started by nickrak, Jun 19, 2011.

Thread Status:
Not open for further replies.
  1. Offline


    SocketBuffer - Buffer traffic to limit number of packets
    Version: 1.1

    This application buffers traffic to that data is only sent 10 times per second. This should resolve issues for people having issues with firewalls that implement flood control mechanisms. If only a client is using SocketBuffer, then all outbound data from the client will be buffered. If the client and the server run SocketBuffer, then traffic will be buffered bi-directional. CLI Only. Don't ask for a GUI, it won't happen. This is a low-level patch designed for server administrators and network-savvy users who have confirmed that flood-control mechanisms are responsible for their disconnects.

    This application is non-bukkit/minecraft dependent and will not be updated unless there is a problem with it.

    Download from GitHub
  2. Offline


    So basically if I understand this correctly. Some times when people get disconnected in Minecraft it can be caused by a firewall which doesn't like the information exchange between the server and the client happening so often?

    And by limiting this information flow to only 10 times a second it should stop issues like these.

    The thing i'm wondering now is, how often does minecraft, when not limited. send info back and forth?

    Each time a frame is rendered / is it linked to the FPS you're running on?

    And basically this causes a 100 ms lagg, right? is this noticable ingame? And if it is, could you add options which have you choose between certain settings? Like 20 times a second or something. Maybe this solution works perfect for certain people but 100 ms is a tiny bit annoying. Then they could try 50 ms. See if it still works. Not sure if the 10 times a second is already the limit here for every firewall before flood control will be triggered or just a safe number to ensure all firewalls their flood control will not be triggered.

    Anyway nice tool if it works. Another thing, is there a way to know if you're getting disconnected by flood control mechanisms? Is this like a real bad thing of getting disconnected every minute or could be getting disconnected every 30 minutes it as well?

    Keep up the good work!
  3. Offline


    Be for warned tho adding high buffer times will increase latency its bit of a trade of really less disconnects or less latency.
  4. Offline


    That's the idea.

    When not loading the world right after a login, just wandering around and breaking a few blocks, building a bit. It averages around 10-20 packets per second, all under 100 bytes each. A standard ethernet frame is a maximum size of 1500 bytes. Each small packet includes a routing header which is 54 bytes. Given that most packets are under 100 bytes. The amount of bandwidth that is consumed is increased by 50% over what Minecraft is actually trying to send. At about 3-5 packets per 10 milliseconds. You reduce 162 bytes of extra data to 54 bytes. Plus you cut your packet count down by a factor of 3-5.

    In the course of one minute of idle, I recorded 660 packets. (11 packets per second). With this tool, you'd drop to at worst, 220 packets. Saving a total of 23760 bytes per minute (23.2kb/m) of header data.

    Yes this causes a up to a 100ms lag. It's most noticeable when the world is loading right after you log in. You see the world load in quick bursts instead of smoothly. But after that you can't tell since the chunks are so far away. It doesn't increase the total time to download data, just delays when you download data.

    100ms was chosen because it's barely noticeable after you've loaded the area around you, and it's enough that no firewall's flood control should ever be set off by that much data. I'll could make it configurable, but post load the most latency it will add is 100ms each way at login. The Minecraft client holds local copies of block changes so the delay should not change mining and building in any way. It may however create a delay in when you see other player's block events.

    The way I found out was by running wireshark from both ends and seeing a non-provoked RST packet from the client computer.

    The person I wrote this for was getting disconnected about 2 minutes after login. If the trouble is after 30 minutes, it may not be your firewall. If you're concerned about it, record a minecraft session with Wireshark and I'll gladly take a look at it.
  5. Offline


    hmmm when i start the .exe than closed it.. is this normal ?
  6. Offline


    This is a CLI-based application, you have to use command prompt to run it.
  7. Offline


    Is it possible to have the source code for this executable, or for it to be recompiled for 32 bit linux?
  8. Offline


    There's an updated download link to GitHub, source is available there. I suggest compiling with QtCreator since I've included the project file and it'll include all the dependencies. Let me know how it goes.
  9. Offline


    Builds just fine. I took the lazy man's route, and since I already had all the required libs installed, I just ran qmake && make in the src/ dir. Thank you for putting this up!
  10. Offline


    There are two ZIPs at GitHub for mac OSX, SocketBuffer-1.1-osx-dependencies.zip and SocketBuffer-1.1-osx.zip, but no explanation of what to do with them. Does anyone know if there are installation instructions somewhere?
  11. Offline


    You need SocketBuffer-1.1-osx.zip.

    If you do not have Qt >=4.7 then you'll need to grab the dependencies zip and just dump them in the same folder with the contents of the first zip.

    If you're not sure then just download the executable and try to run, if it fails, then grab the dependencies.
Thread Status:
Not open for further replies.

Share This Page