What to do in case of an error

Troubleshooting server disconnections when paused by the debugger

While you are using a debugger to debug a server or client, the program you are debugging is often paused due to breakpoint settings, etc.

However, with ProudNet, after tens of seconds of this pause, the connection between the server and the client is lost. If the connection between hosts is abnormally disconnected, it is generally detected immediately, but if a hard disconnect is performed, such as by forcibly disconnecting the power or communication line of the host, it is not immediately detected.

And hard disconnect is detected through ping-pong packets exchanged between hosts at regular intervals. Even if the program being debugged is paused for tens of seconds, ProudNet recognizes it as a hard disconnect and disconnects the host.

To solve this, use Proud.CNetServer.SetDefaultTimeoutTimeSec to set the time to detect a hard disconnect sufficiently long (for example, one hour).

Setting Proud.CNetServer.SetDefaultTimeoutTimeSec to a long time is only recommended when debugging.

If you set SetDefaultTimeoutTimeSec to be long for versions that are distributed to gamers, it may take too long to detect disconnections from gamers who disconnect hard.

Please be aware that some gamers may abuse hard disconnect, so please be careful.

// Example

Proud::CNetServer* srv = ...;
#ifdef _DEBUG
srv->SetDefaultTimeoutTimeSec(60*10); // 10 minutes
#endif

When a build error occurs

Please try #include <atlbase.h> before include <ProudNetServer.h> or include <ProudNetClietn.h>. When using stdafx.h, it is recommended to put include <atlbase.h> at the beginning of stdafx.h.

Programs using the .Net Framework have the symbol System.String, but ProudNet has the symbol Proud.String. Therefore, when mixing .Net Framework, the symbol String may need to specify the namespace of either System or Proud.

When P2P communication suddenly stops and communication resumes a few seconds later

ProudNet takes a few seconds to detect when a P2P connection is blocked in the middle of a P2P communication.

If it determines that the P2P connection is stuck in the middle, it will put the P2P connection into bypass mode. Reliable messages are sent and received all at once, and Unreliable messages are lost.

Blocking the Assert dialog box

ProudNet may display an assert failure dialog when there is an incorrect usage during internal operations in the debug build. If you want to prevent this, you should set something else to work instead of displaying the dialog when assert failure occurs.

You can also replace them with your own functions. An example is shown below.

#include "stdafx.h"
#include <crtdbg.h>
 
int YourReportHook( int reportType, char *message, int *returnValue )
{
    return 1;
}
 
int _tmain(int argc, _TCHAR* argv[])
{
    _CrtSetReportHook(YourReportHook);
    assert(0); // now, this won't show you the message box.
    return 0;
}

The Server, Client, as well as many internal objects in ProudNet use Fast Heap, which leaves the instance as a C++ singleton. If an instance of a Server, Client, etc. that uses Fast Heap is placed as a global variable or a member variable of a global variable, an exception will occur.

Instances created with C++ singleton should be set to C++ singleton rather than global variables because they ensure that WinMain() or main() is destroyed in line with the dependent object relationship before it returns.

When the maximum number of concurrent users does not exceed 5,000

If you are not getting the maximum 5,000 concurrent users, you can check the following.

If the ProudNetClientPlugin.dll module is not found

If the redistribution package is not installed, an error may occur even if the library exists in the path.

You can install the redistributions and CMake in the last step of the initial ProudNet installation, and after installation, the redistributions are also included in the Bin folder under the ProudNet installation path, so you can install them from there.

Last updated