Or you can create a separate host that'll constantly broadcast, like once every 3 seconds, the server's information (IP, Port, Server Name, "game ID"). That way the clients will get the connection information only, instead of trying to connect to a broadcasting host.
On Sat, Aug 15, 2009 at 1:21 AM, <[email protected]> wrote: > > Thanks for the replies. I do seem to have had some success > > with setting the server with: > > > > address.host = ENET_HOST_ANY; > > > > And then the client as address.host = ENET_HOST_BROADCAST; > > > > Once connected it seems to work fine, but it does seem flaky > > to connect sometimes. I've also found that decreasing the > > timeout time for the client seems to have improved matter > > eg enet_host_service(sClient, &event, 100) (from like 5000). > > I'm not sure it's really a good idea to be using ENet to do broadcasts. The > problem is if there happens to be two hosts on the local network listening > on the same port, they're *both* going to get the connection request and > that's obviously going to confuse the client. Even if you establish a > connection to one host, if another one comes up while you're still talking > to the first, it's going to be confused as well, since it'll think you're > talking to it. > > I think the best solution is as Emmanuel said: you just do a single packet > broadcast (using normal sockets, not ENet) "are there any servers?" then > the > servers can respond (with a broadcast of their own) "I am at IP w.x.y.z". > Then you can do a normal ENet connection to w.x.y.z. That way you don't > have > to worry about multiple servers being on the local network or anything like > that. > > Dean. > > _______________________________________________ > ENet-discuss mailing list > [email protected] > http://lists.cubik.org/mailman/listinfo/enet-discuss >
_______________________________________________ ENet-discuss mailing list [email protected] http://lists.cubik.org/mailman/listinfo/enet-discuss
