libretro / libretro/RetroArch

[Netplay] Dealing with core backwards incompatibility

Open
#14,149 124 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

netplay networking
Dominant language
C
Stars
14.1k
Forks
2.2k
Avg merge
7h 35m
Merged PRs (30d)
51

Description

Description

See: https://github.com/libretro/FBNeo/issues/996

  1. Core can break backwards compatibility within days apart, without version increments.
  2. Refusal of core developers to endorse a stable repository for cores (outright threatening to cease support).

I've been unable to netplay fbneo for the past few days because the hosts are running RetroArch 1.10.3 stable but fbneo versions prior to the one that breaks backwards compatibility (nightly).
These players are randoms that I just find in the public lobby, simply telling them to update the core isn't possible.

RetroArch netplay's has multiple advantages over other rollback-based services, with its main strength being its support for more than 2 players.
However, with cores not guaranteeing compatibility within the same version (same version number, not same commit), RetroArch's netplay for those cores is not reliable at all.

Expected behavior

Cores should remain backwards compatible for some time, if the version isn't incremented.

Actual behavior

We only have unstable cores in the core downloader/updater, therefore, backwards compatibility is compromised on cores that get worked frequently.

Side notes

I've been working on networks since the early 2000s, and I've never worked on a project where network enabled components were distributed to the general public straight from unstable.
We often had alpha and/or betas (closed and open) before we would push that update to stable and thus, to the general population.
Problems (as shown here) and security leaks are two things you can expect to encounter if you don't follow with these.

@LibretroAdmin You argued a lot with me about keeping netplay backwards compatible, even when hacks were necessary to do so. But this is effectively pointless if cores can and will break it on a whim.
I've been working tirelessly to improve netplay, but I'll stop if this issue is not addressed.
Solutions include the already mentioned stable repository for cores, or a tag in the info files that allow me to display a very visible notification that the core is not reliable for netplay and should always be updated before hosting/joining (this will be a huge problem for platforms which can't update cores from the unstable repository).

It's also really important for netplay users to express their thoughts on this as it affects them all.
RetroArch's netplay seems to always be treated as a second-class citizen and this needs to stop, or deprecate it and recommend other services.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked FBNeo issue and the existing 124-comment discussion, since no files, tests, or code entry points are identified. Compare the proposed stable core repository with an info-file warning for unreliable netplay; the work is done only when a concrete approach is agreed and its compatibility and update behavior are defined.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking, release
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.