Packets in LUBE

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
User avatar
Sekaru
Prole
Posts: 17
Joined: Sun Oct 07, 2012 5:09 pm

Packets in LUBE

Post by Sekaru »

I've recently managed to get LUBE to work and I've noticed a pretty big issue. Is there any way to send specific packets when you need to from both client and server and handle them in the order they were sent in?

For example:

Code: Select all

-- client
function sendPlayerLoc
   udp:send(player.x)
   udp:send(player.y)
end

Code: Select all

--server
function handlePlayerLoc
   player.x = udp.readdata() -- obviously aren't the actual functions
   player.y = udp.readdata()
end
Thanks in advance.
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Packets in LUBE

Post by bartbes »

Yeah, using tcp.
User avatar
Sekaru
Prole
Posts: 17
Joined: Sun Oct 07, 2012 5:09 pm

Re: Packets in LUBE

Post by Sekaru »

bartbes wrote:Yeah, using tcp.
So just using the tcpServer:receive and tcpServer:send?

Like,

Code: Select all

-- client
function sendSomething
   tcpServer:send(player.x)
end
But how would the client know which function to call to receive the data?
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Packets in LUBE

Post by bartbes »

Using a tcpClient, of course. TCP is a protocol meant to deliver reliably and in order. UDP is lossy, packets can be lost, arrive in different order, etc, the advantage is that this allows you to not care about old packets, so it's generally more suitable for realtime games.
User avatar
Sekaru
Prole
Posts: 17
Joined: Sun Oct 07, 2012 5:09 pm

Re: Packets in LUBE

Post by Sekaru »

bartbes wrote:Using a tcpClient, of course. TCP is a protocol meant to deliver reliably and in order. UDP is lossy, packets can be lost, arrive in different order, etc, the advantage is that this allows you to not care about old packets, so it's generally more suitable for realtime games.
Well what I mean is if I need to send different things like sendPlayerMove or sendPlayerDeath, how will the client know the index of the sending procedure?

So like in VB (let the hate begin) I would do something like this in the server:

Code: Select all

tcp.write(sPlayerMove)
tcp.write(player.x)
And in the client I'd have:

Code: Select all

If Index = sPlayerMove then HandlePlayerMove()
And in the Handle function you'd have the reading. Is there anything like that?
User avatar
bartbes
Sex machine
Posts: 4946
Joined: Fri Aug 29, 2008 10:35 am
Location: The Netherlands
Contact:

Re: Packets in LUBE

Post by bartbes »

Oh, well, you don't. Instead, with everything you send what it is, and read that on the other end.
User avatar
Przemator
Party member
Posts: 107
Joined: Fri Sep 28, 2012 6:59 pm

Re: Packets in LUBE

Post by Przemator »

When you read from a TCP socket, you're guaranteed to read the data in order it was sent. If ALL of your data has to be delivered, then you have to use TCP. UDP is good for data that expires after a short time (if it's old, it's useless) or that is replaced by new data.

If you send player state via UDP, you might include a timestamp, and only process the data if the timestamp is larger than the maximum of already received data from the client.
User avatar
Sekaru
Prole
Posts: 17
Joined: Sun Oct 07, 2012 5:09 pm

Re: Packets in LUBE

Post by Sekaru »

bartbes wrote:Oh, well, you don't. Instead, with everything you send what it is, and read that on the other end.
So if I wanted to send different things in different orders I couldn't? Would that mean that I would just have to send everything every time I want to send something?
Przemator wrote:When you read from a TCP socket, you're guaranteed to read the data in order it was sent. If ALL of your data has to be delivered, then you have to use TCP. UDP is good for data that expires after a short time (if it's old, it's useless) or that is replaced by new data.

If you send player state via UDP, you might include a timestamp, and only process the data if the timestamp is larger than the maximum of already received data from the client.
Yeah I understand that. I just can't understand how there isn't a central function that checks the index of the message which then passes it onto a function that determines which function to use to handle the data.
User avatar
Przemator
Party member
Posts: 107
Joined: Fri Sep 28, 2012 6:59 pm

Re: Packets in LUBE

Post by Przemator »

Sekaru wrote:So if I wanted to send different things in different orders I couldn't? Would that mean that I would just have to send everything every time I want to send something?
What are you saying here? :P I don't understand. You receive a packet, then you read what it is, then you do something with it. With TCP, you are sure that ALL things will come through, and that they will come in order of being sent.

I can imagine a scenario:

player A sends data:

Code: Select all

"action|hit|B"
"chat|gotcha B!"
"action|hit|C"
"chat|now i killed C!"
TCP server gets all that in the right order, while UDP server might get sth like this:

Code: Select all

"action|hit|C"
"action|hit|B"
"chat|now i killed C!"
So, the order isn't correct and one message is missing.
User avatar
Sekaru
Prole
Posts: 17
Joined: Sun Oct 07, 2012 5:09 pm

Re: Packets in LUBE

Post by Sekaru »

Okay. What I'm doing is trying to send different things at different times so the packets will usually not be sent in the same order each time.

Let's take a simple game for example where you have skills, combat and moving.

Assuming we have 3 players online, let's assume they all send these things:
P1 Sends: Moving, Combat, Skills
P2 Sends: Combat, Skills, Moving
P3 Sends: Skills, Moving, Combat

As you can see they all send data in a different order. How does the server know to execute the function that handles Moving if that is sent first and so on for the rest of them?
Post Reply

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 3 guests