[ENet-discuss] Death by a thousand cuts

[Lee Salzman]

Enough of the packet structure has changed that you can't even connect 
to the old protocol and find out the old protocol is being used, not 
without using the old protocol to begin with. So, I'm not worrying about 
backwards compatability.

That might make some users cringe, but I'm not obviating 1.0 by making 
these improvements. What's in 1.0 is perfectly good, just that it gets 
bogged down if you're sending bazillions of small packets. Only upgrade 
when it is convenient or necessary for you to do so.

It's interesting to note, though, that in Sauerbraten we have always 
used a custom UDP protocol for our master server, so that clients 
already were advertised which protocol version the server was using 
before they even tried to connect. Well, that and we always made so many 
changes to the game, that even if the networking protocol didn't change, 
  different Sauerbraten releases were mostly incompatible.

Lee

Bjørn Lindeijer wrote:
>>So I went through ENet and managed to shave off a minimum of 12 bytes
>>from the protocol headers. In the context of the above example, that
>>saves the client from sending an extra 1.8 KB/s and the server from
>>sending 10.8 KB/s, minimum. It required some trickery to fit 32 bit time
>>stamps and sequence numbers into 16 bits, but it seemed to work out
>>rather well.
>>
>>So, FYI: there may be a 1.1 coming out soon.
> 
> 
> It is great to hear that you're working on optimizing this library.
> One concern though is compatibility, about which you didn't mention
> anything. Am I right to assume that for example an ENet 1.1 using
> server will not be able to communicate with an ENet 1.0 using client?
> If this is true, could there be a custom connection failed error so
> that is it easy for the application to feedback the problem to the
> user?
> 
> Regards,
> Bjørn
>