[ENet-discuss] How to temporarily keep a host from accepting incoming connection requests?

Benoit Germain bgermain at ubisoft.fr
Thu Jun 17 04:34:22 PDT 2010


> -----Message d'origine-----
> De : enet-discuss-bounces at cubik.org [mailto:enet-discuss-
> bounces at cubik.org] De la part de Ruud van Gaal
> Envoyé : jeudi 17 juin 2010 12:30
> À : 'Discussion of the ENet library'
> Objet : Re: [ENet-discuss] How to temporarily keep a host from
> accepting incoming connection requests?
> 
> 
> A boolean can be just 1 bit in a 32-bits flags field. Not sure if the
> 'host'
> struct already has such a field.
> Also, you don't want to waste a boolean but then want to add:
> 
>   enet_uint32 sessionPassword;
> 
> to the host struct. How's that any less wasteful?

Cursory examination didn't reveal an existing host field where I could stuff my bit. So I had to add a field anyway, and structure padding would cause even a single byte to add 4 to the total size. Not that it really matters anyway, but I like to keep things tidy :-). And anyway, I need the filtering.

> 
> I agree with Lee; your original problem states you want to 'ignore
> incoming
> connection requests'. A boolean that would be called
> 'ignoreIncomingConnectionRequests' seems to be logical. A
> 'sessionLocked'
> seems a more abstract term than that. And simple things...
> 
> But perhaps I'm missing the point where a 'sessionLocked' would still
> be
> useful in a release scenario...

Yes I need this. See my other questions about LAN-matchmaking: The session master has a matchmaker host, and another host that will be used for actual session replication (let's call it p2p). The latter has connection filtering enabled. Each putative session client has a host that connects to one or more master matchmaker hosts, and receives the filter upon successful connection. When the client decides to join a particular session, it creates its own p2p host that connects to the master's using the filter. It prevents accidental connection from other hosts to the master's p2p host. Again, this has nothing to do with security, it is just here to make connection and peer management as simple as possible at the application level by hiding unwanted connections.


More information about the ENet-discuss mailing list