Currently, modem transmissions can be made as quickly as the Java code can handle making them. In a test singleplayer world, I can get a computer to broadcast on the order of 500 000 packets per second. This effectively floods the entire event queue of any other computer listening in to the same channel, making it inoperable.

This capacity for computers to transmit hundreds of thousands of packets per second is so undesirable that basically any competent server forbids it in some way. As a result, enforcing at least a loose cap on transmission rate at the software level should be able to prevent the worst of those issues from happening to begin with.

When it comes to securing traffic, the issue is even worse. Asymmetric cryptography operations are disproportionately expensive and the receiver can't tell whether it should trust an incoming handshake packet until it performs the operation. Even protocols running on regular computers have to handle this, the Wireguard whitepaper has an entire section on capping handshakes under load. Their solution isn't applicable here because it relies on IP addresses being somewhat hard (though not impossible) to acquire/spoof, which doesn't fit our model.

Potential Solution 1: Enforcing a Fixed Cap per Modem or Transmitting Computer

Something like one message for every 1 ms makes it hard to flood queues, although it doesn't solve the asymmetric cryptography issues since they clock in at ~30 ms per operation. There are at least 2 problems with this: First, programs that transmit large amounts of data would need to buffer them up and send the entire thing at once. Second, modem.transmit doesn't yield, so it can't yield without making a breaking change, as a result the program must block during the transmission period.

Potential Solution 2: Adding an Effort Parameter and Filtering

Another approach would be to add a new "effort" parameter to a transmission, where transmissions with higher effort values take longer to make. The receiver then could filter the incoming packets to those that contain a minimum effort value, and drop everything else, this filter value could dynamically rise and lower depending on load. There are also problems with this approach: Mainly, it is very specific and most programs wouldn't benefit from it without changes, and it also has the yielding problem of the above proposal.

Maybe I could pitch in with an idea as well, there could be some sort of range radius curve applied to each channel, as it is with frequency (the higher the frequency, the lower the radius, and the more data it transmits), that way players could fine tune their tooling while keeping a sort of backwards compatibility

maybe add a config value for how many modem messages can be sent by one computer, and how many can be sent on a channel?