Utilization of RMI
Specifying individual IDs per RMI function
RMI functions inside global {} are assigned a sequentially-valued RMI ID.
To get the desired RMI ID value, see the [id=xxx] construction below.
Maintaining the old way of sending and receiving
When introducing ProudNet into a programme that was created using the old way of handling sending and receiving, it is recommended to switch to the RMI method. This prevents programmers from making the mistake of creating incorrect sending and receiving routines and makes future development easier.
However, if you really need the old way of handling sending and receiving that is not RMI, below is an alternative.
- Send and receive custom messages without RMI
Use the following functions to send user-defined messages without using Remote Method Invocation
Sending | Receiving callback |
---|---|
Proud.CNetClient.SendUserMessage | Proud.INetClientEvent.OnReceiveUserMessage |
Proud.CNetClient.SendUserMessage | Proud.INetServerEvent.OnReceiveUserMessage |
Proud.CLanClient.SendUserMessage | Proud.ILanClientEvent.OnReceiveUserMessage |
Proud.CLanServer.SendUserMessage | Proud.ILanServerEvent.OnReceiveUserMessage |
- Send and receive custom messages as parameters in RMI
Access to all RMI call points
In ProudNet, there is a device that can access the call point of the RMI.
Keep a log of all RMIs called
Optimising game server performance by measuring the time each RMI runs
- Access to sender (Proxy) call point
1. First, create a Proxy derived class of the PIDL compiler output. 2. Overrides NotifySendByProxy
This will cause the overridden method to be called on each sending.
By default, NotifySendByProxy() is enabled to be called, If you want to prevent NotifySendByProxy() from being called for better performance, you can set m_enableNotifySendByProxy to false and NotifySendByProxy() will no longer be called.
- Access to receiver (Stub) call point
1. Set the Stub instance's member variable m_enableStubProfiling(enableStubProfiling) to true. 2. Overrides BeforeRmiInvocation and AfterRmiInvocation in the Stub derived class in the PIDL compiler output.
This will cause the overridden method to be called on each receiving.
BeforeRmiInvocation is called just before the arrival of the RMI execution, and AfterRmiInvocation is called at the end of execution. This will help you find RMIs that are causing server performance issues with long processing times.
How to output all parameters of the received RMI function in Stub Set the Stub instance's member variable m_enableNotifyCallFromStub to true and override NotifyCallFromStub. This method receives parameters in the form of strings, so you can log them here. However, it is recommended to use it only when necessary due to poor RMI processing performance.
In C#, you do not need to override anything, just use the defined delegate function.
Variables can likewise be found in the Stub object you define.
Hiding RMI names
In order to display the names of RMI sent and received by the host in BeforeRmiInvocation, etc., the names of all RMIs can be kept in an executable file.
However, if you want to hide it for security reasons, proceed as follows.
Before including ..._proxy.cpp in PIDL's compilation output, define it as follows.
Starting with 1.7.36365 and later versions, for security reasons, the RMI function name does not appear by default in the IRmiStub.BeforeRmiInvocation function.
To make it appear, we need a proxy of the PIDL compilation output, before the cpp source file is compiled, define it as follows.
⬅️ Back
Last updated