Sending multiple values with 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
Ovidios
Prole
Posts: 29
Joined: Thu Dec 04, 2014 12:00 pm
Location: Berlin, Germay

Sending multiple values with LUBE

Post by Ovidios »

I've just started using LUBE and now want to send multiple tables from the server to the client. Is there any way to differentiate between the different send-calls, for example by using tags?
Thanks in advance! ^^
User avatar
cohadar
Prole
Posts: 25
Joined: Mon May 04, 2015 5:46 am
Contact:

Re: Sending multiple values with LUBE

Post by cohadar »

Make a new table:
{ msg_type = "player_death", table1 = table1, table2 = table2, ... }
{ msg_type = "position_update", table1 = table1, table2 = table2, table3 = table3 }
User avatar
Ovidios
Prole
Posts: 29
Joined: Thu Dec 04, 2014 12:00 pm
Location: Berlin, Germay

Re: Sending multiple values with LUBE

Post by Ovidios »

But when I try to pack a table with subtables to a string using lube.bin:pack() I get an error message saying the type table is not supported... :/ Do I have to use another table serialization library? Could you recommend a simple one?
User avatar
I~=Spam
Party member
Posts: 206
Joined: Fri Dec 14, 2012 11:59 pm

Re: Sending multiple values with LUBE

Post by I~=Spam »

Yep! Here is a very good one! https://github.com/gvx/Ser

Although if you are going to have tables rereferencing themselves you will need the slower but more advanced: https://github.com/pkulchenko/serpent

EDIT: Replaced img tag with url tag. :crazy:
Last edited by I~=Spam on Thu May 07, 2015 3:58 pm, edited 1 time in total.
My Tox ID: 0F1FB9170B94694A90FBCF6C4DDBDB9F58A9E4CDD0B4267E50BF9CDD62A0F947E376C5482610
User avatar
Ovidios
Prole
Posts: 29
Joined: Thu Dec 04, 2014 12:00 pm
Location: Berlin, Germay

Re: Sending multiple values with LUBE

Post by Ovidios »

I'm using the first one now since I'm doing very basic stuff and it works perfectly! Thank you two very much! :awesome:
User avatar
cohadar
Prole
Posts: 25
Joined: Mon May 04, 2015 5:46 am
Contact:

Re: Sending multiple values with LUBE

Post by cohadar »

I am using enet with serpent, it works fine for now.

I detected serpent loses floating-point precision of numbers and have already suggested a fix to the author.

Presumably a perfect netcode serialization library would look like this:
  • Support nested tables
  • Do NOT support cycles, it is slow and it is responsibility of coder to make good input data to netcode
  • All keys MUST be strings, speed is the reason again
  • It should NOT use loadstring for deserialization, it would be a huge security hole.
I believe the best solution would in fact be to write love.pack and love.unpack methods in C++

EDIT:
Forgot to add that all values are either tables or primitive types.
User avatar
zorg
Party member
Posts: 3436
Joined: Thu Dec 13, 2012 2:55 pm
Location: Absurdistan, Hungary
Contact:

Re: Sending multiple values with LUBE

Post by zorg »

I~=Spam wrote:Yep! Here is a very good one! Image

Although if you are going to have tables rereferencing themselves you will need the slower but more advanced: https://github.com/pkulchenko/serpent
For the record, ser can serialize lövecraftian tables too. :3
(And ser is also faster than serpent)

Edit:
cohadar wrote:It should NOT use loadstring for deserialization, it would be a huge security hole.
Also related: Smallfolk, by the same person.
Me and my stuff :3True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
User avatar
I~=Spam
Party member
Posts: 206
Joined: Fri Dec 14, 2012 11:59 pm

Re: Sending multiple values with LUBE

Post by I~=Spam »

cohadar wrote:It should NOT use loadstring for deserialization, it would be a huge security hole.
You do know that you can use pcall and setfenv to make these perfectly safe right?
cohadar wrote:I believe the best solution would in fact be to write love.pack and love.unpack methods in C++
No it wouldn't change the security hole. Unless you rewrite the lua parser so that the C++ parses the lua code itself safely. (And that is a HUGE can of worms with security.) Seriously though. Lua has this already built in. http://lua-users.org/wiki/SandBoxes So it is actually safer to write the sandbox in lua...

Just sandbox the lua code! This will do all of the work for you: https://github.com/APItools/sandbox.lua @cohadar try to break out of this sandbox. I don't think you can.

I have written a lua sandbox but it isn't exactly what you are looking for here. Mine allows pausing untrusted lua code inside of sandboxed coroutines. While the library above forcefully exits the lua code if it takes too long and can only do one at a time. Because of how luajit works internally I actually have to use a small c library to achieve this. But this isn't what you need. :)
My Tox ID: 0F1FB9170B94694A90FBCF6C4DDBDB9F58A9E4CDD0B4267E50BF9CDD62A0F947E376C5482610
User avatar
cohadar
Prole
Posts: 25
Joined: Mon May 04, 2015 5:46 am
Contact:

Re: Sending multiple values with LUBE

Post by cohadar »

pcall and setfenv are just more unneeded overhead.
even loadstring is an overhead.

We do not NEED full lua language parser for this, just parser that can read booleans, numbers, strings and tables.
Data parser is trivial to implement, and it would be extremely fast.

Now that I have written this I realize that implementing data parser is NOT something we should do.
There already exist good data parsers for a standard data-interchange format: JSON

What we need inside Love is a good json library.
And by good I mean one that preserves floating point precision.

For example serpent fails floating-preservation:

Code: Select all

local text = serpent.line( { pi = math.pi } )
ok, t = serpent.load( text )
assert( ok )
assert( math.pi == t.pi )
I suspect same is true of LUBE and Ser

EDIT: yep, Ser also fails

Code: Select all

	local text = ser( { pi = math.pi } )
	t = loadstring( text )
	assert( math.pi == t().pi )
User avatar
I~=Spam
Party member
Posts: 206
Joined: Fri Dec 14, 2012 11:59 pm

Re: Sending multiple values with LUBE

Post by I~=Spam »

cohadar wrote:We do not NEED full lua language parser for this, just parser that can read booleans, numbers, strings and tables.
Data parser is trivial to implement, and it would be extremely fast.
Ahh ok I understand what you are saying now. ;) It still doesn't change that what you said before about it being unsafe is completely false.
cohadar wrote: For example serpent fails floating-preservation:

Code: Select all

local text = serpent.line( { pi = math.pi } )
ok, t = serpent.load( text )
assert( ok )
assert( math.pi == t.pi )
I suspect same is true of LUBE and Ser

EDIT: yep, Ser also fails

Code: Select all

	local text = ser( { pi = math.pi } )
	t = loadstring( text )
	assert( math.pi == t().pi )
This is not their fault check it out.

Code: Select all

lua
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> print(math.pi)
3.1415926535898
> assert(math.pi == 3.1415926535898)
stdin:1: assertion failed!
stack traceback:
	[C]: in function 'assert'
	stdin:1: in main chunk
	[C]: in ?
> 
cohadar wrote:Now that I have written this I realize that implementing data parser is NOT something we should do.
There already exist good data parsers for a standard data-interchange format: JSON

What we need inside Love is a good json library.
And by good I mean one that preserves floating point precision.
I disagree. Json data cannot contain references to itself. (Like how lua tables can reference themselves.) Also I seriously doubt the speed boost would be enough to even matter. LuaJIT has optimized this to the point it can't get much faster. Just stick with lua tables. It works perfectly with lua with no add ons and with serpent you can serialize any table (as long as there is no userdata). This is not the case with json. Sure a json parser could be written in lua rather than a c library but then you loose the potential speed boost you were hoping to gain.
My Tox ID: 0F1FB9170B94694A90FBCF6C4DDBDB9F58A9E4CDD0B4267E50BF9CDD62A0F947E376C5482610
Post Reply

Who is online

Users browsing this forum: No registered users and 47 guests