In current cobalt, instant messages are put in a queue and guaranteed to be given to the OS at some point, even when being rate limited due to a congested state.

This is probably a good default behavior, but for example in multiplayer game networking, it is not unusual to have types of messages where newer ones completely supersede older ones and keeping obsolete messages around to send them later is actually harmful.

One way to better support this use case would be to add another MessageKind which acts like Instant, except that all messages of this kind are cleared from the message queue after each call to Connection::send_packet.

Another, somewhat lower level, way would be to allow the application to attach some kind of application defined type id (maybe just an u8 or u32) to each (Instant) message and have a method to remove all messages of a certain type from the message queue.

Or you could have a new MessageQueueFilter type parameter on Connection, which also defines some kind of meta data to be attached to each message and has a filter method to decide whether to drop a message from the queue. This is of course a major change and might not be the best idea. This would however allow applications to, for example, drop messages if they aren't sent out within a certain time frame.

I'm not sure what's causing this, sometimes when I start up my project, it will spam PacketLost after connecting even though no packets are going out anyways.

Why?

The MIT license requires reproducing countless copies of the same copyright
header with different names in the copyright field, for every MIT library in
use. The Apache license does not have this drawback, and has protections from
patent trolls and an explicit contribution licensing clause. However, the
Apache license is incompatible with GPLv2. This is why Rust is dual-licensed as
MIT/Apache (the "primary" license being Apache, MIT only for GPLv2 compat), and
doing so would be wise for this project. This also makes this crate suitable
for inclusion in the Rust standard distribution and other project using dual
MIT/Apache.

How?

To do this, get explicit approval from each contributor of copyrightable work
(as not all contributions qualify for copyright) and then add the following to
your README:

## License

Licensed under either of
 * Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or http://www.apache.org/licenses/LICENSE-2.0)
 * MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT)
at your option.

### Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted
for inclusion in the work by you shall be dual licensed as above, without any
additional terms or conditions.

and in your license headers, use the following boilerplate (based on that used in Rust):

// Copyright (c) 2015 t developers
// Licensed under the Apache License, Version 2.0
// <LICENSE-APACHE or
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT
// license <LICENSE-MIT or http://opensource.org/licenses/MIT>,
// at your option. All files in the project carrying such
// notice may not be copied, modified, or distributed except
// according to those terms.

And don't forget to update the license metadata in your Cargo.toml!

Contributor checkoff

• @BonsaiDen

I propose per packet encryption via session keys per packet when connecting to the server for the first time. The session key (a symmetric key) will be generated for both the client and server using a public key (an asymmetric key) using something like the Diffie–Hellman key exchange protocol.

After the session key is established per connection; we use the session key to encrypt outgoing client traffic and decrypt it at the server, and vice-versa because the client and server now share a secret key.

There are already a few crypto libraries for Rust such as Ring, and bindings to OpenSSL that could be used.

Of course, this is just an idea, and there might be a better way to go about encrypting network traffic.

The handler for compressing a packet expects compression to be done in-place and allows no mechanism for the 'compressed' form to be larger than the original. Lossless compression cannot compress arbitrary data so expecting packets to always become smaller is nonsensical.