Class name of PIDL compiled result

Class name of proxy and stub generated through PIDL file are the classes named as Proxy and Stub of namespace designated from PIDL. For instance, if you refer to PIDL file below

global TestC2S { ... };

Proxy and stub that get generated by this code become TestC2S. Proxy and TestC2S.Stub.

PIDL file name of compiled result

First, the generated source file must be included in PIDL file. For example, if you’ve compiled TestC2S.PIDL, the name of generated Proxy module becomes TestC2S_Proxy.h. And the name of Stub module becomes TestC2S_Stub.cpp, TestC2S_Stub.h.

It is not suggested to directly attach Proxy or Stub to a project under development. Even through the compiled result of PIDL file is only a text file made of C++ language, it is still a compiled result. If you are using any source control and your compiled result is for read only then it may cause a trouble.

Thus it is better to include them by using #include.

Attaching Proxy to client and server

First, you need to generate Proxy instance of PIDL compiled result. And then, you need to register the instance to Proud.CNetClient or Proud.CNetServer.

Client and server inherit Proud.IRmiHost and Proxy can be registered through the included method, Proud.IRmiHost.AttachProxy.

Each client and server can be attached with more than two of Proxy as long as the range of message ID doesn't overwrap with each other. Let's assume there is TestA.Proxy already attached in CNetClient and you want to additionally attach TestB.Proxy. And you declared the first message ID of TestA as 2100 and TestB as 2200. If the number of RMI functions declared by TestA is 200, then the range of TestA message ID becomes 2100~2300, which overwraps with the ID of TestB. When this happens, an exception will be thrown.

Attaching Stub to client and server

If you are using C++11, check out another way described below.

How to implement Stub in C++11

The stub instance of PIDL compiled result contains RMI functions that will be run by messages sent through network as virtual function. You need to inherit this Stub class and override RMI functions.

For your convenience, PIDL compiler generated macros as followed. These macros are wrapped with RMI function name and parameter.

#define DECRMI_S2C_ShowChat bool ShowChat(Proud::HostID remote,Proud::RmiContext &rmiContext,const CString &a,const int &b,const float &c)

#define DEFRMI_S2C_ShowChat(DerivedClass) bool DerivedClass::ShowChat(Proud::HostID remote,Proud::RmiContext &rmiContext,const CString &a,const int &b,const float &c)

The procedure of using these macros is followed.

In declaration of class of inherited Stub class, add [DECRMI_NameSpace_Method].
In method definition of inherited Stub class, use [DEFRMI_NameSpace_Method].

Here shows how you can use them.

// PIDL file contents
global LobbyC2S 5000
{
    Foo([in] int a,[in] float b);
}
// Class that inherits Stub of LobbyC2S and operates RMI
class LobbyC2SStub:public LobbyC2S::Stub
{
    DECRMI_LobbyC2S_Foo;
};
// Creation of RMI Foo routine
DEFRMI_LobbyC2S_Foo(LobbyC2SStub)
{
    // Parameter that gets passed to here is the same parameter of LobbyC2S.Foo of PIDL.
    a++;
    b++;
    return true;
}

More detailed example on this is guided in RMI stub 구현하기 of ProudNet 튜토리얼.

Client and server inherit Proud.IRmiHost. Stub can be registered through the included method, Proud.IRmiHost.AttachStub.

Just like Proxy, you can attach more than two of Stub as long as their message ID doesn't overwrap with each other.

The operation method of attached Proxy and Stub

Proxy and stub attached to eigher Proud.CNetServer or Proud.CNetClient get registered to proxy list and stub list inside of Proud.CNetServer or Proud.CNetClient.

Proxy has a pointer of Proud.CNetServer or Proud.CNetClient that calls for sending method of Proud.CNetServer or Proud.CNetClient.

On the other hand, when Proud.CNetServer or Proud.CNetClient receives the message then it tosses it onto stub list. Each stub analyzes the header of received message and calls for appropriate RMI. (If there is no associated RMI, then it ignores it and passes an opportunity of analyzing to a next stub.)

When Proud.CNetServer or Proud.CNetClient is destructed, the link of proxy list and stub list contained inside get disconnected as well. When this happens, all stub linked to Proud.CNetServer or Proud.CNetClient in the past no longer calls for RMI and since every proxy also stops referring to Proud.CNetServer or Proud.CNetClient, RMI doesn't operate at all.