[ENet-discuss] ENet 1.2.2 work-in-progress
M. Rijks
enet at forge.dds.nl
Fri May 14 13:23:30 PDT 2010
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
More information about the ENet-discuss
mailing list