Sending multiple values with LUBE

[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!

[cohadar]

Make a new table:
{ msg_type = "player_death", table1 = table1, table2 = table2, ... }
{ msg_type = "position_update", table1 = table1, table2 = table2, table3 = table3 }

[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?

[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.

[Ovidios]

I'm using the first one now since I'm doing very basic stuff and it works perfectly! Thank you two very much!

[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.

[zorg]

Yep! Here is a very good one!

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.
(And ser is also faster than serpent)

Edit:

It should NOT use loadstring for deserialization, it would be a huge security hole.

Also related: Smallfolk, by the same person.

[I~=Spam]

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?

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.

[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 )

[I~=Spam]

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.

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 ?
> 

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.