network engine

Introduce your project and write about your work.

Moderator: PPS-Leaders

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

network engine

Post by greenman » Fri Oct 26, 2007 5:09 pm

Dumeni and I are working on the network engine in PPS HS07:

Project Page
Our goal is to seperate the game into a frontend and a backend (only running on one computer in case of Multiplayer).
The frontend processes input and renders the output.
The backend manages the ODE, object managment and synchronisation of the clients.

Currently we are trying to find a suiting network library as the basis of our engine. ENet seems to be quite suitable at the moment. Lets see wether this will turn out right.

cheers oli

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Post by greenman » Sat Oct 27, 2007 8:41 am

enet seems to be quite powerfull and suiting for our needs. however unfortunately it doesn't support any compression or diff-algorithm.

we got to decide, wheter we want to do this on our own now or if we should keep on searching for a suiting network library.
if we go for enet we got two possibilities:
- every object has to have a function for providing a bytestream of it. synchronisation is done by sending the bytestream of changed objects to the clients. this will probably result in a lot of overhead without any diff or compression stuff implemented.
- we do not sync the whole object, but implement a "language" with control-codes managing the objects (set_position(10,10,0), set_orientation(0,0,10), ...). this will result in a lot of implementation work to be done by probably all of us.

so what do you think ? ;)

btw: does anyone know which library bensch meant in his mail? i couldn't find anything in the www

cheers

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sat Oct 27, 2007 9:21 am

I really think he forgot to send the link. I don't know what he's doing over the week end, so I don't know when we will here from him. Also chrigi hasn't written back yet. As far as I know, we had diff and compression in the old network code. It was provided by some library, but this again is something I don't remember.

Both possibilities require an interface of at least one function doing all the network magic. This interface has to be implemented at a hierarchy level from where all synchronizable objects have to inherit from.
Thinking about it, the easiest way to do it, is to add the values which have to be synchronized to some list, which will be read out by the network engine. Every value in this list will not make it through the network. I think that's the minimal possible way to make it easier for all the other programmers.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Post by greenman » Sat Oct 27, 2007 9:39 am

Yeah, that's a good idea.

I thought about a class containing
- bool changed (selfexplaining ;) )
- linked list with values to be synchronized
- a (template)function reload, that reads all values in the linked list and applies them to the object

This class has to be inherited by all the objects that need synchronisation.
Reload of course has to be implemented by the creator of the object.

All objects to be synchronized will be in a tree related to each other just like the ogre objects (scenemanager, ...).

I think that way we could go for enet, and optionally implement compression because enet is really quite easy to implement compared to opentnl

what do you mean?

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sat Oct 27, 2007 10:29 am

Well, I think diff and at least compression would be a great thing to have. I checked out the wiki (see NetworkManager). We used zlib for compression in the old implementation.

Beside that I think it's great. We have to put your class at the right place in the worldentity hierarchy, so we can include a lot of standards.

I'm not sure, but the reload-function (or maybe synchronize-function) could be implemented by you as well. All you have to do is check for every value in the list which has to be changed and send it or vice versa. Yeah, that should be possible.
"I'm Commander Shepard and this is my favorite forum on the internet."

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Sat Oct 27, 2007 1:16 pm

Bensch meant this lib:
http://cs.baylor.edu/~donahoo/practical ... practical/

It looks really basic. TNL is - for sure - much more powerful and flexible.

For some reason, the mail with the url only reached me...

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Post by greenman » Sun Oct 28, 2007 5:47 pm

Ok, what I meant is we could think about compression and diff later on, when the other things already work.
I didn't think of the reload function as a "send to server" function but as a function who updates object-specific things by using the list mentioned above. This function would be called after a sync to make sure the changes also affect the given object.

cheers

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sun Oct 28, 2007 6:00 pm

Since the list only contains pointers the real values will automatically be changed, when a sync is happening or am I wrong?

It's okay to think of this later and first implement simpler stuff.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Mon Oct 29, 2007 9:17 am

Great! I think you asked the right questions. Your implementation is very close to what we did the last time. You may take a look at the
synchronizeable.(h, cc)
files.

Another questions of great importance: how do you identify objects to synchronize within the network. E.g. how do you know that one object on one computer needs to synchronize other objects on other computers? Unfortunatelly this is not trivial :D

Here are some papers to read, that will help you understand the theoretical background for game network programming (altough I think you have a good picture of it already).
But please read through the first articles, as it will help preventing architectural errors.

The Valve Source (tm) network implementation has very sophisticated way to deal with network delays:
http://developer.valvesoftware.com/wiki ... Networking

Quake 3 networking model uses diff images for synchronization. Really smart , support this ability but don't implement it as a first thing :D
http://trac.bookofhook.com/bookofhook/t ... Networking

And more implementation specific and very nice: the unreal networking implementation:
http://unreal.epicgames.com/Network.htm

You have written about scalabitliy. So how scalable do you want the networking to be? Do you want to support up to 30 players then a normal server-client setup should do it (and a server with a very big backbone). But if you like to be more scalable you would perhaps want to think about another server architecture:
http://ieeexplore.ieee.org/Xplore/login ... 498481.pdf
(you will need to be inside ethz (vpn) to read this ieee message)

And Bensch and my work about game networking:
ftp://ftp.tik.ee.ethz.ch/pub/students/2 ... 006-31.pdf
where we propose to use a proxy server approach.

Have fun!
Patrick

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Post by greenman » Tue Oct 30, 2007 4:44 pm

Thanks a lot for these links, they are/were really helpful.

However now I'm quite pessimistic because of the network delay...
I did some pings today and saw that if we want to be capable of worldwide playing we have to deal with delays of 100-200ms :(
This is bad news because to manage such dimensions of delay we have to implement inter- and extrapolation, prediction and we also have to buffer gamestates for some time (maybe 1 sec).

Is there a way of avoiding intra-/extrapolation and prediction without having lags ?

Edit: just realized that the above ping values might not apply to already established connections. Does anyone know more about delay in an open connection? Can we somehow test/find out the delay in that case ?

User avatar
hofzge
Roshliikhh, lower servant to the Deities
Posts: 116
Joined: Mon Oct 23, 2006 12:01 pm

Post by hofzge » Tue Oct 30, 2007 5:29 pm

The delay apply to all connections as those delays are summed up electronic delays often also caused by dropped packets due to high network traffic. If I understand your problem right, then the solution would be to test an open connection with a tool that sends a stream of packets to a port and an application on a target system like ttcp. Like that you get the overall bandwidth of a connection, which should be irrelevant if you don't always send the whole gamestate.
The roundtrip delay will not change over the course of a transmission (at least not much) and you can measure it the way you already did with ping. Also any delays under 150ms are not felt by a human being. No need to be to pessimistic :)
The sky above the port was the color of television, tuned to a dead channel.
-- William Gibson, Neuromancer

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Tue Oct 30, 2007 6:57 pm

hofzge wrote:Also any delays under 150ms are not felt by a human being.
LOL *insert falling-from-the-chair-smiley here*

We're talking about real-time-game data. Of course everyone feels a 150ms delay. I'm playing unreal tournament with a delay of 30-40ms on german servers and I'd love to have 20ms or even less.

+/-10ms have a noticeable effect on my score, +/-20ms are felt very clearly. Delay > 100ms is unplayable (well, ok, I played with 150ms in my first months with UT, but that meant 10-20 shoots for 1 hit. With 30ms delay I usually need 2-3 shoots.).


A little calculation:
My enemy runs with ~10 m/s
I'm aiming exactly at him and press -fire-

Ok, now: delay 150 means: what i'm currently seeing on the screen is 150ms old and it takes another 150ms to send the -fire- command to the server.
So when the server checks if I have hit the player, my enemy has had 300ms to run 3m away and the servers answer is a clearly "no hit" :?
greenman wrote:However now I'm quite pessimistic because of the network delay...
I did some pings today and saw that if we want to be capable of worldwide playing we have to deal with delays of 100-200ms :(
This is bad news because to manage such dimensions of delay we have to implement inter- and extrapolation, prediction and we also have to buffer gamestates for some time (maybe 1 sec).
I don't really understand your problem. Isn't it possible to just send the current gamedata from the server to the client without considering the delay? The packages will reach the client more or less in order, so the client will see the same action as the server, but with a delay.
Every reaction of the player will reach the server even later, which means (as mentioned above) that players with high delay will miss their target more often than players with low delay.
But thats no problem. If a player shoots, it will take 2*delay until he sees the shot on his screen (if we implement it correctly). This is a good feedback to adjust his aiming ("aim 3m before the enemy to hit him").

Or did I get your problem wrong?

User avatar
greenman
Baron Vladimir Harkonnen
Posts: 360
Joined: Wed Oct 03, 2007 2:53 pm
Contact:

Post by greenman » Tue Oct 30, 2007 9:00 pm

Well the problem is exactly what you already said:
Players with more (physical) distance to the server having more delay are really unprivileged. It wouldn't be fair for them to play with a response time of 100ms compared to 2ms for a client being dedicated server ...

btw: Just a detail, a delay of 100ms means that a packet needs 100ms to the remote host and back, so its a bit less bad, but still...

My suspicion is that the delay using a already negotiated connection is (hopefully a lot) smaller than the one of a ping and thats what I will probably test next.

Does anyone have access to a server "at world's end"? ;)

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Tue Oct 30, 2007 10:10 pm

greenman wrote:well the problem is exactly what you already said:
players with more (physical) distance to the server thus having more delay are really unprivileged. it wouldn't be fair for them to play with a response time of 100ms compared to 2ms for a client being dedicated server ...
So we have two possibilities:
(A) Everyone plays with the same delay. This is hard to implement and has the following worst-case-scenario: some players play with 30ms delay, when suddenly a player from far away joins and therefore everyone has to play with >1000ms delay.

(B) Different delays, based on different connections. this is easy to implement, but its not fair. Worst case scenario: one player plays on the server with 2ms delay, another player has a very bad connection and therefore has to play with >1000ms delay.

A player can choose the server he wants to join, so he will most probably take a server to which he has a good connection, but players on a server can't decide which other players are allowed to join. That's argument #1 for (B).

Internet connections at home are usually not good enough to run a server. the upspeed is too low (well, this will change in the next few years) and there are way too many hosts on the way. That's why everyone rents gameservers that are located in servercenters. This means: No players with 2ms delay, but almost everone in the same country with 30-40ms. That's argument #2 for (B).

Every multiplayer-game I know (all are first person shooters) use (B). No argument, but a guideline. ;)

Fairness ist an argument for (A), it's a good argument, but its the only one I can think of and I think (B) too is fair enough with the assumptions from argument B#2.

So a clear vote for (B) from my side. ;)

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Tue Oct 30, 2007 10:40 pm

Well, it looks that network is not that easy after all (we never said it would). :)

But there is no reason to be pessimistic. Even without all those precautions and cool predictions and compensations one can still play.

The delay as such can be defined as the RTT (round-trip time) or the actual delay of a packet being sent from client to server. Sometimes you have to only take travel delay into account which is not affected by packet size. But most of the time the real bottleneck is the propagation delay caused by limited bandwidth and is affected by packet size.

Well enough with the theory. With reading that stuff one learns a lot about what client and servers have to be able to do. A simple collision detection while client side prediction.

Implementing all this is definitely too much and cannot be done within one semester.

What is important is that your concept can support ALL of those tweaks. Of course that is also not very easy, but I never said that either. ;)

I think a compression of some kind is something possible. Also a distinction between reliable and unreliable messages are possible and important at this time.
For example a chat message can come a second too late and nobody cares, but if it's not arriving, people will care.

ACKs should be used like they are in TCP, but resending should not be done, so UDP is still what we're aiming at.

A basic network protocol will soon be needed from you guys, but relax: We're there to help.

Also think about architecture. A client still has to run some engine stuff. How can we support it without implementing it?
Also you might have noticed that sending, taking snapshots and ticking the game world on the server are handled independently. This can only be done with separately handled loops, with different tick times (threads?).
"I'm Commander Shepard and this is my favorite forum on the internet."

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests