[ENet-discuss] Channel count at server

[M. Rijks]

Thank you for your reaction. I'm sorry, Enet is rather black-box for me - 
I'm relatively new to C++ (although not to programming itself) and I still 
find it hard to find my answer in someone else's code, so I'm particularly 
happy to leave the nitty-gritty network implementation to someone else!

The 'game server' would actually be anyone who has a copy of the game and 
hosting the session. These would be gamers, who are not always typically 
familiar with (or able to influence) firewall configuration - that's why I 
want to set up a server that lists the sessions online (this one in turn 
*would* be administrated by someone who knows his business) and which will 
help in establishing connections between hosts and clients using a technique 
comparable to a STUN server. I'm using Enet for this as well.

The thing is, the client opens up a session by connecting to another 
computer, not knowing if it's a server listing the sessions or a host (since 
I want them to be able to connect to hosts directly, transparently). I wish 
this to service different kind of games - one game would be needing far more 
channels than the other. But since they might connect to a host directly, 
they'll open up a connection using their required amount of channels. The 
server hosting the channels needs only one, but since it's the client that 
sets the channel count, I'm afraid that it's going to run into heavy 
resource use if a lot of clients connect simultaneously. I was looking for 
information on how to limit that.

I hope I have explained myself with this.

----- Original Message ----- 
From: "Daniel Aquino" <mr.danielaquino at gmail.com>
To: "Discussion of the ENet library" <enet-discuss at cubik.org>
Sent: Wednesday, June 24, 2009 5:02 AM
Subject: Re: [ENet-discuss] Channel count at server


i think when a client connects you can see how many channels they
allocated in their peer stucture... if they don't follow your rules
then they aren't written by you or aren't friendly so just drop
them...  or just leave it up to them...

look into how enet initializes it's not very complex code... you can
clearly see that the number of channels is used to allocate space for
the list of channels (or other things)...  So it's really just a way
to limit the amount of memory used if you know you only want 1
cahnnel.. then there is no reason to allocate space for 255 channel
structs (or whatever it creates)...

Are your end users going to run servers ?  They should be technical
enough to simply forward a  port so I don't see why STUN and nat
punching or anything would be needed...  unless you want players to
directly connect to each other in a mesh...




On Tue, Jun 23, 2009 at 3:53 PM, M. Rijks<enet at forge.dds.nl> wrote:
> Hi everyone,
>
> Another query which I hope someone can shed some light on.
>
> My client library (which I intend to use for more than one game) connects
> either to a game server or a kind of lobby server that also acts as a STUN
> server, helping clients connect to game servers. To make things easier for
> end users, they will always connect to an IP not knowing whether it's the
> (STUN) lobby server or the game server - they retrieve a list of sessions
> (more than one in the case of a lobby, just one in the case of a game
> server) and when they select a session to join they are redirected to the
> game server (if it turns out they're on a lobby server and not on a game
> server).
>
> What I'm slightly concerned with is that in Enet, it seems that the client
> decides how many channels are used for communication. That's unfortunate
> because I'd like the client to always use a very large number (let's say 
> all
> 255) of channels when connecting to a a game server, but for the lobby
> server it would need just one channel as there isn't much data to pass and
> it's all in one reliable sequence. Both clients and servers connect to the
> lobby server, and clients would only be connected for a short while 
> however
> a lobby server could potentially serve as many clients as it can hold
> connections - and each connected client would occupy 255 channels...
>
> My questions are:
>
> 1. Am I correct to assume that the connecting client choses the amount of
> channels to open? The interface seems to confirm this.
> 2. If so, what are the repercussions performance-wise and memory-wise, how
> does this escalate?
> 3. Is there any way to make sure the lobby server 'sticks' to the single
> dedicated channel?
>
> Any help appreciated, thanks!
>
>
> _______________________________________________
> 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