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

[M. Rijks]

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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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