Replace all shared interop usage

[bdach]

osu-server-spectator/osu.Server.Spectator/Services/ISharedInterop.cs

Lines 9 to 42 in 0db2ba9

	public interface ISharedInterop
	{
	/// <summary>
	/// Creates an osu!web room.
	/// </summary>
	/// <remarks>
	/// This does not join the creating user to the room. A subsequent call to <see cref="AddUserToRoomAsync"/> should be made if required.
	/// </remarks>
	/// <param name="hostUserId">The ID of the user that wants to create the room.</param>
	/// <param name="room">The room.</param>
	/// <returns>The room's ID.</returns>
	Task<long> CreateRoomAsync(int hostUserId, MultiplayerRoom room);
	/// <summary>
	/// Adds a user to an osu!web room.
	/// </summary>
	/// <remarks>
	/// This performs setup tasks like adding the user to the relevant chat channel.
	/// </remarks>
	/// <param name="userId">The ID of the user wanting to join the room.</param>
	/// <param name="roomId">The ID of the room to join.</param>
	/// <param name="password">The room's password.</param>
	Task AddUserToRoomAsync(int userId, long roomId, string password);
	/// <summary>
	/// Parts an osu!web room.
	/// </summary>
	/// <remarks>
	/// This performs setup tasks like removing the user from any relevant chat channels.
	/// </remarks>
	/// <param name="userId">The ID of the user wanting to part the room.</param>
	/// <param name="roomId">The ID of the room to part.</param>
	Task RemoveUserFromRoomAsync(int userId, long roomId);
	}

All operations here should be replaced with local reimplementations that do not require web to be alive.

[bdach]

I nudged this a bit today. WIP branch at https://github.com/ppy/osu-server-spectator/compare/master...bdach:osu-server-spectator:create-rooms-directly?expand=1.

Brief conclusions:

• The easiest call to replace is CreateRoomAsync(), by moving room creation to spectator server, which the branch above does (with a bunch of safeties skipped to reach PoC status).

• The {Add,Remove}User{To,From}RoomAsync() calls are not removable without extricating the entirety of chat from web, and are generally low-impact in failing anyway (they run async, won't ever fail any operations, all that will happen is "graceful degradation" of not having working chat).

  For now it's probably tolerable to keep multiplayer chat operations as can-fail legacy interop. The other option is to peel chat completely off web, or have spectator server implement its own chat, probably without feature parity.

• Unfortunately all of this is essentially pissing in the wind if the end goal is to have multiplayer work completely with web off, because to have multiplayer work completely with web down, we also need

  • The multiplayer lounge to work through spectator server
  • Various room API lookups (user / beatmap lookups and such) to work through spectator server
  • Submission to happen through spectator server (Move score submission to spectator server off of web #367)

So it'd only be step one of several, and I haven't even done the grueling work of porting all of the validity checks that web does to ensure nothing stupid gets created.

@ppy/team-client would probably like acknowledgement and clear agreement that we are to pursue some or all of the above steps to fully peel off multiplayer from web before I proceed any further.

[smoogipoo]

• The multiplayer lounge to work through spectator server

This is the easy part. I have a branch somewhere...

• Various room API lookups (user / beatmap lookups and such) to work through spectator server
• Submission to happen through spectator server (Move score submission to spectator server off of web #367)

It sounds like it honestly would be easier to just say "PHP/Laravel slow" and create an ASP.NET service to replace the API that preserves the shape of osu!web requests, than to try to inject all of this (perms, etc) into spectator...
Otherwise I do wonder if all of this is just kicking the can down the road for when spectator starts dying the exact same way and we are unable to scale it.

After all, spectator already uses dedicated pods for LIO, so if that's failing then either PHP is too slow or the database is failing (such as in recent times), in which case if we rely on the database at all anymore then we're susceptible to the exact same failures.

---

I don't know that multiplayer is a good starting point for this. The primary thing kicking people out there is API failures: https://github.com/ppy/osu/blob/bd4ed49c067467347429480c8ee25725bd20bff5/osu.Game/Online/PersistentEndpointClientConnector.cs#L69-L76

i.e. This would cause intermittent disconnects, which stateful reconnects would probably cover for... Though the code is very dodgy (why should we disconnect these components on API failures in the first place?).

Probably score submission is the more important one to resolve.

[bdach]

why should we disconnect these components on API failures in the first place?

Because if you don't do this given the current shape of things then multiplayer falls apart.

Example: I tested this branch with a local web instance to see what happens. Testing was via killing nginx.

And sure, after you turn a bunch of client safeties off, this branch makes it so that you are able to technically create a room without web up (in api Failing state). But what of it, given that the client dies instantly on an assert because API lookups of users in the room are failing? Or because beatmaps can no longer be fetched so you don't even know if you can start playing the current playlist anymore?

As you say maybe the answer is to just call laravel slow and reimplement everything in webapi. Obviously this isn't going to give any guarantees that things will behave better. My experience with infra-wide changes of this scope isn't that big but my belief is that wide infra-wide changes like this are never assured success.

The main point is that I've been given a mission statement to detach as many client pieces off of web as possible. I am attempting to execute on this statement. I can abandon it or continue, and I am fine with either, but I do need everyone looking at what I do to tell me to either continue or not so I don't waste everyone's time (including mine).