Infrastructure/online support #14256
Comments
|
How do you setup the DNS? Edit: On PPSSPP i can just use that IP as default Primary DNS Server (which currently use Google DNS 8.8.8.8 i think) for Apctl info, or may be add an option to change DNS Server in the future. Btw, does ATV infrastructure worked yet on JPCSP? |
|
I didnt try on JPCSP. |
|
seems to be fixed on the JPCSP update: |
|
This is the logs from SOCOM Bravo 3 And apparently this game also being flooded with Vulkan errors LOL, or may be because i'm using Debug build? |
|
Socom is not working currently. |
Based on one of the comment: |
|
I guess you have to use JPCSP or a real PSP for now. |
it won't work either, because my internet connection is the main issue LOL mobile data connection aren't allowed to have open port The only way for me to test it is if i host my own private server locally, or if the private server is located inside a VPN, and i have access to the VPN too. Btw, this is the Logs from ATV, which have similar issue when attempting to send something to DNS Server |
Well yes that's because you are using 8.8.8.8 as your primary DNS. Google's DNS doesn't have information about that domain other than it goes to nothing basically. That's why you have to set the Primary DNS to the 104 IP. That's our DNS server that then turns around and sends back the IP address for the server that the game is running on. |
That's only for hosting a game since the game is Peer to Peer. |
So basically the private server is only for match making, while gameplay will be just like Adhoc/LAN Multiplayer which communicates directly PSP to PSP instead of something like online multiplayer on PC (ie. Server to Clients)? |
Well that entirely depends on the game. Some games are UDP while some might be using TCP or TCP with auxiliary UDP. In this case with ATV all the communication to the server is over TCP (it maintains this connection while you are in a match) and the game traffic is UDP. |
See the DM I sent you on the forums. |
|
Hmm... this DNS Server Unreachable issue might be because the socket bound only to localhost IP 127.0.0.1, it probably need to bind an interface that have access to internet gateway... Edit: Screenshot
Using 104 DNS Server also have similar issue and took longer to get the reply Screenshot
The strange part is that the game seems to be expecting something from another socket which is bound to port 6431 Screenshot
|
The port you are mentioning is something on the client. That's what the client decided to use to talk to the server on. The ports that the server can use are: TCP UDP (This is for P2P games and is more or less a client thing) There are a few other ones that a game might try to connect on but as far as I know they weren't common across all games and were non NTSC versions of games. Not that it really matters but generally speaking those are the ports that most games will try connecting on. |
|
Current issue is that the game is not even trying to connect or send anything to a Lobby Server, and i'm not sure how to trigger the game to at least attempt to connect to the Lobby Server. This is the Log from Init to the appearance for that "Connection to lobby server failed": Click to expandIt should atleast try to connect or send to somewhere after successfully resolving DNS, but never did that... may be it failed to resolve the DNS? |
So it could be that your ISP is blocking this change either at their level or through your modem. This is an issue we have with some people and their ps2's / pcsx2 and we have some work arounds for this. The easiest one is just loading a cheat code that replaces the domain with the IP of the server. The only problem is this is currently running on the test server and will eventually be moved to the main one. You could try this code: Or if that doesn't work you could also edit a config file in the ISO mMASServer="104.237.9.163" In this case the DNS server is also hosting the test server for online games. |
|
Also forgot to mention that there are some games that use PSN to connect and some that don't. |
I made a post on the ppsspp forums that mentioned this but I guess that forum does post moderation. There aren't many games that require PSN to begin with on the PSP. |
|
@Zero1UP Sorry for the slow moderation. It's unfortunately necessary due to a huge volume of spam. I've approved your post. |
Ah that might be the case, i remembered that i can't access some websites even with 8.8.8.8 because i feels that my ISP is redirecting all dns queries to their DNS server, where i need to use DNS over HTTPS on dnscrypt to prevent this from happening :( Looks like i need to implement Btw, is that |
That code is a text replacement for A hosts file for the emulator would pretty nice to have. It would certainly make testing things easier. |
|
Hmm hosts file support might not be useful ini this case.. since ATV is trying to communicate directly with DNS Server instead of using API to resolve hostname, and i've seen many PSP games do similar thing. In this case, if we wanted to use hosts file, we will need to be able to recognize whether the packet being sent to port 53 have a valid dns request format or not, if it's then try to resolve it locally, otherwise treat it as regular packet and send it. Changing the hostname using cheat probably the best one for now :( i never liked to use cheat code since they're specific for a certain version only. Btw, does anyone have created a cheat code compatible with PPSSPP (was it cwcheat? i'm not familiar with cheat format) based on this replacements where i can simple copy it to PPSSPP? |
|
Okay, i ended using Speedify VPN to access the internet, and DNS 104 is working properly now :) Well, at least the game is progressing further by trying to connect to lobby server, but i haven't implement TCP-related HLE yet LOL The new Logs with Unimplemented Click to expand |
|
Well at least it works on JPCSP but you HAVE NOT to include flash0/prx files folder for now: You need JPCSP from here: |
|
Hi,me again.I don't usually bother on others issue,but would @mojojojodojo be kind enough to explain how is Infrastructure getting back?What is it? TIA |
|
Hmm.. looks like there are game(s) that need infrastructure support even on single player... #9035 I wanted to implement |
Yes a private infrastructure server have been made for playing games online on various games (Also includes PS2 games). |
|
Updated infrastructure test builds:
Windows build: https://sam.nl.tab.digital/s/jBfmcNif4mQDWLR PS: Since this WIP infrastructure support doesn't have socket class/wrapper yet, using Windows' socket id as is (which usually have a number of 4-5 digits) will potentially caused memory corruption when the game is using it on Edit: Updated Linux build with Release build, previous upload was Debug build which is slow. |
I'm not sure if it's just me but it seems that this build just ignores the DNS setting in the INI file in the linux build. |
|
I recently noticed that FTB2 is also trying to use secondary DNS which is hardcoded to 1.1.1.1, thus resolving to official server instead of private server. PS: The reason i hardcoded it to public DNS server like 1.1.1.1 was because some custom DNS for private servers only resolves game-related domains and doesn't resolves general websites, before, i wasn't aware that games might be using both DNS even when the primary one was able to resolve properly (may be the game is using the fastest one to resolve) |
|
@anr2me There appears to be an issue with R&C: Size matters on the windows infrastructure builds that causes it to hang. However, it appears to not be an issue on the linux build. It might be bind/upnp related. This can be tested using the DNS IP 135.148.144.253. |
|
It's probably socket id things since we don't use a socket wrapper to convert the id yet, so using id given by the OS directly expected to have some issue. Linux's socket id(s) are mostly under 64 which matched the expectation of some PSP games (some games expect the id(s) to be under 64 and always set the Android's socket id(s) are mostly below 256 (which is still valid for PSP socket id, since PSP only supports up to 255 sockets, but will have an issue on games that expect the socket id(s) to be under 64). Windows' socket id(s) are mostly above 1000 (which is clearly not a valid PSP socket id), expected issue are:
This mean Linux's socket id have the highest compatibility (probably MacOS/BSD too, not sure about iOS) to PSP's socket id. Anyway, many issue will automatically be fixed when i have the socket wrapper ready (didn't have the time to work on it yet, since most of infrastructure code will need to be changed), i also need to retest socket id created by Adhoc and Infrastructure to see whether i need to use the same base class for them (and merged them into a single vector), because i remembered seeing the id increases for each Adhoc/Inet socket creation when using both Adhoc and Infrastructure together during my test in the past (didn't have the test code anymore) |
|
The beta size matters works fine on both Windows and Linux though so its a bit strange why it would have issues only with retail. |
From what I can tell, the retail NTSC version of the game initialized UPnP differently than the other variants. You can see it attempting to communicate to open ports if you packet capture the comms. It is attempting to open ports at the exact same time it's trying to connect to the medius server. There could be some other underlying issues as well and I don't think I have enough data to rule that out. |
|
UPnP request are done on a separate thread than the emulation thread to avoid stuttering (the early stage of UPnP implementation didn't use thread and many players complained about the stuttering it causes in the past), as a result the actual port opening process might be delayed a bit. When the game request for a port to be opened it passed the port info to the UPnP thread while the emulation progressed further, how long it takes to open the port depends on how many request being enqueued and how long your router can process each request (can takes up to 500ms per request on a slow router), so at the time the port actually opened the game might already tried using the socket (ie. expecting incoming data). However, if the game is connecting to medius server using TCP, it probably act as a client (usually client have a random port), and client doesn't need opened port, so UPnP won't affect this kind of connection. |
|
On NTSC retail the game uses 2 ports which are 1900 and 6368. EDIT: nvm I though it uses the same domain name as PAL but it uses a diffrent one. |
|
errno = 10060 is a timeout error tho, it's a server side issue (ie. dead server or the server were too busy to handle new connection), or the game is trying to connect to the wrong IP (ie. official server) If the game failed to connect it's normal to retry again (ie. looping for a few times, sometimes even for infinitely) by closing old socket and creating new one, which can triggers opening the port again, however since our UPnP implementation keeping tracks of opened ports, if the game tried to open an already opened port it won't send the request to the router again (which saves time and avoid flooding the router with unnecessary requests) |
AFAIK port 1900 is used for UPnP device broadcasts So this likely a packet sent over LAN to ensure no other device has the ports it's requesting already open |
That's all the logs I am getting. |
|
Some infrastructure games did tried to dealt with SSDP directly, they probably use a third-party UPnP library instead of sony's UPnP library (which is why they use low level sockets), similarly i've seen games that try to download through HTTP port 80 directly using low level socket instead of using sceHttp library (most-likely came from a third-party HTTP library). So those logs are probably came from third-party library trying to do low-level internal things. |
|
Vita3k is also implementing infrastructure too now: |
|
Have you looked at updating the infrastructure build with the recent updates released from the official builds? (1.15.4..etc) Let me know if this is still something you’ve want to look into again. So far, 1.13.1-18-g9ad52e50c has been working flawlessly but has not been updated in about a year since release. Thanks! |
|
Sorry, i wasn't able to work on anything due to bad sectors issue. Was trying not to change any files i was working on and risking it to be saved on a bad sector. I think, i should be able to spare some cash to buy a NVME this month (if nothing urgent came up), was planning to get Adata SX8200 Pro 1TB (hopefully still in stock), but kinda hesitate to upgrade my laptop (from 2018) as it also shows other faulty symptoms like flickering display's back-light. |
You can get an up-to-date infra test builds from Github action's Artifacts now. I'll try to create more workflow to generate iOS IPA and Windows UWP later Edit1: Updated links Windows/Linux/MacOS Artifacts at https://github.com/anr2me/ppsspp/actions/runs/7310716391 PS: IF those artifacts expired, you can try re-running the workflow |
Thanks! Appreciate the reply and the work to make this possible for current revived games. |
At least with the windows build any connection it tries making out to a server (even on local) it will take a long time and sometimes just drops the connection or hangs. The game I was testing locally with was Socom tactical strike but it was also doing it with Socom Fireteam Bravo 1 and 2 52:59:937 Coroutine E[SCENET]: HLE\sceNet.cpp:1882 UNIMPL sceNetInetInit() |
|
Is this issue only happened on the new version? because my infrastructure implementation hasn't been changed for a long time, just keeping it up to date with the latest PPSSPP, so it should be the same with my older builds. But based on the socket error 10061 (connection refused), it seems the server is dropping the connection, and the game might be didn't know/have a handler for that kind of error code and got confused. Anyway, i won't be able to continue working on this anymore, but fortunately, there is someone who's working on infrastructure implementation (and wrote a cleaner code than mine) #18578 |
Yea the server closes the connection because the game just stopped sending data. I'll do more testing later. Thanks for all the work you've done just implementing this into the emulator to begin with. |
|
Btw, in the past, there was an issue where You can try disabling HTTPS support on PPSSPP to see whether it behave differently than HTTPS being enabled(the default), in case this problem were affected by the same issue too. like this example #17972 (comment) |
Yes thank you for making this possible @anr2me :) |
and others
There was an issue open for infrastrucutre but they removed the part of it so I will do it again.
So infrastructure is getting back on the PSP .
First game that works is ATV Off Road Fury Blazin' Trails.
To connect you need to use the 104.237.9.163 DNS on a real PSP.
For now you cant connect because the infrastructure feature is still unsupported on PPSSPP.
The text was updated successfully, but these errors were encountered: