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

[Lee Salzman]

The behavior is pretty much as always: the connection effectively has 
only as many channels as the minimum of what both requested. If client 
requests 100, and server only wants 3, then both get only 3. If client 
wants 2, but server allows 16, both get only 2.

Lee

M. Rijks wrote:
> Awesome! You've made at least one person on this globe do a happy 
> dance. :)
>
> Just one question - what will the host do if the client attempts to 
> open more channels? I wouldn't want to refuse the connection, because 
> if you're an incompatible client you want to have at least some basic 
> communication to inform the client. I would merely want to make sure 
> incoming data on 'illegal' channels is dropped. Would this be taken 
> care of as well?
>
> Thanks!
>
> Martin
>
> Quoting Lee Salzman <lsalzman1 at cox.net>:
>
>> Well, I guess I'll just go with the API I have, rather than the API I
>> want, so for better or worse:
>>
>> /** Limits the maximum allowed channels of future incoming connections.
>>    @param host host to limit
>>    @param channelLimit the maximum number of channels allowed; if 0,
>> then this is equivalent to ENET_PROTOCOL_MAXIMUM_CHANNEL_COUNT
>> */
>> extern void enet_host_channel_limit (ENetHost * host, size_t 
>> channelLimit);
>>
>> :)
>>
>> 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
>>>>>>
>>>>>> ___