I'm considering profiling DMP network usage and possibly modifying how packets are packed to reduce their size. However, this will obviously break on-the-wire compatibility.

Is this something you care about - i.e. will you reject a Pull Request that breaks On-The-Wire compatibility? If so then obviously I'll find somewhere else on the project to do some work!

What's on-the-wire compatibility? I've never seen that term used before.

Sorry, I mean on the wire as in the binary format of the packets. I'd like to change how packets are encoded/decoded to make them smaller (if profiling reveals this may be useful).

i.e. If you change how packets are encoded then all the code to read/write packets won't break (that's not concerned with the on-the-wire format) but an old client communicating with a new client will fail. The first change I'd suggest in this case would be a version flag so packets could be sent with an older version to an older client!

Godarklight is already considering breaking the protocol for 0.1.6 to add stuff like compression. (See here)

I'm closing this as it's not technically a bug report, but I've already gone most of the way with this.

I know my MessageWriter/Reader code might not make a lot of sense (It doesn't use network byte order, so big-endian servers are up poop creek, KSP only runs on little endian), but it bit-packs without headers (unless it's an array where it uses a 4 byte int header), which is about as efficient as you can get. However, for ConfigNode string data, I intend to use System.IO.Compression on systems that support it. I remember it doesn't work for everyone though - It hangs in ancient versions of mono so it will still need to be tested in a thread and made optional.

And just for future reference, any time you go changing a MessageWriter/MessageReader message, you must bump PROTOCOL_VERSION: https://github.com/godarklight/DarkMultiPlayer/blob/master/Common/Common.cs#L20