[ENet-discuss] ENet 1.2.2 work-in-progress

[M. Rijks]

As little as I have looked into Enet source I have no idea if this  
constitutes a big change or a small change, but one thing  would  
definitely appreciate: in my understanding it is the client who  
decides the number of channels to be opened at the host. I'd like to  
be able to tell the host the maximum number of channels a client is  
allowed to open, and simply drop data that comes in on 'illegal'  
channels without queing it in the channel.

The reason I'd like to have this is that I'm trying to design a  
multi-purpose game networking library on top of Enet, and that it is  
theoretically possible for anyone to force-open lots of channels on  
'foreign' (different game) hosts, and start hogging resources on that  
host. Knowing the developer crowd I'm aiming at I know some will try  
and do just that to try and bring someone's host down. :( I would also  
think this could be a potential issue for any other Enet user if they  
do not cater for any kind of protection themselves, but do correct me  
if I am wrong.

Thanks for considering,

Martin


Quoting Lee Salzman <lsalzman1 at cox.net>:

> Just so we're clear: this is NOT a release announcement. Didn't want to
> get your hopes up. :)
>
> But recently I added some features to ENet CVS that people were bugging
> me about, so I thought I'd just tell you all what they were if you were
> in need of them.  Or maybe you just want to test them out and make sure
> they're stable (which they should be as far as I could test so far).
>
> 1. I fixed some places in the event dispatch where it was walking over
> all the channels to find appropriates packets to hand off to the user,
> such that is basically no longer does evil stuff like this. In other
> words: there is no longer any performance penalty for using high
> numbers of channels, per se, although it still needs to allocate memory
> for each channel, for each client, when you first create the host. But
> the dispatching costs of using them are gone.
>
> 2. I added a no_memory callback that allows you to override ENet's
> standard out-of-memory behavior, which was simply to call abort.
> Someone simply wanted the API functions to simply return errors in this
> case, and I revised some internals so that you can safely make a null
> no_memory handler and get that behavior. The default is just to call
> abort, which keeps ENet behaving as it always did, unless you decide to
> supply that callback.
>
> 3. I used the packed attribute on some sensitive protocol structures
> that were causing some protocol incompatibilities on platforms like
> ARM+GCC, which appeared to use much different alignment rules than what
> x86 and friends were.
>
> 4. Nathan Brinks contributed a less crufty autoconf build system.
>
> That out of the way, are there any not too difficult things people
> would like to see in 1.2.2?
>
> Lee
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss