> -----Message d'origine-----
> De : [email protected] [mailto:enet-discuss-
> [email protected]] 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.
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss

Reply via email to