Last sunday we had a race in gt3 on Reiza VIR and after some lap we had many disconnection issues, we were 24 drivers. It is not the first time this happen. I verified everything on the server logs but can't figure out. In the trace file, i can see these 2 issues 72317.23s NetCommDedic 2450: Detected 809 ms long freeze while processing status dialog 24 (SetClientListEnabled) 5764.42s NetComm.cpp 1572: System Message(2): "Error (The socket is marked as nonblocking and the requested operation would block.) sending to 185.185.126.201:6788" I have watch server last 3 days and last error with ip appears on a particular driver twice The first error happen randomly
Ask drivers ro reconnect to tha server, and watch their Message Center ... What does it say ? Connection lost ? Other text ? Also, maybe check your bandwidth usage and check if you have enough download/upload.
For bandwidth, it is ok I set RF2 to 35000kbps in upload and 200000 kbps in download. So I can run over 30 cars easily (My internet plan is 940/50 and very stable). It is not our first race, we race every sunday since march, and this issue happen 3 times. This one was the biggest one. We were in a race so no drivers can reconnect as RF2 doesn't let reconnect other than practice, qual and warmup sessions. Watch You can see issues starting at 1:23:40 with car going in grass then back on track magically, then all car disconnect and one start flying. Over 15 drivers were disconnected at the same time.
Cars flying are extrapolated movements i think, so client seems to not have data from server. That looks like a lack of data from server inducing a disconnection to some users "out of sync". 950/50 is in Mbps ? Have you checked it with a speed test ? I have 1Gbps symetrical and only get 800/300 in reality instead of 1000/1000 Mbps.
This has been discussed a lot of times and is hard to analyze; if all players disconnected at the same moment I would say it is a "server" related problem speaking of the physical or virtual machine you are running your dedicated server on. Causes may be packet loss, bandwidth, a takeover of the network line by a fault tolerant network component etc. Maybe the operating system has logged something at the same moment but this is also hard to find (I am not too familiar with Windows, but I am running DS on Windows Server 2022 and it is logging a lot more I think then Windows 10).
Yes my speed test giving me 950/50... and the 50 is always 50 watever time of the day...it is rock solid. I have a speed warranty from my ISP over Coaxial network. Everything is cabled with CAT5E and once I built the server I recabled everything and tested every wires. All past Windows errors I had have been fixed before this issue. I see errors only in rf2 logs at the moment... This message below NetComm.cpp 1572: System Message(2): "Error (The socket is marked as nonblocking and the requested operation would block.) sending to 185.185.126.201:6788" When it occur, I can have 500 repeated lines of this until rf2 server close the sockets and starts kicking out people. I have logged on one of the client of ip reported in the log errors.,.. every time this player connect..it gives this kind of error... I figure out with a couple of twist of creating exception in firewall and router.... by turning off the windows firewall error disapears. I tested on a second client and it does the same... like there's no failsafe on server side and it is caused by the client communication blocking their socket. Ican be wrong but looks like that.
Having a rock solid server or client connection means diddly squat if the connection is losing packets of data along the way, at any of the nodes on its way to/from the server. We had those multiple entries in our server’s trace file too, in our case going back to a Google server, what I did was create an outgoing rule on the server’s firewall blocking connections to that particular Google server. We, thankfully haven’t had any mass disco’s yet (not enough players). I know of one other Australian server that did have mass disco’s with the same errors (outgoing to Google), they also created a rule to block those connections and to date they haven’t had any mass disco’s since. To be fair though they’d only had two mass disco’s about two months apart, so the “rule trick” may just be a placebo.
