Net play, anyone want to do it?

[Rice]

Does any one would like to join the project, to make a common net play plugin, which will be share among the most of the emulators?

I don't think Kaillera is the right direction to go, it is probably a place to meet someone to play game on the net, but not likely a way to achieve better speed to make N64 game net play available to most of the players who are still using dial up access.

I do have some good ideas but lack of time, need some partners, who would like to practise TCP, UDP, winsock, multi-thread Client/Server programming in C/C++. !964 could be the first emulators to integrate, but it should not be hard to integrate into other ones.

I hope the final one could make netplay at virtually full speed, even via dial up network.

 

[bjz]

Well I am actually getting cable on friday, but i will still help you. I am byfar no expert, espescially when it comes to n64, but i have some winsock experience with C.

Mail me [email protected] or get on irc when i am on. I know u get on cuzz i have talked to u a few times .

 

[jvolel]

hasn't that been done in the current version of 1964

 

[zilmar]

something that I had always planned to do for pj64 .. just never did have the motivation/time .. now I quit never will .. but I was doing all that network programming for my job .. oh well .. I am sure some one can add it in to pj64 latter ..

 

[Hacktarux]

I am eventually interested by doing this. Maybe i don't have all the necessary knowledge (I have never made such things on a windows environment) but i think i can learn it quickly. Can you explain your ideas so i can tell you if i think i am able to make this ?

 

[Rice]

Hacktarux

Email me. I should know my email.

 

[Zombie9246]

If you look at a very famous Snes emulator like Zsnes, you see they perfected netplay on that console system. Their netplay is proprietarly coded on their emulator becuase the internal input, emulation core, and netplay code need to be working they way they need together, plus the proper data in the UDP packets is sent. Their emu is under a Open-source liscense so youd need to get permission in order to take any ideas from their code.

 

[Cyberman]

Does any one would like to join the project, to make a common net play plugin, which will be share among the most of the emulators?

I don't think Kaillera is the right direction to go, it is probably a place to meet someone to play game on the net, but not likely a way to achieve better speed to make N64 game net play available to most of the players who are still using dial up access.

I do have some good ideas but lack of time, need some partners, who would like to practise TCP, UDP, winsock, multi-thread Client/Server programming in C/C++. !964 could be the first emulators to integrate, but it should not be hard to integrate into other ones.

I hope the final one could make netplay at virtually full speed, even via dial up network.

Ummm wonderful I'm glad you know a bunch of protocol names

UDP - User Datagram Protocol - this is what TCP uses as an underlying transport mechanism in reality, UDP is what is termed connectionless. You send a packet to a socket at a specified port and there is no guarentee that packet reaches that destination period. Also if you send a packet before one packet it could arrive after the 2nd packet. No guarentee of the order packets will be recieved in. This is block oreinted because you must create a data gram then send it. It has low over head because of this.

TCP - Transport Control Protocol - the majority of internet applications use this, it guarentees delivery of data. It operates like a stream. There is no size limit since there is no datagram it's just a stream of data. Data cannot be recieved out of order, data will not be trimmed, you will know when the client/server refuses a connection. This is called a connection because you connect to a server and the server manages the connection the socket is used exclusively for the client. High over head.

Threading is a TOTAL PAIN IN THE ASS. Just warning you, especially with dealing with data on the internet. For example under windoze you have to have a large thread cache if you are servicing more than 10 clients simultaneously. The server can be written entirely independantly of the clients.

Now here are some problems:
I suggest you use TCP to establish a connection to the server as a control connection. It's not a big deal.. The problem is you need a SERVER and a socket for this to work. IE FTP is socket 23. Since this would be a non standard server, you MUST use a number >=1024. 6144 is fine just has to be greater than 1024. ALSO windows is limited to socket ID's from 0 to 32767 this means sockets 32768 to 65535 are not usable from a windows machine (pain in the ... BEEP).
The server I would recomend have a login for the clients for the control connection something like.

USERID
PASSWORD
EMAIL

It has to be secure to prevent malicious use. You can get the clients IP address from there TCP data on the connection. the control connection would be LOW bandwidth IE not much data is sent on it. What it is used for is sending information to the clients like CLIENT LOGED OUT, CLIENT TIMED OUT etc. if someone was linked. OR give information like Martin wants to play Gauntlet64 with 3 other people.. etc. Simple messages etc. and control information.

You essentially have to use TCP for the control connection.

UDP is usable between individuals (IE to people playing the same game). Since the control connection can pass the clients information about the oponent input this is quite workable. Synchronization of data probably won't be necessary. Order of UDP packets will be. Also you do need to check if the packet is complete and error free. UDP guarentees NOTHING.
You need to know the order of packets so a 32 serialization of each packet sent is probably a good idea. Each new packet gets a new 'stamp'.

Things you need to pass in the packets?
Sync speed (PAL/NTSC) 30/25 fps you don't want the games to go faster than each other so.. you will have to stop frame rendering while one lags. (fun?)
STOP IE someone stops the emulation on there end.. this needs to stop it on the other other too. It's lame I suppose but necessary.
For every packet sent there needs to be an acknoledgement.

I would recomend a sequence of tokens in each packet of data. First data should be the sequential number, the second chunk of data should be the total length of the packet (16 bits) then a 16 bit CRC that makes your packet a whole 8 bytes thus far
After that your actual DATA (woo) should appear I would suggest a set of parsable tokens with fixed data fields.
IE (<> - indicates a token ID [] indicates a data field)
<KEYPAD>[Buttons][AX][AY]
Just an example that would contain the current status of the other persons Joy stick information. It is only sent when it changes (lag could make this fun huh?).
Other status tokens like... STOP PAUSE etc. used on the EMU would need to be sent as well as 'key frame' data.

IE if you are starting a game.. both parties need to keep track of what 'frame' count they are on mutually.

An example of a typical packet my be
<ACKKEY><KEYPAD>[Buttons][AX][AY]<ACKFRAME><FRAME>[Current Frame]
This is so the other client knows you recieved the current frame it is on and it can verify your current frame. ACK KEY would recognize a JOY stick change .. not to exciting.. but it is always good to verify data was recieved
If no verification of the data was recieved then you might want to send an <PAUSE> and wait for a response.

Granted this might be happening VERY fast but since the packets are small it shouldn't be too bad over a serial connection. Though downloading etc would slow it down (IE compete for bandwidth).

Since your FPS is typically some divisor of 60 (IE 30 or 15) or 50 (25 or 12.5) Sending your frame counter periodically (say every 10 frames) won't be bad and it's a good way to see if the other person is still there.. if the person drops off, you will know VERY quick this way .

There is another reason why you want to use control connections to the server (TCP) you can pass what data port each client is listening on for packets from the other. In addition it is possible to 'blockaid' people spoofing packets to your IP address this way since... the server can control the socket addresses and ID information each client is expecting.

Enough of that.. heh.. why the heck did I say all this? I implemented a server that had similar requirements already. Works nicely under WinNT. I'm not sure what computer you plan on using for a server but consider that you might have 300 connections (control) of which 30 at anytime will be actively sending data (login control status information etc.) And most important NO traffic containing the actual Game data going through the server (hurah!). You might get Martin to put it up on emutalk

Cyb

 

[Zombie9246]

If you use a UDP method, thats very well suited for peer to peer gaming. What data thats in the packets and the time stamping are very important i beleive. You don't want to have to send stuff to the client when you could fine a way around without having to send some type of data. Packet-loss in UDP can also cause complete pauses and even broken connection.

As for the gaming speed and smoothness, as long as the gaming computers involved can render the game at 60FPS(offline) the netplay code shouldn't have to require much emulation pauses on the faster computer. So no lowend to highend PCs and instead...highend to highend PCs or at least equal in power.

 

[Rice]

Cyberman

I like your post very much. Is it too long to follow? I have to go back and forward because it does not fit into one screen! Just kidding.

I think you have pointed out a few very important things, and you make me have to share my key ideas here.

So try these:
- Use TCP, not UDP to do game control and player status update
- Not programming a server, but just doing peer-to-peer, or I should say peer to mutliple peers netplay because N64 has up to 4 players
- KEY: sync to projected frame count per interval (0.1s), this will make full speed game play possible with 1 interval key input lag

Now a quiz to you:
1. How to play the game at full speed during the interval, and still listening to update from other players?
2. How to project the frame count at the next interval?

Possible answers:
1. Multiple thread for network connections and play status udpate
2. When a player updates its status to other players, will tell his current frame count and current increase rate.


Now what will be your answer to the quiz questions?

Want one more quiz, Why do I say the interval will be 0.1s? Should it be 0.05s, or 0.15, or 0.2s? What factors should be considered to determine this value?

(Now I think this thread has come to the interesting point)

 

[Rice]

If you look at a very famous Snes emulator like Zsnes]

I hope the one we are trying to make will be similar to, but better than Snes.

 

[Hacktarux]

I think we can make something like a ring :
player1 <--------------player4
| /\
| |
\/ |
player2 ---------------->player3

Each member receive a control's status of a player and modify it on its own emu and then transmit the information to the following member.
I think this can simplify positively the data transmission.

Concerning the interval length, i think that if it is big, we must have similar configurations, maybe the emu could start with a low delay and then increase it when it has enough information of the different machine's speed to synchronize them.

Note: my diagram seems to not be very well displayed on the emutalk forum, but i think everybody have understand what i wanted to show with this.

 

[Rice]

Hacktarux

I would rather that every player just send its status update to all the other players (update to 3 remote players). Whenever a player has got updates from all other players, then this player can use the latest udpates to start a new interval, at the meantime, this player will send his new keypad udpates to other players.

Just to remember that it takes time for a TCP packet (containing the keypad updates) to arrive all other players, and it even takes relatively long time for a modem user to send out such TCP packets(each TCP packet to one remote player), and what we try to do is to let every other players get updates in shortest time interval. It will be three times slows if we are sending player updates in your way, because it will take up to 3 times longer for the latest player to get the updates of the 1st player.

In fact, we don't know who is the 1st players, and who will be the latest player.

About the interval lenght, 0.1s is my guess based on my testing of the network response time of a regular 56K modem user and considering network transmission speed of a 56K modem. If our netplay DLL is smart enough, for each player, it will be able to do some testing to determine the the best interval, and tell the value to all other players. And then all playes will use the longest one among all the values from all players.

 

[Hacktarux]

Hmm, sorry, i misunderstood what you said, now that you have clarified it, i must admit that the solution i have made is quite stupid

From what i have understand, we must have a thread that makes the following :
-wait until the delay is done
-then block the emu and launch 6 threads:
1) 3 threads that sends current status
2) 3 threads that receive the status of the other players.
- then we wait until these 6 threads have finished their jobs.
- if i am not the fastest computer then i have to wait until i reach the same point as this one to apply the new status.
- if i am faster than the slowest computer i have to slow down the emulation.
- then we loop from the beginning

Easy to say but...

 

[Rice]

Wrong, you are still wrong.

Assume at the beginning of each interval, we already have updates from all othe players, and all players are synced, then we do:

1) Packet sending thread will send out local player's keypad data to all other players, the thread will go to sleep when it finishes its task
2) Packet receiving thread is listening to the incoming packets from other players, when it receives a packet from other player, just put the packet to a buffer to be checked later.
3) emulators is free to run at full speed until the projected frame count. While the emulator is running, it is using the keypad data at the beginning of the interval, even for the local player, so there will be a 1 interval input lag


At the end of the interval, 1), 2) and 3) should all finish. Then we can check the new updates from other players (packets are stored in buffer), project a new frame count to sync to at the end of the next interval, and then start a new interval, and so on.

 

[Cyberman]

I see potential trouble with just PEER to PEER communications.

First One:
One 2 One Knowing what sockets etc. are available from the other user for communications. It is very important you do not use a fixed socket for UDP communications. Why is this important? People can spoof that UDP port with garbage for cheating or just being a PITA to you.

Second:
You know MSN uses UDP for handling data MOSTLY. However you connect to a server (fixed Socket and IP address) to get the peer to peer information. How do you plan on doing that? What you'll end up with is fixed TCP and UDP ports, this is a bad thing. Also a number of ISP's block Sockets 1024 + from passing through there network. Connecting TOO something isn't a problem but something connecting to you will be in this case (experienced by me .
Something has to handle the data in between, a server is fine especially for things like keeptrack of scores (it's possible to do), also allowing you to play against someone else without having to know there IP and socket information for exchanging data. That's what servers are for, to make the clients life easier (and therefore users). However a server isn't immediately necessary.

Third:
Sync data
Key Frame sync (IE at 60 FPS this is image 120) etc. You might want to have a progressive scheme on this, starting out with a short interval and increasing the interval so it self optimizes. Expecting every machine out there to run at 60 FPS might be a bit much. Also you have PAL to consider (50 FPS).

Joystick changes should be sent when they happen. This allows for real time operation. If you send it on the Frame sync Ummm things will lag on the remote end. This won't be noticable on an LAN (like I have) but across a modem to another machine lag can be from 12ms to as much as a minute.

A good way to test this is to use 1 high powered system and one under power system. Why? because it will be great for testing lag between the machines

Obviously PEER to PEER would be a good first step. I suggest working toward a server with PEER to PEER added in. This would allow People to know who is playing what what the high score is etc. (Duke frag anyone? Turok Rage Wars?) So... all these things can be done without the actual machines getting spamed a lot.

Now for each oponent you need a socket..
TCP that's 3 sockets (this is why fixed sockets is a sort of NO NO). UDP same deal. 2 person games only need 1 socket 3-2 4-3 Each person has to send essentially the same data to all three clients. How do you plan on syncing them all? The only thing I can think of is everyone syncs to the key frame data.

That brings up another problem, how do we know how many frames have been rendered?

Cyb

 

[Zombie9246]

Could it be possible to just use UDP for input? Less input delay maybe? As for Peer to peer UDP, suitable for mainly just 2 ppl i was intending to mean. Since in p2p connections one could have a disadvantage, have a buffer to help simulate a server-like situation to equal out things? Using strictly TCP is a lot of latency. You gotta wurry about ACK packets wich overall slows things down when a UDP packet would execute apon recieving(if timestamp is new enough). I think trying to set up 4 player netplay is a bit too high for N64 emulation at this point in time.

As for spoofing and spamming on a fixed port, i just don't see THAT much of a wurry if its just you and some friend playing netplay. Other emu's use a fixed port and i don't see a problem in theres. Maybe if you were all planing on a huge organization of netplay gaming, you'd need to wurry more? I see netplay as more isolated i guess. I also don't see people bothering trying to cheat in N64 netplay because it'll be cool enough as it is just being able to play online! Its not quite up to the point where PC online gaming has gotten.

 

[Cyberman]

Could it be possible to just use UDP for input? Less input delay maybe? As for Peer to peer UDP, suitable for mainly just 2 ppl i was intending to mean. I think trying to set up 4 player netplay is a bit too high for N64 emulation at this point in time.

As for spoofing and spamming on a fixed port, i just don't see THAT much of a wurry if its just you and some friend playing netplay. Other emu's use a fixed port and i don't see a problem in theres. Maybe if you were all planing on a huge organization of netplay gaming, you'd need to wurry more? I see netplay as more isolated i guess. I also don't see people bothering trying to cheat in N64 netplay because it'll be cool enough as it is just being able to play online! Its not quite up to the point where PC online gaming has gotten.

Call it parinoia

As for 4 player mode.. it isn't a huge step up.
Fixed sockets I think might be a problem though especially for people who have there ISP doing weird things with socket ports. I suppose if you want to not have all that much fancy with setup. You could have a single TCP connection between the 'host' and the client (this case the host is the guy wanting to play a game) and the client in this case is the person trying to play against them. In this case a socket < 1024 is needed 500 would likely be a good candidate. The host sends requests to the client for testing what sockets work. Then after that.. you two packet each other with data

Cyb

 

[Mayco]

and what happens if one player isn't running @ full speed?

 

[Cyberman]

and what happens if one player isn't running @ full speed?

Everyone runs at the same speed.
Otherwise there is no point sending out frame syncs.
There were prior to this about 3 seperate times long diatrabs about this

You can't avoid it really.

Cyb