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 billyzimmerman@yahoo.com 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]

Originally posted by 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.

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)