[garbear]

Video decoding (for e.g. GameStream) has been removed from RetroPlayer because it used some private VideoPlayer APIs. I'm taking this advantage to redesign RetroPlayer for multiplayer support. Because this involves encoding and stream video, not just decoding, we basically get GameStream for free.

My design requirements for multiplayer RetroPlayer are pretty expansive. I'll list them here:

• Serverless, p2p design
  
• Social discovery
  
• Global discovery
  
• UDP streaming for high speed / low latency
  
• NAT transversal via ICE, STUN and TURN
  
• End-to-end encryption via DTLS, SRTP and SCTP
  
• "Heavy clients" (stream savestates and reconstitute video/audio)
  
• "Light clients" (encode and stream video/audio directly)
  
• GameStream support (accomplished by light clients)
  
• Global spectator mode - basically p2p twitch
  
• Multi-environment single player
  
• Optional playback control (RW/FF/seek)
  
• Random host negotiation
  
• Auto-detect host negotiation for lowest latency or lowest bandwidth
  

OK, so "expansive" was an understatement. There's a lot of complexity here, but I'm working on some abstractions that can manage all these points.

Let me know if you think anything should be added/removed from the list.

[Scourge]

OK, so "expansive" was an understatement.

I don't think anyone who followed your work over the years would have expected anything else

Is the whole player profile discussion in scope for this as well or would that be another part of Retroplayer/Kodi?

[Julipo]

It will be a shame if is not compatible with other libretro systems like RetroArch. RetroArch is preparing to launch next-version of his app with improved netplay and future match-making in mind. I'm not expecting that RetroPlayer will use the RetroArch match-making system, but I hope that you can play with other retroarch players (from Windows or linux application, RetroPie compilation, android app)

[garbear]

Is the whole player profile discussion in scope for this as well or would that be another part of Retroplayer/Kodi?

To keep the complexity down, player profiles are separate from RetroPlayer. All it cares about is the port number and the controller state.

That said, I'll certainly make sure RetroPlayer won't need to be modified later to add player support, so adding players to the mix isn't off the table.

[garbear]

It will be a shame if is not compatible with other libretro systems like RetroArch. RetroArch is preparing to launch next-version of his app with improved netplay and future match-making in mind. I'm not expecting that RetroPlayer will use the RetroArch match-making system, but I hope that you can play with other retroarch players (from Windows or linux application, RetroPie compilation, android app)

I didn't add this to my list of requirements, but one of my personal goals is to enable multiplayer between Kodi and the browser using an Emscripten-compiled RetroArch. The main RetroArch pieces missing here are in javascript territory, so I'm not sure how much it'll benefit native RetroArchs.

At the end of the day, interoperability with RetrArch is directly related to how similar our design requirements are.

I also didn't add this to my list, but I'm studying artificial neural networks so another design requirement is compatibility with reinforcement-learning algorithms. The multiplayer interface I'm designing is highly theoretical (and beautifully simple), but RetroArch might intermingle some of the concepts, so RetroArch might require some work. I'll give examples when my interface is done.

I am also interested in latency, and currently there is only one technology that can shove high-bandwidth, low-latency data between any two peers on the planet: WebRTC. WebRTC is one of the greatest software engineering feats in the last 5 years. It's the key to browser interplay. It offers the highest performance video, audio and data streams. It can transverse NATs and firewalls. There are two implementations, WebRTC (by google) and OpenWebRTC (by a swedish company), so there's more likely to be a solution for a given platform.

And finally, a requirement I glossed over is "Serverless, p2p design". This means a fully decentralized system (or at least minimally centralized). If RetroArch uses a server for match-making, it probably falls outside the requirements above.

Can you give a list of design requirements that RetroArch is trying to tackle? We can go from there to see how intercompatible we can make our systems.

[Montellese]

If you need help with the technical stuff around DTLS and SCTP I might be able to help out because I've already done this and it's an awesome combination (but a bit of a pain to get it working). I've borrowed lots of ideas / concepts from WebRTC but couldn't use WebRTC itself because it didn't fit the use case.

[garbear]

I was planning on an API to mirror RTCDataChannel and RTCPeerConnection, and then implement it with a hodge podge of WebRTC, OpenWebRTC, and protocol implementations translated from other languages. RTCDataChannel looks like it fits our needs, because it can be abstracted as a data stream between two peers. Is this the use case you're referring to?

[Montellese]

Yeah RTCDataChannel should fit the need here. My use case was different so I "stole" the transport layer implementation but ran my own protocol over it.

[Hedda]

Video decoding (for e.g. GameStream) has been removed from RetroPlayer because it used some private VideoPlayer APIs. I'm taking this advantage to redesign RetroPlayer for multiplayer support. Because this involves encoding and stream video, not just decoding, we basically get GameStream for free.

My design requirements for multiplayer RetroPlayer are pretty expansive. I'll list them here:

• Serverless, p2p design
  
• Social discovery
  
• Global discovery
  
• UDP streaming for high speed / low latency
  
• NAT transversal via ICE, STUN and TURN
  
• End-to-end encryption via DTLS, SRTP and SCTP
  
• "Heavy clients" (stream savestates and reconstitute video/audio)
  
• "Light clients" (encode and stream video/audio directly)
  
• GameStream support (accomplished by light clients)
  
• Global spectator mode - basically p2p twitch
  
• Multi-environment single player
  
• Optional playback control (RW/FF/seek)
  
• Random host negotiation
  
• Auto-detect host negotiation for lowest latency or lowest bandwidth
  

OK, so "expansive" was an understatement. There's a lot of complexity here, but I'm working on some abstractions that can manage all these points.

Let me know if you think anything should be added/removed from the list.

Much of that and more could probabably be achieved relativly quickly with RakNet gaming networking engine, as suggeted here before:

http://forum.kodi.tv/showthread.php?tid=201868

Doesn't however look like RakNet is still maintained on GitGub, or at least no new commits during last year. The project is still getting pull requests, so maybe fork that project or parts of its code? It is now all FOSS licensed under a BSD "as is" license so should be GPL compatible:

https://github.com/OculusVR/RakNet

Old website is still live and lists most features and functions of RakNet but that website have not been updated since Oculus VR bought it and made the software free and open source as a community driven project.

http://www.jenkinssoftware.com/features.html

Still, I think RakNet could be used here to more quicly get a proof-of-concept up and running. Personally I think that the lobby system is most interesting and maybe the hardest to make in a good way for social discovery. From within that lobby it would also be cool to start text chats and voice chat with people you are already connected to as friends.

Key featrures of RakNet 4 include: object replication, remote procedure calls, patching, secure connections, voice chat, lobby system for friends / community chats and leaderboard ranking, and real-time SQL logging. The technology has been licensed by thousands of indie developers, as well as companies like Unity, Havok, Mojang, Maxis and Sony Online Entertainment.

RakNet 4

RakNet is a cross-platform C++ and C# game networking engine. It is designed to be a high performance, easy to integrate, and complete solution for games and other applications.

Autopatcher
Update your users with database driven binary delta patches, or use a simpler version for updates such as user skins or maps.

Remote procedure calls
Call native C and C++ procedures with automatically serialized parameter lists.

Voice communication
Includes audio bindings for Port Audio, FMOD, and DirectSound.

NAT Punchthrough
Essential for voice communication or peer to peer applications. Steam and Steamworks servers supported.

Object replication
Automatically create, destroy, serialize, and transmit your game objects.

Lobby system
Database powered lobby with support for friends, rooms, quick match, ranking, email, and multiple titles.

Secure connections
SHA1, AES128, SYN Cookies, and RSA to prevent and detect network attacks.

Robust communication layer
Automatic congestion control, message ordering on multiple channels, message coalescence, and splitting and reassembly of packets.

[docwra]

Very cool, I can add some feature requests:

Gamercard system (what games you own, have completed, battles won, high scores etc)
Charting for plays and high scores
Unique usernames (Kodi ID?)

Let me know if you need any online services written as a basis for this

[Hedda]

Unique usernames (Kodi ID?)

+1

And for this I guess the best might be to use our Kodi's community forum names as unique usernames if you can get that from MyBB database in a good way?

Maybe if Team Kodi could setup a new SSO (single-sign on) server that gets and syncs usernames and passwords from the Kodi community forum for login?

Perhaps something built from MyBB Integrator or similar:
http://phpdave.com/MyBBIntegrator/
https://github.com/olada/MyBBIntegrator

This could also be a way to further build the Kodi community as you would get more users who might normally not create a user of the Kodi community forum.

[garbear]

Doesn't however look like RakNet is still maintained on GitGub, or at least no new commits during last year. The project is still getting pull requests, so maybe fork that project or parts of its code? It is now all FOSS licensed under a BSD "as is" license so should be GPL compatible:

This is a deal-breaker. We can't adopt a technology that's forsaken by Facebook.

Autopatcher
Update your users with database driven binary delta patches, or use a simpler version for updates such as user skins or maps.

We don't use binary delta patches, and skin updates are already handled by the add-on system.

Remote procedure calls
Call native C and C++ procedures with automatically serialized parameter lists.

We already have JSON-RPC.

Voice communication
Includes audio bindings for Port Audio, FMOD, and DirectSound.

Kodi already has audio bindings for every platform we run on.

NAT Punchthrough
Essential for voice communication or peer to peer applications. Steam and Steamworks servers supported.

NAT punchthrough requires a central server. This won't work if we're required to use RakNet network APIs on the server because the server's environment might not be supported.

Object replication
Automatically create, destroy, serialize, and transmit your game objects.

I'll probably just use protobufs.

Lobby system
Database powered lobby with support for friends, rooms, quick match, ranking, email, and multiple titles.

This would be useful, but again requires a central server.

Secure connections
SHA1, AES128, SYN Cookies, and RSA to prevent and detect network attacks.

I would prefer session security were handled by a standard protocol like DTLS.

Robust communication layer
Automatic congestion control, message ordering on multiple channels, message coalescence, and splitting and reassembly of packets.[/i]

The communication layer is the most desirable part of RakNet, but I doubt that pulling in RakNet's dependencies is worth the tradeoff when all of these things can be extracted from OpenWebRTC. Keep in mind we have to adapt the dependencies to all of our platforms which can be difficult and time consuming.

If we want to move forward with RakNet, we need to answer these questions:

• Will RakNet be alive and supported in 6 years? (6 years is the half-life for Linux kernel code)
  
• What dependencies does it need?
  
• What specific network protocols does it rely on?
  

[garbear]

Gamercard system (what games you own, have completed, battles won, high scores etc)

I'm building support for RetroAchievements.org achievements.

Charting for plays and high scores

Charting requires a central server. What sort of technologies would you use to build this?

Decentralized charting might also be feasible with a reputation system and distributed database.

Unique usernames (Kodi ID?)

This could also be a way to further build the Kodi community as you would get more users who might normally not create a user of the Kodi community forum.

Encouraging cross-participation with the forum would be awesome. Would you also add the option to authenticate with Facebook/Google? Authorization could also occur, allowing you access to friend lists for social discovery.

[tornicade]

I wonder if there would be a way to set up an integrated murmer server that where one of the participents elects to be the host and the the rest are set as clients.

meaning the chat settings would work work as long as someone elects to host that session. I would guess that would require its own add on using ICE

[garbear]

I wonder if there would be a way to set up an integrated murmer server that where one of the participents elects to be the host and the the rest are set as clients.

meaning the chat settings would work work as long as someone elects to host that session. I would guess that would require its own add on using ICE

I'm not familiar with murmur, how does it work? Can it be run inside a browser?