sceNetAdhocctlInit waits until the friend finder has logged into the adhoc
server, polling in emulated time but giving up only after 5s of wall time.
The friend finder makes one attempt per login request, and it too waited
the full 5s on a connection that had already been refused, because it
only looked for success. Now it checks the socket error and gives up at
once, and records the failure so the wait ends with it.
In headless, which runs far ahead of real time, Gods Eater Burst sat in
this wait for its whole run.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The friend finder thread set friendFinderRunning itself, after a DNS
lookup of the adhoc server. A shutdown in that window cleared the flag
first; the thread then set it again, looped forever, and the join in
NetAdhocctl_Term() never returned. Gods Eater Burst hit this in about one
headless run in six. The flag is now set before the thread is created,
and a finished thread is joined before a new one replaces it, which
would otherwise call std::terminate.
The built-in adhoc server thread had the same race, behind its check for
an existing server, and gets the same fix.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With WLAN on and no server reachable, sceNetAdhocctlInit keeps its thread
waiting for the login. The load dropped the request, and the wait ended in
BUSY, which Init can't retry. Splinter Cell then ran its failure path with
a deleted event flag. Also stop freeing matching event buffers into the
restored allocator, and take the event lock when clearing.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Make GetPdpStat behave more like in P2P mode
- Now fetches accumulated ready to be received amount of data
instead of only the immediate to be received Pdp block
- Make GetPtpStat behave more like in P2P mode
- Now fetches accumulated ready to be received amount of data
instead of the size of the next server send block
- Make PtpRecv behave more like in P2P mode
- Fix block like behavior where whole server send block has
to be consumed before getting data from the next send block
- Fix block like bahavior where sender sends in small PtpSend
calls while receiver receive with less frequent but bigger
buffer PtpRecv causes bloat(and eventually server kick)
on relay
In P2P mode, this issue was solved by resolving the final IP
address without the first byte. Fix the issue again for relay mode
by resolving the true mac address before sending.
True mac resolving was also added to relay mode ptp connect as a
precaution.
- bump aemu_postoffice
- timeout TCP connection attempts at 5s to not block the library user too much
- set send and receive buffer sizes after connection to avoid some blocking cases on some platforms with small defaults (windows?)
- pop OSD message when relay connection fails
Add various data fields and logic to handle:
- automatic adhoc data mode handling
- future UI expension on server list
- future support for automatically downloaded/user provided server list
PDP recv with buffer < packet size was not implemented correctly
as far as FlatOut Head On is concerned. Fix relay PDP recv
implementation to report required size without consuming the next
PDP packet so that it behaves like P2P mode does.
