WebsiteProud Console
Language

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.

global MedivalWorld 10000
{
    Foo([in] int x);                   // id=10001 is automatically assigned
    [id=13000] id=Foo2([in] int y);    // force assignation as id=13000
}

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

// In ProudNet, the Proud.ByteArray type 
// can be used as a parameter in the RMI as follows.
Foo([in] Proud::ByteArray something);

// --- Up to this point is the PIDL

// This allows you to use past send/receive processing routines. 
// When sending a message, put the buffer object created in the past message sending routine into a Proud.ByteArray object. 
// Then send the Proud.ByteArray object as a parameter to the RMI.

// Creating a message object
Proud::CMessage msg;
 
/* User-created msg objects have not yet been told which buffer to write to.
In these cases, the << operator will only work if you call UseInternalBuffer.
UseInternalBuffer assumes that nothing in the msg object is specified to use the buffer.
Therefore, this method should not be called if buffer usage is already specified.
For more information, see the Proud.CMessage.UseInternalBuffer help. */
msg.UseInternalBuffer();
 
msg << a << b;
 
Proud::ByteArray block;
block.SetCount(msg.GetLength());
memcpy(block.GetData(), msg.GetData(), block.Count);
 
Foo(Proud::HostID_Server, Proud::RmiContext::ReliableSend, block);

// Receive a Proud.ByteArray object as an RMI parameter inside a developer-implemented RMI function when a message is received, 
// extract the data you need.

DEFRMI_MyPIDL_Foo(MyClass)
{
    // Parameter 'block' and the others are is given
    Proud::CMessage msg;
    msg.UseExternalBuffer(block.GetData(), block.Count);
    msg.SetLength(block.Count);
    msg >> a >> b;
    ...
}

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.

#define HIDE_RMI_NAME_STRING

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.

#define USE_RMI_NAME_STRING

Last updated