Not Enough Bandwidth (NEB)

Introduction

NEB uses various methods to save as much network traffic as possible during Minecraft gameplay, while remaining transparent to both mods and players.

In the ZZZZ Dataset from TeaCon Jiachen, compared to raw uncompressed data, NEB can theoretically reduce the server's outbound traffic to 7.6% of its original size, with an actual measured value of approximately 13.8%.

In tests conducted in a Vanilla environment, the server outbound traffic was reduced to 18% of its original size. Theoretically, as the number of installed mods increases, the content transmitted over the network becomes larger and more complex, leading to better compression performance.

Press Alt+N in-game to easily view the network traffic status.

Main Features

Compact Packet Header

Optimize CustomPacketPayload encoding and decoding by replacing the packet header Identifier (Packet Type) with a compact index. This reduces the mod network packet header overhead to a fixed 3-4 bytes, instead of the length of the string corresponding to the network packet type.

The index structure is as follows:

Fixed 8 bits header

┌------------- 1 byte (8 bits) ---------------┐ │ function flags │ ├---┬---┬-------------------------------------┤ │ i │ t │ reserved (6 bits) │ └---┴---┴-------------------------------------┘

• i = indexed (1 bit)
• t = tight_indexed (1 bit, only valid if i=1)
• reserved = 6 bits (for future use)

Indexed packet type

• If i=0 (not indexed):

┌---------------- N bytes ---------------- │ Identifier (packet type) in UTF-8 └-----------------------------------------

• If i=1 and t=0 (indexed, NOT tight):

┌-------- 1 byte ---------┬-------- 1 byte --------┬-------- 1 byte --------┐ ┌------------- 12 bits ---------------┬-------------- 12 bits --------------┐ │ namespace-id (capacity 4096) │ path-id (capacity 4096) │ └-------------------------------------┴-------------------------------------┘

• If i=1 and t=1 (indexed, tight):

┌--------- 1 byte ----------┬--------- 1 byte ---------┐ ┌--------- 8 bits ----------┬--------- 8 bits ---------┐ │namespace-id (capacity 256)│ path-id (capacity 256) │ └---------------------------┴--------------------------┘

Then packet data.

It occupies 3 bytes when the network packet namespace and its corresponding path are fewer than 256, and 4 bytes when greater than 256. This supports up to 4096 mods, with 4096 channels per mod.

Aggregation and Compress

Optimize the situation where vanilla often produces a large number of small network packets. Intercept transmission at the Connection level, assemble them into one large network packet every 20ms, and send it after compression.

┌---┬----┬----┬----┬----┬----┬----... │ S │ p0 │ s0 │ d0 │ p1 │ s1 │ d1 ... └---┴----┴----┴----┴----┴----┴----... └--packet 1---┘└--packet 2---┘ └----------compressed----------┘

• S = varint, size of compressed buf
• p = prefix (medium/int/utf-8)， type of this subpacket
• s = varint, size of this subpacket
• d = bytes, data of this subpacket

Delayed Chunk Cache

In Vanilla, when a player moves, the server instructs the client to immediately forget the chunks behind them; if the player returns to the original position, the full chunk data must be sent again. By delaying this "forgetting", the chunk transmission traffic generated when poking around can be saved.

Config

Modify the configuration file at config/NotEnoughBandwidthConfig.json.

compatibleMode

WORK INDEPENDENTLY ON CLIENT AND SERVER.

Whether to enable compatibility mode. If set to true, the blackList below will be used.

blackList

WORK INDEPENDENTLY ON CLIENT AND SERVER.

The blacklist for compatibility mode. Packets listed here will be skipped by NEB. By default, it includes a list of Velocity-related packets, but you can add new packets as needed.

To ensure packet ordering, packets in the blacklist will interrupt the ongoing aggregation. If there are many packets in the blacklist, or if the corresponding packets are sent too frequently, the efficiency of aggregation-compression will decrease.

contextLevel

WORK INDEPENDENTLY ON CLIENT AND SERVER.

The context window size used for compression. Valid values are integers from 21 to 25, representing 2MB to 32MB respectively. The default is 23 (8MB).

A larger context window results in better compression and bandwidth savings, but consumes more memory.

For a server with 100 players, a setting of 25 will result in approximately 3200MB of additional memory usage.

dccSizeLimit, dccDistance, dccTimeout

ONLY WORK ON SERVER.

The maximum number of cached chunks, cached chunk distance, and cache timeout allowed by the Delayed Chunk Cache (DCC). Larger values may consume more memory, while smaller values may trigger updates more frequently.