I would recommend everyone who is using the RTC SDK to compile as many projects as they can with the RTC_DEBUG compiler directive declared. This can be done for all projects by opening the "rtcDeploy.inc" file in the RTC SDK's "Lib" folder, removing the dot from
{.$DEFINE RTC_DEBUG} and rebuilding each project where you want to have RTC DEBUG logging enabled, without making any changed to the project.
When RTC debug logging is enabled, a "<YourAppName.exe>
.DEBUG.log" file will be created immediately when your application starts, with a few lines listing some RTC SDK units which were initialized. This file is used only to log unit initialization and finalization and should always be there when RTC_DEBUG is enabled, but except for unit initialization and finalization, NOTHING will be written to that file (unless you are writing to that file in your code).
The main purpose of the ".DEBUG.log" file is to make sure there are no problems during RTC application initialization or shutdown. If your application should hang at shutdown, you can look that log file to see where it hangs.
If you do not see that file and the "LOG" folder after you have started your application compiled with the RTC_DEBUG compiler directive, it is very likely that your application does NOT have the permission to write to its folder. This will often be the case for executables installed in the "Program Files" folder, but it should NOT be a problem for the RTC SDK, since a LOG folder will automatically be created in the Windows Temp directory in case it could not be created in the same path where the executable is (or in the path specified in your code).
When RTC_DEBUG logging is enabled and you are using asynchronous WinSock (default), you will also see a "<YourAppFile.exe>
.SOCK.log" file for all socket-related errors. This includes aborted, failed and refused connections, but it also includes any other socket errors reported by WinSock, like problems starting the Server listener because of a port already being in use or because of a port number left empty.
Even though FD_CLOSE and FD_CONNECT log entries about refused, aborted and failed connections are not always alarming, should you start getting a lot of these messages, you might want to consider checking your network setup. A lot of failed, aborted or refused connections could be an indicator that your network is flooded or unreliable (wireless?), but it could also be an attack or a badly behaving client.
In case you do not want to log everything by declaring the RTC_DEBUG compiler directive, Socket error logging can also be enabled by setting the LOG_SOCKET_ERRORS variable from the "rtcSockBase.pas" unit to TRUE. And if you want to disable socket error logging while using RTC_DEBUG, simply set the LOG_SOCKET_ERROR variable to FALSE. You should do this in your project, though. Do not change the default values for RTC variables in the "Lib" folder.
Another log file which might help you debug your application is "<YourAppName.exe>
.INFO.log". If that file is generated, it means that an exception was raised by one of the RTC Value object classes. Every entry in that file will include the exception message, but you should not think that all entries in that log file are errors in your own code. For example, if you have a Server which has to accept requests from third-party clients over XML-RPC, you will also see errors about badly formatted XML-RPC text.
If you are using the "Timeouts" property (available on all TRtcConnection descendants. For example, TRtcHttpServer and TRtcHttpClient), you will also see an entry in the "<YourAppName.exe>
.TIMEOUT.log" file every time a connection is being closed because it was idle longer than your specified maximum timeout value. These are not error messages if you are using timeouts to close idle connections, but could also be an indicator of "dead" connections (sockets which were closed by peer but a packet signaling that was lost and never reached your app).
And now, to the real error logs ...
One log file which should NEVER be generated is the "<YourAppName.exe>
.THREAD.log" file, which is used to log exceptions in the RTC Thread Pool. If a log entry ends up in there, it either means that something is very wrong with the ThreadCallback object attached to the thread pool, or that there are serious problems creating background threads (RTC_MAX_THREAD_POOL_SIZE value too high?). If you see that file generated, all alarms should start off because any exception raised there could be fatal to your application.
If you are using third-party encryption plugins, any exception which might get raised in the encryption plugin code will be captured and logged to the "<YourAppName.exe>
.PLUGIN.log" file. If that file is generated, it either means that the third-party encryption components, the third-party encryption plugin or an event you wrote for the encryption plugin is raising an exception. And none of that should happen. If you get a log entry in the ".PLUGIN.log" file, please make sure the exception isn't raised by your own code and either contact me directly by E-Mail (see address below) of consult your encryption components vendor if you think the error is in their code.
And, the most important log file is definitely "<YourAppName.exe>
.ERROR.log". If you see that file in your LOG folder, it means that something is definitely wrong in your code or in the RTC SDK. If this should happen and you can not locate a bug in your own code, please wrap your LOG files up in a ZIP and send them to me by E-Mail:
PS. Critical exceptions in the WinInet connection provider are currently being written to the "<YourAppName.exe>
.WINET.log" file, while critical exceptions in the WinHTTP connection provider currently end up in the "<YourAppName.exe>
.WINHTTP.log" file, but I am thinking about changing this behavior and moving these exceptions to the "ERROR" log, then use the WINET and WINHTTP files to log connection errors (not exception) like it's the case with the "SOCK" log file.
Best Regards,
Danijel Tkalcec
