[ENet-discuss] Broadcast Messages through the LAN - Trying an implementation
Lee Salzman
lsalzman1 at cox.net
Mon Mar 16 17:10:20 PDT 2009
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 <david.orejuela.esteban at gmail.com
> <mailto:david.orejuela.esteban at gmail.com>>
>
> 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
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
More information about the ENet-discuss
mailing list