UDP networking for multiplayer game

[grump]

Send a UDP message to 255.255.255.255, i. e. send a broadcast message. All devices listening on the same network on that destination port will receive it and can respond to it.

Edit: it's a little bit more complicated for IPv6, but not by much. Please support IPv6

[keharriso]

You can send a message to all hosts on the LAN by using the target address of 255.255.255.255. Something like this:

Code: Select all

local socket = require "socket"
local sock = socket.udp()
sock:setsockname("*", 55555)
assert(sock:setoption("broadcast", true))

Then simply broadcast to everyone with:

Code: Select all

assert(sock:sendto(msg, "255.255.255.255", 55555))

EDIT: grump beat me to it and is right about IPv6

[mxmlnbndsmnn]

Thanks for the quick replies! I am going to try it out this evening.

Some questions in advance:
What exactly is the meaning of the "*" in

Code: Select all

sock:setsockname("*", 55555)

?
I've read the UDP networking tutorial when I started and for some reason I could not get this running for my game. Instead, I had to give a specific address (server-side). (So for the server and the client the same "server address" was hardcoded)
Server:

Code: Select all

udp:setsockname(serverAdress, serverPort)

Client:

Code: Select all

udp:setpeername(serverAdress, serverPort)

My guess would be that after the server send such a message to all clients (and empty nodes) in the LAN, I can use getsockname() at the server to know the server IP address, right? And similar to that the client responds to the broadcast message with a sendto -> again use getsockname() for the client... at least that's what my understanding looks like atm.

I'm looking forward to test it asap thanks for helping!

[keharriso]

Some questions in advance:
What exactly is the meaning of the "*" in

Code: Select all

sock:setsockname("*", 55555)

?

The "*" lets the socket know to accept messages from all interfaces. For example, if you used "127.0.0.1" instead of "*", it would only accept messages from localhost.

I've read the UDP networking tutorial when I started and for some reason I could not get this running for my game. Instead, I had to give a specific address (server-side). (So for the server and the client the same "server address" was hardcoded)
Server:

Code: Select all

udp:setsockname(serverAdress, serverPort)

Client:

Code: Select all

udp:setpeername(serverAdress, serverPort)

My guess would be that after the server send such a message to all clients (and empty nodes) in the LAN, I can use getsockname() at the server to know the server IP address, right? And similar to that the client responds to the broadcast message with a sendto -> again use getsockname() for the client... at least that's what my understanding looks like atm.

I'm looking forward to test it asap thanks for helping!

You need to call:

Code: Select all

sock:setsockname("*", port)

on both the client and the server. Then the server can send a message to all clients with:

Code: Select all

sock:sendto(msg, "255.255.255.255", port)

Then the clients receive the message with:

Code: Select all

msg, address, port = sock:receivefrom()

They can respond to the server with:

Code: Select all

sock:sendto(msg, address, port)

The server can send and receive exactly the same as the client does, with

Code: Select all

sock:receivefrom()

returning the message and address and port of the client that sent it..

[mxmlnbndsmnn]

Alright, I am trying to implement that approach but ... on the server I cannot do this:

Code: Select all

assert(udp:sendto("promo", "255.255.255.255", serverPort))

with this

Code: Select all

udp:setsockname("*", serverPort)

It says (something like) that the specified host is unknown.

The client on the other hand says that the used address is not compatible with the protocol when I do receivefrom. :c

Edit: When I posted this, your last post was not yet visible to me, keharisso.

Edit 2: Yep, your steps are mostly what I did ... using the udp:setsockname("*", serverPort) on both client and server (I only did it on the server side) the client now "works" in terms of not producing the compatibility error any more. But the first error still occurs: the server does not send a broadcast message. Not knowing where it results from I tried it on 1 PC, 2 PCs with LAN and "normal"/dynamic and also static addresses. I even disabled IPv6 for now in my windows LAN settings... no changes.

[keharriso]

A few things:

1. You can't use the same port for client and server on the same host. You need a separate clientPort for the client (and broadcast to this port from the server).

2. In the client you need to use:

Code: Select all

udp:setsockname("*", clientPort)

3. Don't use udp:setpeername in the client.

[mxmlnbndsmnn]

I used setpeername because the tutorial included it, but okay.

Still the broadcast wont work :c Setting the broadcast option to true returns 1 as it should. But the host is still "unknown".

[keharriso]

Sorry, where is host unknown?

I attached the code that seems to be working for me.

[mxmlnbndsmnn]

The

Code: Select all

assert(udp:sendto("promo", "255.255.255.255", clientPort))

Does not work. It produces an error that says that the specified host (I guess the broadcast address) is unknown.
Same error with your files. So it seems to be device/OS dependend? Using love 11.1 on Windows 10. I'm only in a common home Wifi (deactivating it made no changes) and right now I'm only testing on one local machine. I'm confused-

[keharriso]

The

Code: Select all

assert(udp:sendto("promo", "255.255.255.255", clientPort))

Does not work. It produces an error that says that the specified host (I guess the broadcast address) is unknown.
Same error with your files. So it seems to be device/OS dependend? Using love 11.1 on Windows 10. I'm only in a common home Wifi (deactivating it made no changes) and right now I'm only testing on one local machine. I'm confused-

You're right, it's an OS issue. Works on Debian Stretch, doesn't work on Windows 10. I tried playing around with the code and couldn't come up with any solution. The question is where the bug is. I'll look into it a bit more.