Views
Tutorial:Networking with UDP-TheClient
The complete source for the UDP client
-- to start with, we need to require the 'socket' lib (which is compiled
-- into love). socket provides low-level networking features.
local socket = require "socket"
-- the address and port of the server
local address, port = "localhost", 12345
local entity -- entity is what we'll be controlling
local updaterate = 0.1 -- how long to wait, in seconds, before requesting an update
local world = {} -- the empty world-state
local t
-- love.load, hopefully you are familiar with it from the callbacks tutorial
function love.load()
-- first up, we need a udp socket, from which we'll do all
-- out networking.
udp = socket.udp()
-- normally socket reads block until they have data, or a
-- certain amout of time passes.
-- that doesn't suit us, so we tell it not to do that by setting the
-- 'timeout' to zero
udp:settimeout(0)
-- unlike the server, we'll just be talking to the one machine,
-- so we'll "connect" this socket to the server's address and port
-- using setpeername.
--
-- [NOTE: UDP is actually connectionless, this is purely a convenience
-- provided by the socket library, it doesn't actually change the
--'bits on the wire', and in-fact we can change / remove this at any time.]
udp:setpeername(address, port)
-- seed the random number generator, so we don't just get the
-- same numbers each time.
math.randomseed(os.time())
-- entity will be what we'll be controlling, for the sake of this
-- tutorial its just a number, but it'll do.
-- we'll just use random to give us a reasonably unique identity for little effort.
--
-- [NOTE: random isn't actually a very good way of doing this, but the
-- "correct" ways are beyond the scope of this article. the *simplest*
-- is just an auto-count, they get a *lot* more fancy from there on in]
entity = tostring(math.random(99999))
-- Here we do our first bit of actual networking:
-- we set up a string containing the data we want to send (using 'string.format')
-- and then send it using 'udp.send'. since we used 'setpeername' earlier
-- we don't even have to specify where to send it.
--
-- thats...it, really. the rest of this is just putting this context and practical use.
local dg = string.format("%s %s %d %d", entity, 'at', 320, 240)
udp:send(dg) -- the magic line in question.
-- t is just a variable we use to help us with the update rate in love.update.
t = 0 -- (re)set t to 0
end
-- love.update, hopefully you are familiar with it from the callbacks tutorial
function love.update(deltatime)
t = t + deltatime -- increase t by the deltatime
-- its *very easy* to completely saturate a network connection if you
-- aren't careful with the packets we send (or request!), we hedge
-- our chances by limiting how often we send (and request) updates.
--
-- for the record, ten times a second is considered good for most normal
-- games (including many MMOs), and you shouldn't ever really need more
-- than 30 updates a second, even for fast-paced games.
if t > updaterate then
-- we could send updates for every little move, but we consolidate
-- the last update-worth here into a single packet, drastically reducing
-- our bandwidth use.
local x, y = 0, 0
if love.keyboard.isDown('up') then y=y-(20*t) end
if love.keyboard.isDown('down') then y=y+(20*t) end
if love.keyboard.isDown('left') then x=x-(20*t) end
if love.keyboard.isDown('right') then x=x+(20*t) end
-- again, we prepare a packet *payload* using string.format,
-- then send it on its way with udp:send
-- this one is the move update mentioned above
local dg = string.format("%s %s %f %f", entity, 'move', x, y)
udp:send(dg)
-- and again! this is a require that the server send us an update for
-- the world state
--
-- [NOTE: in most designs you don't request world-state updates, you
-- just get them sent to you periodically. theres various reasons for
-- this, but theres one *BIG* one you will have to solemnly take note
-- of: 'anti-griefing'. World-updates are probably one of biggest things
-- the average game-server will pump out on a regular basis, and greifing
-- with forged update requests would be simple effective. so they just
-- don't support update requests, instead giving them out when they feel
-- its appropriate]
local dg = string.format("%s %s $", entity, 'update')
udp:send(dg)
t=t-updaterate -- set t for the next round
end
-- there could well be more than one message waiting for us, so we'll
-- loop until we run out!
repeat
-- and here is something new, the much anticipated other end of udp:send!
-- receive return a waiting packet (or nil, and an error message).
-- data is a string, the payload of the far-end's send. we can deal with it
-- the same ways we could deal with any other string in lua (needless to
-- say, getting familiar with lua's string handling functions is a must.
data, msg = udp:receive()
if data then -- you remember, right? that all values in lua evaluate as true, save nil and false?
-- match is our freind here, its part of string.*, and data is
-- (or should be!) a string. that funky set of characters bares some
-- explanation, though.
-- (need summary of patterns, and link to section 5.4.1)
ent, cmd, parms = data:match("^(%S*) (%S*) (.*)")
if cmd == 'at' then
-- more patterns, this time with sets, and more length selectors!
local x, y = parms:match("^(%-?[%d.e]*) (%-?[%d.e]*)$")
assert(x and y) -- validation is better, but asserts will serve.
-- don't forget, even if you matched a "number", the result is still a string!
-- thankfully conversion is easy in lua.
x, y = tonumber(x), tonumber(y)
-- and finally we stash it away
world[ent] = {x=x, y=y}
else
-- this case shouldn't trigger often, but its always a good idea
-- to check (and log!) any unexpected messages and events.
-- it can help you find bugs in your code...or people trying to hack the server.
-- never forget, you can not trust the client!
print("unrecognised command:", cmd)
end
-- if data was nil, then msg will contain a short description of the
-- problem (which are also error id...).
-- the most common will be 'timeout', since we settimeout() to zero,
-- anytime there isn't data *waiting* for us, it'll timeout.
--
-- but we should check to see if its a *different* error, and act accordingly.
-- in this case we don't even try to save ourselves, we just error out.
elseif msg ~= 'timeout' then
error("Network error: "..tostring(msg))
end
until not data
end
-- love.draw, hopefully you are familiar with it from the callbacks tutorial
function love.draw()
-- pretty simple, we just loop over the world table, and print the
-- name (key) of everything in their, at its own stored co-ords.
for k, v in pairs(world) do
love.graphics.print(k, v.x, v.y)
end
end
-- And thats the end of the udp client example.
-- into love). socket provides low-level networking features.
local socket = require "socket"
-- the address and port of the server
local address, port = "localhost", 12345
local entity -- entity is what we'll be controlling
local updaterate = 0.1 -- how long to wait, in seconds, before requesting an update
local world = {} -- the empty world-state
local t
-- love.load, hopefully you are familiar with it from the callbacks tutorial
function love.load()
-- first up, we need a udp socket, from which we'll do all
-- out networking.
udp = socket.udp()
-- normally socket reads block until they have data, or a
-- certain amout of time passes.
-- that doesn't suit us, so we tell it not to do that by setting the
-- 'timeout' to zero
udp:settimeout(0)
-- unlike the server, we'll just be talking to the one machine,
-- so we'll "connect" this socket to the server's address and port
-- using setpeername.
--
-- [NOTE: UDP is actually connectionless, this is purely a convenience
-- provided by the socket library, it doesn't actually change the
--'bits on the wire', and in-fact we can change / remove this at any time.]
udp:setpeername(address, port)
-- seed the random number generator, so we don't just get the
-- same numbers each time.
math.randomseed(os.time())
-- entity will be what we'll be controlling, for the sake of this
-- tutorial its just a number, but it'll do.
-- we'll just use random to give us a reasonably unique identity for little effort.
--
-- [NOTE: random isn't actually a very good way of doing this, but the
-- "correct" ways are beyond the scope of this article. the *simplest*
-- is just an auto-count, they get a *lot* more fancy from there on in]
entity = tostring(math.random(99999))
-- Here we do our first bit of actual networking:
-- we set up a string containing the data we want to send (using 'string.format')
-- and then send it using 'udp.send'. since we used 'setpeername' earlier
-- we don't even have to specify where to send it.
--
-- thats...it, really. the rest of this is just putting this context and practical use.
local dg = string.format("%s %s %d %d", entity, 'at', 320, 240)
udp:send(dg) -- the magic line in question.
-- t is just a variable we use to help us with the update rate in love.update.
t = 0 -- (re)set t to 0
end
-- love.update, hopefully you are familiar with it from the callbacks tutorial
function love.update(deltatime)
t = t + deltatime -- increase t by the deltatime
-- its *very easy* to completely saturate a network connection if you
-- aren't careful with the packets we send (or request!), we hedge
-- our chances by limiting how often we send (and request) updates.
--
-- for the record, ten times a second is considered good for most normal
-- games (including many MMOs), and you shouldn't ever really need more
-- than 30 updates a second, even for fast-paced games.
if t > updaterate then
-- we could send updates for every little move, but we consolidate
-- the last update-worth here into a single packet, drastically reducing
-- our bandwidth use.
local x, y = 0, 0
if love.keyboard.isDown('up') then y=y-(20*t) end
if love.keyboard.isDown('down') then y=y+(20*t) end
if love.keyboard.isDown('left') then x=x-(20*t) end
if love.keyboard.isDown('right') then x=x+(20*t) end
-- again, we prepare a packet *payload* using string.format,
-- then send it on its way with udp:send
-- this one is the move update mentioned above
local dg = string.format("%s %s %f %f", entity, 'move', x, y)
udp:send(dg)
-- and again! this is a require that the server send us an update for
-- the world state
--
-- [NOTE: in most designs you don't request world-state updates, you
-- just get them sent to you periodically. theres various reasons for
-- this, but theres one *BIG* one you will have to solemnly take note
-- of: 'anti-griefing'. World-updates are probably one of biggest things
-- the average game-server will pump out on a regular basis, and greifing
-- with forged update requests would be simple effective. so they just
-- don't support update requests, instead giving them out when they feel
-- its appropriate]
local dg = string.format("%s %s $", entity, 'update')
udp:send(dg)
t=t-updaterate -- set t for the next round
end
-- there could well be more than one message waiting for us, so we'll
-- loop until we run out!
repeat
-- and here is something new, the much anticipated other end of udp:send!
-- receive return a waiting packet (or nil, and an error message).
-- data is a string, the payload of the far-end's send. we can deal with it
-- the same ways we could deal with any other string in lua (needless to
-- say, getting familiar with lua's string handling functions is a must.
data, msg = udp:receive()
if data then -- you remember, right? that all values in lua evaluate as true, save nil and false?
-- match is our freind here, its part of string.*, and data is
-- (or should be!) a string. that funky set of characters bares some
-- explanation, though.
-- (need summary of patterns, and link to section 5.4.1)
ent, cmd, parms = data:match("^(%S*) (%S*) (.*)")
if cmd == 'at' then
-- more patterns, this time with sets, and more length selectors!
local x, y = parms:match("^(%-?[%d.e]*) (%-?[%d.e]*)$")
assert(x and y) -- validation is better, but asserts will serve.
-- don't forget, even if you matched a "number", the result is still a string!
-- thankfully conversion is easy in lua.
x, y = tonumber(x), tonumber(y)
-- and finally we stash it away
world[ent] = {x=x, y=y}
else
-- this case shouldn't trigger often, but its always a good idea
-- to check (and log!) any unexpected messages and events.
-- it can help you find bugs in your code...or people trying to hack the server.
-- never forget, you can not trust the client!
print("unrecognised command:", cmd)
end
-- if data was nil, then msg will contain a short description of the
-- problem (which are also error id...).
-- the most common will be 'timeout', since we settimeout() to zero,
-- anytime there isn't data *waiting* for us, it'll timeout.
--
-- but we should check to see if its a *different* error, and act accordingly.
-- in this case we don't even try to save ourselves, we just error out.
elseif msg ~= 'timeout' then
error("Network error: "..tostring(msg))
end
until not data
end
-- love.draw, hopefully you are familiar with it from the callbacks tutorial
function love.draw()
-- pretty simple, we just loop over the world table, and print the
-- name (key) of everything in their, at its own stored co-ords.
for k, v in pairs(world) do
love.graphics.print(k, v.x, v.y)
end
end
-- And thats the end of the udp client example.
