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

[Lee Salzman]

Packets pile up regardless if you don't service the host enough to 
dispatch all of them. At this point a channel is just a temporary 
waiting area for packets that are not ready to be dispatched, and those 
waiting packets need to be allocated either way.

Lee

M. Rijks wrote:
> Ah - forgive me but I thought that each channel was an independent 
> queue. It wasn't the opening of channels I was concerned about, but 
> more the fact that they may grow extensively when piled up with 
> (unwanted) incoming data.
>
> One (not so elegant) solution that does not break up the API is to 
> configure the channel limit separately, i.e. a new, separate function 
> call with which you can override the default limit of 255 channels.
>
> Martin
>
>
> Quoting Lee Salzman <lsalzman1 at cox.net>:
>
>> 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
>>>>