LUBE (Networking Library)

[Sparx]

Hi there again,

I really need your help!!! LUBE doesn't seem to flush too fast send data via UDP, which I definately need and which would be expected....

I don't know, whether i use LUBE wrong or this is a major BUG.

You don't have the smallest clue how long it took me realizng that THIS is the problem of pings growing into outerspace.

Please tell me if im wrong, if I'm not i would be sooo glad about a solution.

[bartbes]

Can you explain some more, as I myself had lag on some occasions, but on others I have none at all, it'd be great if I knew what the problem might be.

[Sparx]

I hope i don't missunderstand how UDP is working but this is what occurs:

I am sending data via LUBE 0.04 (from server to 1 client and at the same time from 1 client to server)
The ages of the ariving packages are growing the longer my programm runs. Im speaking about ca. 2-3 seconds delay each 10 seconds the programm runs.
If I close the client the server still gets all the packeges which were send many seconds ago.

btw: I didn't use the checkping at serverside, because this didn't work properly while runing the rest of my programm

[bartbes]

Weird, though I did seem to have lag I've never had packages coming to the server after the client's been closed, though I don't know how the current LUBE version behaves.., AFAIK you're the only one with that problem.
@everyone: Had the same problem?

[Sparx]

This is the code i am actually working with. It tries to do a serverside latency compensation via linear extrapolation.

I just set the code for 1 client, because i first want to solve this problem before integrating more then 1 client....
I hope someone can help i would be very glad

Lines 16 and 20 are quoted because the client doesn't except server set velocities for it's own character.
For the other players this is eventualy going to be important to do a clientside latency compensation, but i have to do a fieldtest which one feels better..

[bartbes]

It looks like it should work, have you tried commenting out the love.timer.sleep calls yet? (just in case) That's the only thing I can think of.. else we need to diagnose the problem with LUBE.

EDIT: I read over one of your earlier questions, yes it is possible to create multiple connections, you want to know how? (it's on the wiki btw)

Code: Select all

--CLIENT
--1 connection code:
love.client.Init()
--multiple connections code:
local conn = love.client()

--SERVER
--1 connection code:
love.server.Init(port)
--multiple connections code:
local conn = love.server(port)

[Sparx]

I started without it.. it actually works better with this because(i guess) there are not as many packets send as without the sleep, so it takes longer to create a longer UDP queue.

[bartbes]

Weird.. I don't have the time to look at it right now, but I'll search my code when I do.

BTW, look at my previous post, I edited it. (and I want to add it returns a connection object, not an identifier, so you just do something like: client:setCallback(cb))

[Sparx]

Thanks for answering this fast! I would love to hear a reaction how this programm is running on other systems, respectivly what you think is the problem of very old data ariving, even if client is closed.

Is there any project working with lube that has a good latency management? I mean if pings stay low you don't need compensation... so a programm where pings naturaly stay low or have a good integrated compensation method.

BTW: I don't know where to find a lube wiki... in the löve wiki there is just the lube-docs...

[bartbes]

Didn't I put it in the docs? I thought I had? No I haven't

Anyway, I just had a moment of insight (thank my toilet for that) and when I have the time (tomorrow, probably) I'm going to create: Lag-o-meter 3000 (the name is on purpose). It'd be nice if it becomes a diagnostic tool someday