UDP Networking [Solved]

[spynaz]

There are also several free hosts with PHP support, so you can try those. I've been using http://www.atspace.me and http://www.host-ed.net for a while with no problems.

I'll try that.

EDIT: I looked at www.atspace.me and it looks good. So do you get to even have your own website for free too?

[Germanunkol]

Well, the UDP thing you're trying to do works, but only within your LAN as far as I know.

We made a script for a game jam once. The Game sucked, but we were pretty proud to have a working UDP broadcast function. Source code is freely available at: https://entropia.de/GPN12:Gamejam:KarmaExchange
It's all German, but download KarmaExchange.love under "File".

The idea is:

• Server opens, then listenes on a UDP port.
• Client opens, then broadcasts a UDP request.
• All open servers in the network receive the UDP request and reply to it by sending their game's information to the new client.
• Client lists the servers.
• Player chooses a server and connects to it using TCP.

To run the server, unzip the .love file and start the server.lua from the command line with:
lua server.lua

To connect, start the .love file on another PC in your network. (If I remember correctly, UDP broadcast won't work if you have the server and client on the same PC).

[spynaz]

Well, the UDP thing you're trying to do works, but only within your LAN as far as I know.

We made a script for a game jam once. The Game sucked, but we were pretty proud to have a working UDP broadcast function. Source code is freely available at: https://entropia.de/GPN12:Gamejam:KarmaExchange
It's all German, but download KarmaExchange.love under "File".

The idea is:

• Server opens, then listenes on a UDP port.
• Client opens, then broadcasts a UDP request.
• All open servers in the network receive the UDP request and reply to it by sending their game's information to the new client.
• Client lists the servers.
• Player chooses a server and connects to it using TCP.

To run the server, unzip the .love file and start the server.lua from the command line with:
lua server.lua

To connect, start the .love file on another PC in your network. (If I remember correctly, UDP broadcast won't work if you have the server and client on the same PC).

That sounds like an interesting method. I'll check it out. Thanks!

[spynaz]

Wait do you mind explaining your code a bit? Because I'm kind of confused.

[T-Bone]

If you have an old computer you can just install Linux on it and use it as your webserver. No-ip provides free URLs for it. It would have to be on 24/7 but they don't consume that much power (I've measured, my Minecraft server uses less power than a light bulb).

[spynaz]

If you have an old computer you can just install Linux on it and use it as your webserver. No-ip provides free URLs for it. It would have to be on 24/7 but they don't consume that much power (I've measured, my Minecraft server uses less power than a light bulb).

I cannot run my computer 24/7 as it is used for other stuff like school.

[Germanunkol]

Wait do you mind explaining your code a bit? Because I'm kind of confused.

Haha, that's the bad thing about game jams: no time to comment your code.

I didn't write the UDP server, a friend did - but I'll try my best:

Server side:
The server.lua is started, using plain lua. We chose not to use love for this, because for the plain server, all you need is lua socket (see below). This is just a design choice. If you want your server to also be a client, you can do that by simply calling all the stuff I explain below using love, not plain lua.
In linux, do:

Code: Select all

cd KarmaExchange
lua server.lua

On windows, you'll need to install Lua 5.1 and then run the script like this (I guess):

Code: Select all

cd path\to\KarmaExchange
C:\Program/ Files\Lua\Lua.exe server.lua

Or similar.

The server.lua script starts by running the serverSetup() function (see last line in server.lua).
At the beginning of the file, lua socket is required (you might need to install that) and then two udp sockets are created. The socket called udp is just relevant for our game, you will probably not need it. The broadcast socket is what you should look at. You should probably read the introduciton to udp here: http://w3.impa.br/~diego/software/luaso ... ction.html
At the beginning of serverSetup() the udp sockets are bound to the addresses "*" (representing all addresses) and two ports (dfined in common.lua)
Make sure to also add the two lines:

Code: Select all

	assert(broadcast:settimeout(0))
	assert(broadcast:setoption('broadcast', true))

The first one makes sure that any following calls to send and receive functions on the broadcast socket won't lock the game; if there's no data on the sockets, the call will return and your game can continue.

There's lots of stuff related to our game following which you won't need. What's important is the lines

Code: Select all

local b_pack, b_ip, b_port = broadcast:receivefrom()

and

Code: Select all

local success, e_msg = broadcast:sendto(B_SERVER_MESSAGE, B_ADDRESS, B_PORT)

receivefrom needs to be called in a loop, to always accept incoming requests. So if a client broadcasts something on the port that broadcast was bound to, then this call will receive it. b_ip and b_port will return the address and port of the client so we can send back data. That's what we do using the sendto function. So as soon as we get a request, we send back a message. By receiving this returned message, the client will know that there's a server.

Client side
The client is written using the normal Love API: main.lua ist started as always. The client script client.lua is required.
In client.lua, the procedure is similar: a udp and broadcast socket is created. Again, broadcast is the important one.
First, setupBroadcast() is called, which set the same ports and address as the server did. It also sets the socket as a broadcast socket and the timeout to 0.
Then sendBroadcast() is called, which sends any message on the broadcast socket and then returns immediately. After this, in love.update, receiveBroadcast() is called, which continuesly looks for answers. If there's an answer received, it adds the ip and port from which it received from the server list.

So:
1) Client sends request to socket and starts listening for answers
2) Server finds it, replies: "I'm a server"
3) Client receives the reply and notes down from which address it came. Now the client can display that data in a list and the player chooses one. Then your game can connect (using tcp, for example) to that server.

In our script, the messages sent are simply:
B_CLIENT_MESSAGE = "Who's a server?"
B_SERVER_MESSAGE = "I'm a server "
But of course, the server could instead send back a server name, description, how many players are online, what map he's hosting etc... This was just not needed for our game.

I hope this helps somewhat.

If you have an old computer you can just install Linux on it and use it as your webserver. No-ip provides free URLs for it. It would have to be on 24/7 but they don't consume that much power (I've measured, my Minecraft server uses less power than a light bulb).

I use a raspbery pi (even lower power consumption) for my server atm. If you choose this method, I really recommend writing all the scripts in plain lua (or html/php/mysql), because running love on a raspberry pi works but is a hazzle. I also use no-ip.org, it works well with a pi.
But you'll need to remember that these are two different things entirely: One option is the udp broadcast, which works inside a LAN and does not require port forwarding etc. The other one is an online server list which requires each player who hosts a server to open his own ports for the game if you want players from the internet to access his/her server.

[spynaz]

Wait do you mind explaining your code a bit? Because I'm kind of confused.

Haha, that's the bad thing about game jams: no time to comment your code.

I didn't write the UDP server, a friend did - but I'll try my best:

Server side:
The server.lua is started, using plain lua. We chose not to use love for this, because for the plain server, all you need is lua socket (see below). This is just a design choice. If you want your server to also be a client, you can do that by simply calling all the stuff I explain below using love, not plain lua.
In linux, do:

Code: Select all

cd KarmaExchange
lua server.lua

On windows, you'll need to install Lua 5.1 and then run the script like this (I guess):

Code: Select all

cd path\to\KarmaExchange
C:\Program/ Files\Lua\Lua.exe server.lua

Or similar.

The server.lua script starts by running the serverSetup() function (see last line in server.lua).
At the beginning of the file, lua socket is required (you might need to install that) and then two udp sockets are created. The socket called udp is just relevant for our game, you will probably not need it. The broadcast socket is what you should look at. You should probably read the introduciton to udp here: http://w3.impa.br/~diego/software/luaso ... ction.html
At the beginning of serverSetup() the udp sockets are bound to the addresses "*" (representing all addresses) and two ports (dfined in common.lua)
Make sure to also add the two lines:

Code: Select all

	assert(broadcast:settimeout(0))
	assert(broadcast:setoption('broadcast', true))

The first one makes sure that any following calls to send and receive functions on the broadcast socket won't lock the game; if there's no data on the sockets, the call will return and your game can continue.

There's lots of stuff related to our game following which you won't need. What's important is the lines

Code: Select all

local b_pack, b_ip, b_port = broadcast:receivefrom()

and

Code: Select all

local success, e_msg = broadcast:sendto(B_SERVER_MESSAGE, B_ADDRESS, B_PORT)

receivefrom needs to be called in a loop, to always accept incoming requests. So if a client broadcasts something on the port that broadcast was bound to, then this call will receive it. b_ip and b_port will return the address and port of the client so we can send back data. That's what we do using the sendto function. So as soon as we get a request, we send back a message. By receiving this returned message, the client will know that there's a server.

Client side
The client is written using the normal Love API: main.lua ist started as always. The client script client.lua is required.
In client.lua, the procedure is similar: a udp and broadcast socket is created. Again, broadcast is the important one.
First, setupBroadcast() is called, which set the same ports and address as the server did. It also sets the socket as a broadcast socket and the timeout to 0.
Then sendBroadcast() is called, which sends any message on the broadcast socket and then returns immediately. After this, in love.update, receiveBroadcast() is called, which continuesly looks for answers. If there's an answer received, it adds the ip and port from which it received from the server list.

So:
1) Client sends request to socket and starts listening for answers
2) Server finds it, replies: "I'm a server"
3) Client receives the reply and notes down from which address it came. Now the client can display that data in a list and the player chooses one. Then your game can connect (using tcp, for example) to that server.

In our script, the messages sent are simply:
B_CLIENT_MESSAGE = "Who's a server?"
B_SERVER_MESSAGE = "I'm a server "
But of course, the server could instead send back a server name, description, how many players are online, what map he's hosting etc... This was just not needed for our game.

I hope this helps somewhat.

Thanks for taking the time and explaining everything! It just makes so much sense now. I just have one question; Which is the best way to connect the client to the server, using TCP or UDP? I'm not familiar with TCP.

[Germanunkol]

Which is the best way to connect the client to the server, using TCP or UDP? I'm not familiar with TCP.

Short answer:
TCP.

Long answer:It depends on what you want to do.

We used UDP for simplicity reasons, because we already had it implemented and wanted short broadcast-based information. Most information which we sent did not need to be sent reliably.
The main difference is that TCP is connection-based while UDP is not. This means that in TCP, you have neat things like making sure that packets arrive and they arrive in the correct order. This takes a lot of work away from the programmer because it's safe: you send some data and you can be sure it either arrives, or you get an error message.
UDP is connection-less, so it's more like a "fire and forget" algorithm, meaning you might never know if the packets arrive on the other PC (unless you send back an "acknowledge", but then you might just as well use TCP because that's what TCP does internally). This makes UDP faster, but not so much that you need to worry about it, most of the time. For broadcasting video, for example, you'd use UDP while for sending Websites from a web-server to a user, TCP is more reliable.

So if you don't know much about the difference, I definitely recommend use TCP. Later on, if you run into speed-problems (lag), try sending less data and optimizing what you transmit. Then, if there's still too much lag and too much data, then use UDP. There's games that use UDP and TCP at the same time, or which implement a "secure" UDP (with acknowledge) so you can switch between normal UDP and secure UDP depending on what data you're sending (a player's exact position can be sent via UDP because it's usually sent again multiple times a second - if one packet is lost it's no big deal. On the other hand, when a new player connects, his/her player name needs to be sent in reliable mode, because if that info is lost, the other players will just not know about the new player, ever). But this is all much, much more than you'll need for a "simple" multiplayer game - just use TCP.

The reason we use UDP for serverlist-broadcasts is that (to my knowledge) TCP does not support it (since, as I said before, it's connection-based) and because in the server-listing it's not a failure of the program if a packet is lost (the program sends out broadcasts every 5 seconds, so the player just needs to wait a little longer if something is lost - which also usually doesn't happen much in a standard LAN, just through the internet).

Hope that clears it up somewhat. For further reading, just google "udp vs tcp" or similar - there's lots of articles on the topic.

Bottom line:
UDP for serverlist on one port/socket
TCP for server-client connection on another port/socket

[spynaz]

Short answer:
TCP.

Long answer:It depends on what you want to do.

We used UDP for simplicity reasons, because we already had it implemented and wanted short broadcast-based information. Most information which we sent did not need to be sent reliably.
The main difference is that TCP is connection-based while UDP is not. This means that in TCP, you have neat things like making sure that packets arrive and they arrive in the correct order. This takes a lot of work away from the programmer because it's safe: you send some data and you can be sure it either arrives, or you get an error message.
UDP is connection-less, so it's more like a "fire and forget" algorithm, meaning you might never know if the packets arrive on the other PC (unless you send back an "acknowledge", but then you might just as well use TCP because that's what TCP does internally). This makes UDP faster, but not so much that you need to worry about it, most of the time. For broadcasting video, for example, you'd use UDP while for sending Websites from a web-server to a user, TCP is more reliable.

So if you don't know much about the difference, I definitely recommend use TCP. Later on, if you run into speed-problems (lag), try sending less data and optimizing what you transmit. Then, if there's still too much lag and too much data, then use UDP. There's games that use UDP and TCP at the same time, or which implement a "secure" UDP (with acknowledge) so you can switch between normal UDP and secure UDP depending on what data you're sending (a player's exact position can be sent via UDP because it's usually sent again multiple times a second - if one packet is lost it's no big deal. On the other hand, when a new player connects, his/her player name needs to be sent in reliable mode, because if that info is lost, the other players will just not know about the new player, ever). But this is all much, much more than you'll need for a "simple" multiplayer game - just use TCP.

The reason we use UDP for serverlist-broadcasts is that (to my knowledge) TCP does not support it (since, as I said before, it's connection-based) and because in the server-listing it's not a failure of the program if a packet is lost (the program sends out broadcasts every 5 seconds, so the player just needs to wait a little longer if something is lost - which also usually doesn't happen much in a standard LAN, just through the internet).

Hope that clears it up somewhat. For further reading, just google "udp vs tcp" or similar - there's lots of articles on the topic.

Bottom line:
UDP for serverlist on one port/socket
TCP for server-client connection on another port/socket

Thanks a lot for explaining, bro! I see the difference now.