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

[Philip Bennefall]

Hi lee,

My answer would be a definite no. While I do see a slight advantage in the 
flexibility that this offers, I don't think breaking the API for the sake of 
this feature is justified. Perhaps put it on a future to do list and only do 
it if you make a new major ENet version with other API differences so that 
this change can come as part of the bundle.

Kind regards,

Philip Bennefall
----- Original Message ----- 
From: "Lee Salzman" <lsalzman1 at cox.net>
To: "Discussion of the ENet library" <enet-discuss at cubik.org>
Sent: Friday, May 14, 2010 4:48 PM
Subject: Re: [ENet-discuss] ENet 1.2.2 work-in-progress


> At one point that may have been an issue, but now there is no performance 
> cost to the channels, just memory, and the limit is still at most 255 
> channels, and each channel is consuming 56 bytes of memory, so we're 
> talking at worst 255*56==14280 bytes of wasted memory.
>
> Now, a channel limit parameter could probably be added to the 
> enet_host_create() call, but this is at the cost of breaking the API for 
> all existing ENet users. The question is, is this something people want 
> badly enough to warrant that?
>
> Lee
>
> M. Rijks wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> ENet-discuss mailing list
>> ENet-discuss at cubik.org
>> http://lists.cubik.org/mailman/listinfo/enet-discuss
>>
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss