Active TopicsActive Topics  Display List of Forum MembersMemberlist  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin
Developers
 Brain Games Forums : Developers
Subject Topic: network Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 14 August 2003 at 14:10 | IP Logged Quote Popolon

Well, now that I've started he network code for MoG2 (and RoadFighter). I'm discovering that it's not as easy as I thought!

May be some of you can answer my questions (Carles?):

First of all: I will use TCP/IP to connect the computers. I guess it's the right protocol, I've readen of UDP, but as it is not very reliable, I'm not going to use it.

Second, I've to chose a PORT. Is there any rule to chose a port? or it's better to allow the user to change it in a dialog?

To initialize a networked game, first I set a computer as a SERVER, and I open a listening Socket in it, to listen for CLIENT's requests to connect. Now my problem is: the CLIENTs need to know the IP address of the SERVER!?!?! Isn't there a way that the CLIENTS can scan the network looking for MoG2 SERVERs active without having to know the IP address?

Well, for now those are my doubts. I guess I will have more as I advance in coding the network part...
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Jorito
Admin Group
Admin Group
Avatar

Joined: 30 December 2002
Location: Netherlands
Posts: 1930
Posted: 14 August 2003 at 19:25 | IP Logged Quote Jorito

Well... my thoughts...

You definitely should go with TCP and not with UDP. Basically because of this: with TCP you are sure a packet is received, with UDP you won't be. TCP is also the most common protocol, UDP is more used for streaming audio and video (because it's not a big deal if one small audio or video packet gets lost, you're more interested in a fast stream than in waiting for each packet to be acknowledged).

As for port, iirc, all ports below 1024 are taken, everythjng above is probably free. Not sure if the exact port limit is 1024, but ahwell. Just pick a port somewhere in the thousands (like 9111 or so), and maybe do a quick search on google to see if there's already any other commonly used program using it. You could enable a user to choose their own port, but I think it's much better to pick an unused port and 'force' that as a standard, otherwise it would be very hard to oversee...

And indeed, you'd need the IP address of the server! At least, if you want to do internet playing as well, since you don't want to scan the whole internet For local networks, you could try to scan all computers in the same netmask (usually 255.255.255.0, giving you for example all 255 PC's in the 192.168.1.x range) for a server listening on the port you specified, but you really should have an option to enter the IP or hostname of the server, it's normal.

Hope this helps, if you want to know more, just ask!
Back to Top View Jorito's Profile Search for other posts by Jorito Visit Jorito's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 15 August 2003 at 00:22 | IP Logged Quote JEames

Ports arround 8000-9000 are generally used for proxys and similar services. I would choose something above 30000, I remember Quake used port 27000 or something like that.

Forget about scaning the network. What you can do is some kind of Internet Game Server Locator: when the server is launched, the server contacts one unique central server (could be on getput) where a list of available "game servers" is constantly updated and available. When the server goes down and a time-out goes off, the server is taken off the list. -When a client want's to play, it first connects to the server and downloads a list of available servers (can be done even via http)... then trys to con connect with the game server the user chooses.

Carles right now is lost somewhere in Burgos... but l'll forward him this thread... let's see if he can team-up.

BTW: certain games use UDP for real-time updates. They have a TCP open socket for critical data and use UDP to constantly update positioning. This make's the game run smooth with a good bandwith but it does'nt make the game stop working when there insuficient bandwith but just make the updates much slower and "bumpier". I think counter strike used this kind of connectivity... but I guess this is a very complicated way to start... but keep it in mind because you might need it in the future.



Edited by JEames on 15 August 2003 at 00:26


__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 15 August 2003 at 12:00 | IP Logged Quote Popolon

Thanks for all the advices! I think that I can advance a little bit more now. I'll keep you informed of my advances!

For now:

I'll forget UDP then.

I'll use a high port (32123 for instance).

To find active servers, I think that I will make to ways:
A) Give the direct IP address of the server
B) Get the server list from GetPut

Initially I'll start with A), and when everything works, then it will be easy to add the B functionality

Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Jorito
Admin Group
Admin Group
Avatar

Joined: 30 December 2002
Location: Netherlands
Posts: 1930
Posted: 15 August 2003 at 13:48 | IP Logged Quote Jorito

Sounds like a good way to approach the problem! Keep us informed of the status
Back to Top View Jorito's Profile Search for other posts by Jorito Visit Jorito's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 15 August 2003 at 21:36 | IP Logged Quote JEames

Popolon wrote:
I'll use a high port (32123 for instance).

Usually, easy numbers have been used or are beeing used. Why don't you use your birthdate telephone or your number?



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Lars The 18Th
Senior Member
Senior Member
Avatar

Joined: 16 November 2002
Location: Netherlands
Posts: 166
Posted: 16 August 2003 at 01:26 | IP Logged Quote Lars The 18Th

Here is a complete list of used ports and programms  
http://www.iana.org/assignments/port-numbers

Back to Top View Lars The 18Th's Profile Search for other posts by Lars The 18Th Visit Lars The 18Th's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 16 August 2003 at 12:02 | IP Logged Quote Popolon

Thanks!

Fortunately 32123 is still not used. I'll use that one (I just like that number )

btw, I'm advancing. Currently, the computers are communicating with each other!! Currently, the server launches, creates a listening socket, and waits for clients. The clients are able to connect to the server and log in/log out and send data to/from the server!

So this is advancing fast! Actually TCP is a VERY easy protocol to use with the SDL_net API!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Jorito
Admin Group
Admin Group
Avatar

Joined: 30 December 2002
Location: Netherlands
Posts: 1930
Posted: 16 August 2003 at 21:33 | IP Logged Quote Jorito

Hahaha, I assumed as much! Not that hard to figure out if you know that the 'S' in SDL stands for Simple Anyways, it's cool to hear of this rapid progress!
Back to Top View Jorito's Profile Search for other posts by Jorito Visit Jorito's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 18 August 2003 at 02:28 | IP Logged Quote Popolon

Well, I've supposet to be done of the network code, but...

but it's damn slow!!! I can only get about 5-6 frames per second!! And I'm testing it in a 100Mbit LAN! And it is not the case that I send very much information, in fact the average interchange of information per frame is 32bytes...

I don't know what happens, has someone any idea of the average latency of a TCP message in a LAN?
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 18 August 2003 at 12:06 | IP Logged Quote JEames

Well, I'll make a bet: what happens is that you wait to recieve the network information before rendering graphics. That might slow down the game a lot... on a networking envoirment you have to make the game speed (rendering graphics & processing) completly independent from the network data recieving.

In any case, 6 frames / sec at a rate of 32bytes / frame is a very low figure. You are loosing time somewhere, and I bet it's not the network (on a 10Mbit lan you can send 1Mb of data per second easy and you are sending 0,00003Mb each second, so there has to be some problem on the programing).

Try printing out on screen what is the computer waiting for between frame and frame.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 18 August 2003 at 12:30 | IP Logged Quote JEames

While having a shower I was thinking about this speed problem and something came to my mind: are you sure the SDL_NET is'nt buffering something? All the code is the same so it make's no sense that you are "losing time" somewhere but within the comunications and the 32bytes/sec should work fine regardless of the processing/recieving data problem I mentioned just before.

I remember when Carles was dealing with all this socket bussiness he started using the stanadard sockets tha come with Borland Delphi, then he changed over to some component he found on the net, and finally he changed for the last time to an open source code component he found... and he still wasn't very happy about it; he actually mentioned about makeing his own sockets to have 100% control on what happens over the network connection... so getting to now how you sockets work might be harder than what it seems.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 18 August 2003 at 13:38 | IP Logged Quote Popolon

mmm... that makes sense. I'll try to look the inner code of SDL_net to see if there is some kind of buffer.
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 12 September 2003 at 16:39 | IP Logged Quote Popolon

Yesterday I designed a new protocol for the game. I think that this one will be able to handle the number of synchonizations per second that I need.

The main idea is the following one:
- Each local computer makes an hypothesis on what the other players will do, and execute the game without any pause with that hypothesis.
- When the server sends an update of the local computer states to the rest of computers, each individual computer checks whether the hypothesis that they have made are right or not. If they are not right, all the cycles computed based on that hypothesis are discarded and recomputed.

However, it's a little mode complex to code. I've started today, and I'm about 30-40% of the total implementation.

I hope it works!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 12 September 2003 at 16:55 | IP Logged Quote JEames

Wow.. . it's sounds complex to me.

Could'nt you get the right frame rate with those 32byte/sec?

What I mean is that if you can't get the 32bytes/sec all computers on the network game will be guessing what's going on and discarding every x frames. That will make the game "bumpy".

The idea is great but predicting movements should only be done when there's a puntual lack of bandwith. If you can't get 32bytes sent over the network every second you have a problem no mater how well you predict the players movements...

Well... it's just a systems admin's opinion. It might just work, you never now.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Jorito
Admin Group
Admin Group
Avatar

Joined: 30 December 2002
Location: Netherlands
Posts: 1930
Posted: 12 September 2003 at 23:31 | IP Logged Quote Jorito

Uhhmm... maybe I'm out of my league here, but maybe you're doing this the wrong way? Not that I would know a good way on how to do this, but it really sounds as if something is wrong... It's not as if there's a lot of data to send (32 bytes a second iirc? Just passing through player positions should be enough), and that amount of data should be possible even on a normal dialup line without any problems. Sending that small amount of data every second (shorter intervals probably is a bad idea) should be possible, even if there's latency. Otherwise, it might be worth considering UDP in stead of TCP, you'd miss the ACK, but can burst more data (and maybe use shorter intervals).

So... network traffic shouldn't be the problem... but probably how to deal with it in the game is? There's no docs about this somewhere on the internet? Or an SDL opensource game with multiplayer support? I mean, there's lots of other projects that do work, and if they can make it work, so can we Of course, I hope you don't take this the wrong Santi, you're a very good coder, but if you are as new to this as me, some research might help out to make RF (and MoG) a great multiplayer online experience!

BTW... your guessing method might work, perhaps other games do it in this way too, but... will it work and be accurate enough?
Back to Top View Jorito's Profile Search for other posts by Jorito Visit Jorito's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 13 September 2003 at 00:08 | IP Logged Quote Popolon

Well, it's not 32bytes/second. It's actually 32Bytes per frame. But that's still very little data.

I asked some weeks ago in some forums and I got some clues and answers. The problem is not the amount of data, but the protocol. My previous protocol worked in the following way:
- Each client computes a game cycle and send the new status to the server
- Once the server obtain all the new status, it sends the updates of each client to the rest of clients.

The problem is that both, the server and the clients are bloqued waiting for the response of the other. In the SDL forums, they told me that all the Quake-like games work with speculative execution. In that games, the protocol is some variation of the following:
- Each client makes hypotheses of the moves of the rest of players and computes a new cycle. Then, broadcast the new state using UDP to the rest of clients, and using TCP to the server.
- Each client use the quick-UDP updates to temporally update the game. But when the server sends using TCP the real state, if some UDP packet contained an error, the hypothetical execution is discarded, and all the information is recomputed using the secure information sent by the server.

My idea is not to use UDP by the moment (to broadcast the state to the rest of clients) to see if I can get enough speed. If this works, then I'll add UDP also to increase smoothness to the game (only if needed).

And by the way, the guessing is quite robust: the asumption made is that if a key is pressed, it will be also pressed on the next cycle. Therefore, the hypothesis is only wrong in the frames when the user presses a new key or releases a previously pressed key (I think that the hypothesis will be right about the 75% of the cycles: you do not press 25 new keys per second!).

And, about looking for an opensource game with multiplayer. Actually, one guy has given my an URL from where to get one. If my new protocol doesn't work, I'll download that game...
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 13 September 2003 at 00:11 | IP Logged Quote JEames

Hey! Never underestimate Santi's coding powers!!!

He can make a game smarter than your self! -So: if Santi can predict your movements (keep in mind he works in the IIIA (Artificial Inteligence Research Institute)) this means that he's probably right and what ever your movement was, you were worng.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 13 September 2003 at 00:28 | IP Logged Quote JEames

Now what about a more simple aproach:

The only one who predicts anything is the main server, clients connect to the server's open sockets and the server sends a continuose stream of data with the maximum number of updates each socket connection permits, so that if computer A has an ADSL he gets for example 50 updates per second and computer B that's got a standard modem gets 20 updates per second.

The way to do is is to create seperate threads that contiousely read the map possition and send it to the clients as fast as each client  read.

Each computer has another socket to send keystrokes to the server and the sever updates accordingly... if no keystrokes are recieved in the last frame, use the same key status you had before. Let's imagine a Popolon jump with a lack of bandwith: the server assume's pop didn't jump because no data was recieved, but the local computer made pop jump and get to (where ever he wanted to get) ... so the server will need continiouse updates of keystrokes and player possitions and then decide where pop realy is.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 13 September 2003 at 13:32 | IP Logged Quote Popolon

Actually, 25 updates per second are needed an enough. Since the game executes 25 cycles per second.

But don't worry! It's almost working now!!!! I can get more than 100 synchronizations per second with the new method!!!!
And the limit of 100 syncs/sec was not due to a network limit, but simply to that my machine is not fast enough to execute more than 100 game cycles per second!!!!

But now, I see that all the problem was due to a very simple fact. When Jorito mentioned the ACK messages in his last post he made me think of a very stupid thing that I was doing!
In the old implementation, I packed all the information if 4byte blocks, and then send each block in a TCP message, and I had pieces of code like this:
TCP_send(block1)
TCP_send(block2)
TCP_send(block3)
Notice that before block2 was send, the computer is waiting for the ACK of the block1!!

In the new one, I just send all the information I have to send in a single TCP message:
bigblock=merge(block1+block2+block3)
TCP_send(bigblock)

This saves me a lot of synchronization delays! And that's all!


JEames wrote:

Now what about a more simple aproach:



Each computer has another socket to send keystrokes to the server and the sever updates accordingly... if no keystrokes are recieved in the last frame, use the same key status you had before. Let's imagine a Popolon jump with a lack of bandwith: the server assume's pop didn't jump because no data was recieved, but the local computer made pop jump and get to (where ever he wanted to get) ... so the server will need continiouse updates of keystrokes and player possitions and then decide where pop realy is.



This is exactly the problem! The server will asume no jump (speculative execution). Then after receiving the keystrokes from the client, the server will update the position of Popolon. But not only update it. The server will rewind the state of the game till the point where popolon started to jump, and then recompute all the new game state. All the clients will do the same after receiving an update from the server.

But well, as I've told you. The network bandwith is not a problem anymore. The speculative execution will work as follows:

Imagine that a computer is executing the cycle 23 of the game, but has not received any information of the server of cycles 22 and 21, I will keep the following:
- state of cycle 20 (synchronized)
- state of cycle 21 (speculative)
- state of cycle 22 (speculative)

Now, the computer executes the cycle 23, and we got this:
- state of cycle 20 (synchronized)
- state of cycle 21 (speculative)
- state of cycle 22 (speculative)
- state of cycle 23 (speculative)

An update from the server arrives of the cycle 21, and the hypothesis of no keyboard strokes was right, so state 21 was well computed, we got this:
- state of cycle 21 (synchronized)
- state of cycle 22 (speculative)
- state of cycle 23 (speculative)

Now, an update of the cycle 22 arrives, and there has been a new keystroke. So cycles 22 and 23 are discarted and recomputed, we got this:
- state of cycle 22 (synchronized)
- state of cycle 23 (speculative)

The only problem, is that the user will never see cycle 22 well drawn in the screen, since when cycle 22 was displayed on the screen, it was not properly synchronized. But this happens with all the network games.

Sumarizing, the idea is to have a queue of states, keeping always the last synchronized state, and the sequence of speculative states. Currently I've limited the amount of speculative states to 8. So if during 8 cycles, a client doesn't receive any update, it remains bloqued until an update is received.

I don't know if any of you is knowledgeable in microprocessor design, but what I've described is exactly the workflow of a superscalar mircoprocessor (such as any of the Pentiums).

Edited by Popolon on 13 September 2003 at 13:34
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 

Page of 2
  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.01
Copyright ©2001-2003 Web Wiz Guide

This page was generated in 0,7188 seconds.