Cthulhu-throwaway - request

[LibretroAdmin]

@Cthulhu-throwaway Could you please be in the Discord even in a limited capacity? There's all sorts of netplay talk going on there and there are people reacting adversely to some of the changes made to netplay, and it could help a lot if the main netplay coder is there to basically explain some of these things. And maybe also sometimes there's feedback posted there which could help in further improving netplay.

I ask them to post Github issues here instead of on a Discord but I can't always get them to do it by themselves.

[LibretroAdmin]

I'm talking about this:

WipMonkey — Today at 03:03 I'm not fluent in C and I can't seem to find the answers in code for this: for netplay, why does it listen on udp 55435 (and some other seemingly random port)? the faq only talks about tcp. Also the tcp listening is happening on ipv6 is there a setting to force it to only use ipv4? sudo netstat -tunlp|grep retroarch tcp6 0 0 :::55435 ::: LISTEN 1015475/./retroarch udp 0 0 0.0.0.0:52004 0.0.0.0: 1015475/./retroarch udp 0 0 0.0.0.0:55435 0.0.0.0:* 1015475/./retroarch

let me know if this is the wrong place. It seems like a very technical question. PasNox — Today at 10:44 is not udp/random ports part of the upnp stuff ? ie it would open random ports on your rooter to allow netplay @WipMonkey ^ Btw, I never succeed in having netplay working, anytime I try it launch game ,then said netwplay failed xD radius — Today at 16:12 You only need 55435 (or whichever port you have configured) WipMonkey — Today at 17:17 That's what what I thought but if I forward the "random" port (along with 55435) then I get no error and see myself in the lobby. WipMonkey — Today at 17:18 If UPNP is required I can't use it but even with that one my friend had no luck. PasNox — Today at 17:27 upnp is a mechanism to automatically ope/close random ports, then you normally don't need to open them yourself. Still, no idea if RA use upnp radius — Today at 17:47 @WipMonkey I open just 55435 and it's fine... well I did it's currently messed up if I hit start netplay host it reinits the game WTF... updating RA is always a wild ride and retroachievements login gets invalidated if I don't start RA in a few days I guess the tokens expire or something so now starting netplay reinits everything and restarts the game NICE! this is too messued up and then I get failed to initialize netplay I give up, I won't even try to debug this BoardsOfCanada — Today at 17:58 Cthulhu-throwaway maintains netplay also the reinits everything thing is it updating the core to make sure the core is updated on both ends you might be overreacting a bit or failing to understand something he did - overall netplay has improved a lot since he worked on it you could always leave a Github issue about it and he would respond please leave these comments in a Github issue where he can actually read it so we can discern if there is an actual problem or just a misunderstanding of how things work now he doesn't read this Discord so there's no point in writing stuff here radius — Today at 18:04 reiniting when you start a session is just bad, if you were going to rejoin someone mid session you just killed everything nuked it and you have to start from scratch think... final fight you were playing coop player leaves another one joins radius — Today at 18:04 back at the start of the game radius — Today at 18:04 and it doesn't even work at all now radius — Today at 18:04 it always says failed to init netplay radius — Today at 18:07 it should never force a core update and furthermore, even if it was a good idea it will fail to init netplay now sonninnos — Today at 18:08 Or something else is afoot radius — Today at 18:09 @sonninnos well I did take the time to try with a clean config no dice hunterk — Today at 18:09 any chance it's thinking your core is outdated when it's not? radius — Today at 18:09 latest nightly errr latest master regardless, imagine you're playing final fight, you're mid game... lets say second to last stage, you were hosting but noone joined so you were just playing alone @hunterk just tried updating manually just in case nada [ERROR] [Netplay] Failed to bind port 55435. [ERROR] [Netplay] Failed to bind port 55435. [ERROR] [Netplay] Failed to set up netplay sockets. [ERROR] [Netplay] Failed to initialize netplay. anyway, I give up, not going to do anything constructive since I'm really really annoyed, cheers

[LibretroAdmin]

radius says the current issue he is experiencing is this -

"you start netplay on windows, it reinits everything, starts the game again, and it says failed to initialize netplay"

[ghost]

There is so much misconceptions in here that I don't even know where to start.

1. UDP port 55435 is used by the host to answer LAN discovery queries.
2. Forced content reload is only performed on the end initializing netplay, that means he is completely wrong in assuming that the host will keep reinitializing.
3. Content reload is necessary for the following features: redirect save files to a special directory (client) and core update (client/host).
4. Some platforms absolutely need to reload content (mainly static core platforms) while some cores won't work well with starting netplay mid session (see: https://github.com/libretro/RetroArch/issues/14193#issuecomment-1192151050).
5. His error is related to port binding and has nothing to do with content reload.
6. Forced netplay core update can be disabled just like you would disable a single core update, LOCK THE DAMN CORE!!! This was discussed to death in the issue and PR.

I am running the latest nightly on Windows without issues (netplayed on random rooms a couple of times so far).

Copypaste from a message I've sent to someone else:

I am so glad I am not on Discord anymore. Someone gave me a dump of the #netplay channel and it’s 90% people bitching about problems by trying to netplay on non-supported platforms (with the FAQ having its own section saying those platforms are not supported) and the other 10% is some guy replying with bot-like messages telling people to use Steam Remote Play Together, a fuckin streaming service.

This is the place to handle development discussions without all the vitriol that you've on Discord; he has both an account and committed to this repo many times in the past, I can't see why he can't just open an issue (other than having some kind of beef with me). All recent netplay issues are now closed as completed because I've gone through all of them, there is absolutely no reason to throw fits at me over platform-specific issues.

[ghost]

I also check the official forums every day and I talk to both @sonninnos and @hizzlekizzle there through private messages, if opening a public issue is not desirable.

[LibretroAdmin]

He says there are deadlocks when using RetroAchievements -

radius — Today at 18:47 I haven't changed anything yet, just fixed my cheevos loging, and cheevos is async as you >? > know, so the reinit caused RA to deadlock here

Is this reproducible? Is there a way to fix this?

[ghost]

He says there are deadlocks when using RetroAchievements -

radius — Today at 18:47 I haven't changed anything yet, just fixed my cheevos loging, and cheevos is async as you >? > know, so the reinit caused RA to deadlock here

Is this reproducible? Is there a way to fix this?

I don't use achievements and this would be a problem within the achievements code. Not my "jurisdiction", @Jamiras should be responsible for looking into it.

[ghost]

On dynamic core platforms, initializing netplay before content will not cause reloads: https://github.com/libretro/RetroArch/blob/master/retroarch.c#L2873-L2891

[ghost]

You cannot change the discovery port because other users in the LAN wouldn't know where to send the query to, it's always 55435 UDP and I haven't changed anything about this port or socket binding for a long while now. Failing to bind the discovery port WILL NOT lead to an error, although other hosts in the LAN won't be able to query your room locally. Failing to bind the customizable TCP netplay port WILL lead to netplay failing to initialize.

His log just says socket_bind() is failing, I don't know the reason because I can both host and join other rooms on Windows 7 at commit d5cc01c, with the core updater automatically updating it before initializing netplay.

[LibretroAdmin]

OK, and I assume the netcode would work the same in RetroArch for Windows 7, 8, 10, and 11? So we don't need to be concerned about potential differences there?

[ghost]

Vista and above use the same API (winsock2). We only have branching for Windows versions below Vista.

Below versions also use winsock2, although with a poorer API: no native inet_ntop/inet_pton or support for socket_poll for example.

[LibretroAdmin]

OK, so other than the RetroAchievements deadlock issue you see no outstanding issue here?

reiniting when you start a session is just bad, if you were going to rejoin someone mid session you just killed everything nuked it and you have to start from scratch think... final fight - you were playing coop, player leaves, another one joins back at the start of the game

What he describes here, is that an impossibility with the curent implementation or is that an actual issue? Is it a wrong assumption or a real issue?

[ghost]

Sorry, but he is wrong and didn't even read my first comment here.

[LibretroAdmin]

Alright, I'll close this issue for now then and I'm going to consider the situation resolved for now. Thanks for your time. I'll try talking with @Jamiras about any potential RetroAchievements deadlocking and seeing if that can get fixed if it can be reproduced.

[ghost]

See, this is why I said I am burnt out with working on netplay, and I've said this privately to you even before I left Discord.

With a few exceptions (see @FinalSlice), there is no intention from the community to assist me with this, and instead of coming here and opening an issue in order to get things sorted (or reading my PRs for better clarification on how some of the changes work), they keep shit talking on discord, and with wrong assumptions, no less. Is there even a netplay-related issue that I haven't answered?

And yeah, I know I lost my cool in the comment above and I apologize for that; I've been really stressed lately for more than one reason, which is another reason for avoiding social media, such as discord.

[LibretroAdmin]

All of your work is highly appreciated at least by me. Please don't let random critics get you down.

We should only be concerned about netplay improving and the pool of netplay users growing, and you have done an immense amount of good work there.

My only interest in bringing these issues to you is to just see netplay improve, just like what your passion and interest is. Let's avoid any and all passive aggressive comments and let's focus on what is important. Nobody is doubting your efforts here, some might but they are not involved in development here anyways so it's of no importance.

Don't let it get you down.

Anyway, one final point:

but if you're mid game and decide you want to have your friend join it will when you start netplay. furthermore, even if you did savestate before selecting start netplay you may end up with an updated core that can't load the savestateit's a remote possibility but it can happen

Is this a realistic concern? Or is this something we can attribute to a misunderstanding too? If it is a realistic concern, is there any way to address it?

[LibretroAdmin]

As far as I'm concerned, you're our only hope for netplay continuing to improve by leaps and bounds. Let's not have a few detractors shut all that down and let's focus on what is important.

[ghost]

Is this a realistic concern? Or is this something we can attribute to a misunderstanding too? If it is a realistic concern, is there any way to address it?

Sure, but that can happen with non netplay stuff too. It's a limitation of the "cores always on nightly" policy.

1. Saved my state and went to bed.
2. (Other day) Updated my cores and went to load my save state.
3. Current core version no longer supports the old save state.

Above example doesn't even do anything netplay related.

And as I've said before, you can lock your core if you don't want to auto-update (core backups also work for netplay core updates).

Content reload is absolutely a must at this point (as soon I've learned that the no audio issue completely vanished once we started reloading before initializing netplay). The client also absolutely needs it if we are to preserve save files written by cores.

So, is this a realistic concern? Sure. Is it an issue? No. The situation described above should be pretty uncommon, unless the person hasn't updated his cores for sometime and you can effectively disable this behavior (although not recommended for obvious reasons) by locking the core and only unlocking it when manually updating.

And if you recall correctly, it was you guys that wanted to update the core to latest when netplaying. I wanted either a netplay-based fork or a "stable" core repository.

[LibretroAdmin]

Alright, I see. Agreed. I think we have touched on all important parts then.

[ghost]

I would like to bring back his point that the forced update is bad; I wonder how often he has been netplaying.

Today (12/08/2022), I've left my public room running mslug on FBNeo for about 2 hours and received about 5 connections, all of them disconnected immediately because they are not running any newer commit of FBNeo (they are likely on stable 1.10.3, since no auto core updates for netplay). This is absolutely NOT a functional netplay design. I've been unable to netplay Metal Slug games on FBNeo since may (when FBNeo broke savestate backwards compatibility for these games) because almost no one update the cores outside of a new stable release of RetroArch.

I would really encourage people to try nightly with the auto core update for netplay. I tend to play 2 or 3 public rooms a week and the only time it's noticeable is once a day, when FBNeo (the largest netplay-supported core at 11-12 MBs) starts downloading, and even then, it depends on whether the buildbot is running slow or not. Content reinit is not an issue at all; it's nearly instantaneous and optional (you can start netplay before loading content; joining a room through the lobby will do that for you). If another feature is deadlocking on reinit, that feature needs a fix. I've been using this netplay update system since implemented and have had zero deadlocks so far (I don't run achievements).

I also check with a couple of brazilian streamers that netplay often in order to get some info of pending issues remaining within the system and I know that at least one of them have updated to nightly; I haven't heard a beep from him about these changes though.

Someone who no longer contributes to netplay, doesn't appear to be netplaying often, but surely as hell knows what the current main issues are. This system was merged a month ago, no issues were opened regarding this and only now did he notice it...

[LibretroAdmin]

Alright, yeah I fully trust that you are making the right decisions for netplay. Don't let it worry you.

We do want to release a new stable fairly soon. I will have to do some tests on the consoles and then it's time to release it. We can hopefully get some more people transitioned over then to the new netplay.

[ghost]

The only real concern imo (which wasn't pointed out), is the fact that the update occurs silently while the graphics interface is not running. If the buildbot and/or the connection are slow, this may cause the sensation that RetroArch has either crashed or deadlocked while downloading the core.

This kind of core update needs to be performed in a place where we are guaranteed the core is not loaded (Windows for example would lock the DLL until unloaded), while also knowing which core is going to be loaded next. This makes runloop_event_init_core the perfect place, but we don't have the graphics interface running there.

We could theoretically create a temporary interface just to display a simple message at the center of the screen, but I am not sure how to go about it in a universal (driver agnostic) way. If you or someone else could point me in the right direction, I can take a look and see how viable this would be, otherwise someone with more experience working with RetroArch's GUI could improve this later on.