You should be using raw UDP traffic for this. Do not use ENet's
host/peer system. The way we do this in AssaultCube is:
Every server binds a UDP info socket (just used for pinging the server)
to the same exact port. Game traffic is done on a different port which
differs per server, only the info socket is the same port value for all
servers. The SO_REUSEADDR option is set on this info socket before the
address bind is done, which allows multiple info sockets to live on the
same ip address and port. SO_REUSEADDR causes any packets sent to the
broadcast address to be delivered to ALL sockets bound to that port.
This allows multiple servers to coexist on the same computer and be
pinged properly, so long as their game traffic is at least on different
ports. The server then replies back with information about which port
its actual game traffic is on and other info back to the client that
pinged it.
Just structure your pings so they are UDP packets, small enough not to
fragment, sent out at some constant interval (like once every few
seconds). If you lose packets, its no big deal since you're resending
frequently at constant intervals anyway.
Lee
David Orejuela wrote:
Another aproximation: Connecting broadcast
We can connect to a ENET_HOST_BROADCAST host so any Server will reply
our connect Request. Then we do all the server data information
interchange and disconnect from it.
Repeating this proccess we could obtain information from all the
servers on the LAN. But there are problems with this solution. When we
do a enet_host_connect, the server
can be the same that answered the last enet_host_connect, there are
unorderer responses.
Does somebody know a solution for it?
2009/3/16 David Orejuela <[email protected]
<mailto:[email protected]>>
Hi!
First, I'm not much experienced with enet so sorry if I'm wrong in
some parts of the following discussion.
I've readed the following post: "How to send a broadcast message
without connecting to any one?".
I have the same problem, a client that search servers in a LAN,
wich are not registred as enet peers of a host.
So the default enet_host_broadcast function doesn't fit to my
intentions.
I must send a broadcast packet through the LAN network, so I coded
the following:
int
enet_host_network_broadcast (ENetHost * host_origin, ENetPacket *
packet)
{
ENetAddress target_address;
ENetBuffer buffer;
target_address.host = ENET_HOST_BROADCAST;
target_address.port = host_origin->address.port;
buffer.data = packet->data;
buffer.dataLength = sizeof(packet->data);
return enet_socket_send (host_origin->socket, &target_address,
&buffer, 1);
}
In my "FindServers" client function, I use the new
"enet_host_network_broadcast" enet function,
sending a FIND_SERVERS_REQUEST message. But this message is never
read by the server.
Reading some posts in the mailing list I found a discussion about
Multicast/Broadcast addresses (Giuseppe Greco giuseppe.greco at
agamura.com <http://agamura.com/>
Tue Sep 4 11:09:39 PDT 2007), that talks about broadcast datagrams
discarding and shows the following code
static int
enet_protocol_handle_incoming_commands (
ENetHost * host, ENetEvent * event)
{
...
if (peer -> state == ENET_PEER_STATE_DISCONNECTED ||
peer -> state == ENET_PEER_STATE_ZOMBIE ||
(host -> receivedAddress.host != peer -> address.host &&
peer -> address.host != ENET_HOST_BROADCAST))
return 0;
...
}
The questions are:
I will be able to receive the FIND_SERVERS_REQUEST message if I
modify "enet_protocol_handle_incoming_commands" removing "peer ->
address.host != ENET_HOST_BROADCAST" condition?
Are there some kind of risks doing it?
------------------------------------------------------------------------
_______________________________________________
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
