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

[M. Rijks]

Ah, I see. I suppose I can check channelCount to know the number of  
channels ultimately allocated. I hadn't tried using enet_peer_send on  
a channel that wasn't allocated, so I don't know its behavior in such  
cases but I assume this means it will just return <0 (failure).

Excellent Lee, thank you very much for your efforts - much appreciated!

Martin


Quoting Lee Salzman <lsalzman1 at cox.net>:

> 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
>>>>>>>
>>>>>>> ___
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss