Custom LuaUI network messaging

Post by **Auswaschbar** » 16 Oct 2007, 13:43

Even on some 2 MBps lines, the upload bandwidth is
still around 100KBps

2 MB/s == 16MBit DSL
2MBit/s DSL == 250 KB/s

For comparison:
Engine client to server upload: ~200 Byte/s
Engine Server to client: 400 - 500 Byte/s per client (depends how much players do, but usually wont go higher than this) = ~8 KB/s for a 16 player game

Post by **trepan** » 16 Oct 2007, 13:45

16 Mbps -> 2 MBps
'b' = bit
'B' = byte

LordMatt · Post by **LordMatt** » 17 Oct 2007, 00:48

Well this didn't cause any significant lag in OTA so there must be a way to implement it so that it isn't a big deal.

Zpock · Post by **Zpock** » 17 Oct 2007, 01:54

Maybe just draw the allies cursor location instead of the camera? Then you just need to send 2 numbers (the map x,z of the mouse).

I think this would be actually cooler then seeing the viewports, since you can see what the other player is doing as well as a rough picture of where his screen is (has to be somewhere around his mouse).

Post by **trepan** » 17 Oct 2007, 02:31

I've used the OTA demo, so I don't really know what the allied
camera indicators look like, if they were choppy, etc... One thing
to consider is that the mouse cursor isn't always on the map,
and that the same is true for center viewpoint, and camera
location.

I do have an allied camera widget already implemented (with
bandwidth reduction by avoiding duplicate camera states), but I
need to finish the frustum / ground intersections lines.

LordMatt · Post by **LordMatt** » 17 Oct 2007, 03:19

trepan wrote: I do have an allied camera widget already implemented (with
bandwidth reduction by avoiding duplicate camera states), but I
need to finish the frustum / ground intersections lines.

That would be win of the purest form.

It's been a while since I played OTA, but I think the camera was pretty fluid. In OTA, the camera came straight down and didn't zoom, however, so the amount of information that needed to be transferred may have been less. If you knew the size of your allies screen resolution, all you would need to send was the coordinates of one corner of the rectangle or the center, and you could reconstruct the whole thing on the other end. I don't know if that's how they did it, however.

You could probably implement the same thing in spring if you wanted. If you sent only the xy coordinates of the center of the viewport you could show a dot where they were looking. Alternatively, you could probably send at the start of the game the screen resolution and angle of that the camera makes with the vertical and then only send the x, y, and z coordinates of the center, and reconstruct the trapazoid from that. That would involve maths and programming that I don't know, however so maybe its more complicated than that.

BigHead · Post by **BigHead** » 17 Oct 2007, 08:50

Mouse cursor position:
minimum 5 updates / second
host output = 16 * 15 * 320 = 76.8 KBps
Someone should rewrite spring network client-server code into peer2peer. Any volunteers?

Post by **Auswaschbar** » 17 Oct 2007, 14:59

Someone should rewrite spring network client-server code into peer2peer. Any volunteers?

Adding p2p functionality is a 1-hour-job, but what would it do except moving the traffic to clients?

@trepan
What do you think about the following (example with camera state):
normal state: server dont send camera update messages to client A
client A starts camera state widget -> telling the server -> server starts sending camera updates to client
client A stops camera widget -> telling the server -> server dont send camera updates to client a any more

It wouldnt add any traffic to people who dont want it. If you tell me some details i would help you implementing it in client/server code.

Post by **trepan** » 17 Oct 2007, 15:41

I'd rather leave it the way that it is for the moment. Client selective messaging
would allow for easier cheats. The other advantage to the current system is
that all players will have complete replay files, and you'll be able to watch a
replay with the same camera view as any player (using freecam and some lua).

BigHead · Post by **BigHead** » 17 Oct 2007, 16:01

but what would it do except moving the traffic to clients?

128 bytes / second / player

Current IO:
client output = 128 bytes
client input = 16 * 128 bytes / sec = 2.048 KBps
host input = 15 * 128 bytes / sec = 1.92KBs
host output = 16 * 15 * 128 = 30.72 KBps

P2P IO:
client output = 15 * 128 bytes / sec = 1.92KBs (> 128 bytes)
client input = 15 * 128 bytes / sec = 1.92KBs
host input = client input = 1.92KBs
host output = client output = 1.92KBs (<< 30.72 KBps)

I doubt it's a 1-hour-job so we most likely have different understanding "adding p2p functionality"

lurker · Post by **lurker** » 17 Oct 2007, 16:15

The thing about p2p is that many clients won't be able to connect to each other, so you have to do it in hybrid form.

But a lot of this discussion of bandwidth management is pointless, I think. You don't have to send an exact position by any means. If you send the camera position in elmos, and orientation in 256ths of a circle, then that's only 9 bytes per update. Likewise, sending the cursor as an xz position fits into only 4 bytes.

Current IO:
9*2 + 4*5 = 38, not going to worry about overhead yet
client output = 38 bytes
client output = 15 * 38 bytes / sec = .6 KBps
host output = 16 * 15 * 38 = 9 KBps
And that's with camera and cursor. Just camera would only need half that.
The overhead could add a bit depending on the amount of new packets per second, etc. I don't remember, how often are host packets sent at present when no orders are issued? But either way, sending a rough camera in a fraction of the data is far better imo.

Forboding Angel · Post by **Forboding Angel** » 17 Oct 2007, 16:58

All you need is 1 person with a crap, malware, disease infested computer and a subpar ISP and this entire p2p system falls flat on it's face.

Sadly enough

crap, malware, disease infested computer and a subpar ISP

Due to lack of true user knowledge, that describes the majority of computers connected to the internet.

lurker · Post by **lurker** » 17 Oct 2007, 17:04

Forboding Angel wrote:All you need is 1 person with a crap, malware, disease infested computer and a subpar ISP and this entire p2p system falls flat on it's face.

Sadly enough
crap, malware, disease infested computer and a subpar ISP
Due to lack of true user knowledge, that describes the majority of computers connected to the internet.

That's why you go hybrid and route through whoever can do it best. A pure p2p system fell on its face long ago with anyone who hasn't port forwarded properly, and can't reach everyone with hole punching.

AF · Post by AF » 17 Oct 2007, 17:10

ok so we have our 1 client to client connection bandwidth of 1.92KBps under bigheads model.

But bigheads model is incomplete and out of context

So in a 16 player game that bighead attempted to model, 1.92kbps is not the comparitive value of bandwidth floating around the system, because thats just a 1 way connection in a system with 16 nodes and each node having 2 connections to each other node, 1 to send data and one to recieve, 1.92KBps only represents one of those connections for one of those nodes.

Also lurker made a mistake as a Kilobyte is 1024 bytes not 800 (16* 50 == 800).

Distributed p2p systems do not save bandwidth, they increase bandwidth, the reason they're mentioned where bandwidth is concerned is because the host has reduced bandwidth load as all the peers are sending eachother the data, even if the interclient bandwidth far outweighs the original hosts bandwidth in the centralized system.

lurker · Post by **lurker** » 17 Oct 2007, 18:28

AF wrote:Also lurker made a mistake as a Kilobyte is 1024 bytes not 800 (16* 50 == 800).

Wha? Oh. Yeah, I changed the numbers a few times when I was calculating... Let me update that for you.

but the key thing is upload bandwith, that's why bighead was only looking at one half, as so many connections are asymmetric

But doesn't the host send a packet to each person per frame anyway? If so, then the rough camera/cursor combo has very little overhead and only takes about 10 KBps.

BigHead · Post by **BigHead** » 17 Oct 2007, 18:40

Uhm, AF you're right in all your statements but you you came to wrong conclusion.

each node having 2 connections

I mentioned this in my post:
client output = 15 * 128 bytes / sec = 1.92KBs
client input = 15 * 128 bytes / sec = 1.92KBs
This means that I+O = 3.84KBs

system with 16 nodes

Well, if you put it this way bandwidth floating around the system is 16 * 3.84 = 61.44Kbs which is roughly the same as with current centralized model.
However this value is distributed equally (in ideal situation) among 16 independent internet connections which is much better than relying on server to transfer 50% of data.

Post by **Auswaschbar** » 17 Oct 2007, 19:15

trepan wrote:I'd rather leave it the way that it is for the moment. Client selective messaging
would allow for easier cheats. The other advantage to the current system is
that all players will have complete replay files, and you'll be able to watch a
replay with the same camera view as any player (using freecam and some lua).

With the disadvantage of a 4 times higher traffic (when all players use the camera widget), even when i decide not to use it. Not to mention that this messages get exactly the same priority like the engine data.

Client selective messages don't make cheating easier, it makes it more difficult. I currently have to alter 1 line of code to see the other teams chat messages, some more to see their mapdraws and then i could see their camera / cursor positions because i recieve them anyway.

In addition, it would allow some more bandwith consuming widgets without lagging all other players out (cursor position, music straming, voicechat or whatever)

Post by **trepan** » 17 Oct 2007, 19:30

Auswaschbar

Ya, you're right, information hiding is indeed helpful to avoid most
types of cheating. The one I was thinking of was when a player
starts to send information to an enemy to ruin a game (which I
assume is why Spring does not support player-to-player messages).

The type of cheating I just mentioned could be avoided by only
allowing player-to-player messages between allied players.

All that aside, my main point is that I do not want any special server
setup for the initial custom lua message type, I want them to be
sent to all players so that the recordings at the clients are all
complete. Once I've got that tested a bit, we might add another
message type that relies on server message culling.

P.S. The incoming client bandwidth for the camera state is pretty
low (ex: 128 * 16 = 2KBps). I think that the real problem will be
the server upload bandwidth, which server side message culling
would only reduce by about 50% (or less, as spectators are setup
to receive all message, as is the current setup for chat messages)

Post by **Auswaschbar** » 17 Oct 2007, 19:55

At first: don't get me wrong, i really think its a good idea

trepan wrote:P.S. The incoming client bandwidth for the camera state is pretty
low (ex: 128 * 16 = 2KBps). I think that the real problem will be
the server upload bandwidth, which server side message culling
would only reduce by about 50% (or less, as spectators are setup
to receive all message, as is the current setup for chat messages)

But since other people are encouraged to write their own widgets with networking support it will increase over time. And when its not selective every player will recieve every message send by each players widgets.

Post by **trepan** » 17 Oct 2007, 20:00

Exactly, so everyone will have a replay file that contains all
information used in the game. As with most everything else,
it's a trade-off.

Spring RTS Engine

Custom LuaUI network messaging