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 <[email protected]>:
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 <[email protected]>:
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
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
