How to use
Last updated
Last updated
As a way to obtain interhost latency (ping time or lag) from ProudNet, the ping time obtained is the roundtrip latency, which is the time taken to send a message from one host to the other and then respond immediately to it from the other host.
C++ function | C# function | Description |
---|---|---|
C++ function | C# function |
---|---|
Starting with version 1.7.40679-master, we added a new function to get the latency from the client to the server. Previous functions like GetLast~ or GetRecent~ had a problem with ping pong being delayed when the network condition was not smooth.
If you have access to 1.7.40679 or later, we recommend using the function to get the latency with the newly added server.
Reliable message delivery is a two-way communication method, which means that sending and receiving times are slower than Unreliable, but the order of sending and receiving and the certainty of arrival are guaranteed.
Unreliable message delivery is a one-way communication method that has a faster send and receive time than Reliable, but the order in which messages are sent and received can be out of order and arrival is not guaranteed.
Sometimes you want two programs to communicate with ProudNet, but in different programming languages. In these cases, the PIDL compiler will generate proxies and stubs in two or more languages, and each program can then grab and write what it needs.
Basic types like int, double, and string are already provided by ProudNet's wrapping modules for languages other than C++. However, in different languages, these primitive types are named differently by default. For example, in C#, the string class is System.String, whereas in C++ it is std::string, std::wstring, ATL::CString, Proud::String.
To address this, the PIDL compiler provides the ability to change the type of variables in the generated proxy and stub to be language specific if desired.
Below is an example of usage.
The Proud.HostID is included for identification when receiving RMI or event callbacks. When developing a game server, if you get a Proud.HostID, you can retrieve an object for that Host based on that value and then work with it, which is how the ProudNet sample program is built.
A Host Tag is identifying data, other than the Host ID, that you can define for the local host and other hosts.
You can use them to make your program perform better.
Example when Host Tag is not used
The Host Tag is specified by the following methods.
CLanClient and CLanServer are not supported starting in version 1.7.
NetClient and NetServer take over the roles of CLanClient and CLanServer.
The Host Tag is received via Proud.RmiContext.m_hostTag and Proud.CNetPeerInfo.m_hostTag and is not synchronized over the network, so it is not propagated to the other party.
The network client module CNetClient and the server module CNetServer in ProudNet use two types of Thread Pool.
Networker thread pool: Used exclusively for internal processing of the ProudNet, handling socket I/O, etc.
User worker thread pool: For running user-defined routines. Handle RMI or callback events, etc.
For best performance, create thread pools explicitly and set them up in the Network module if you want certain thread pools to be shared instead of each module owning them.
Currently, you need to include ProudNetServer.h to use this feature on the client end, but starting with 1.7.36365, you do not need to include ProudNetServer.h to use it.
A user-created thread pool object will throw an exception if it is destroyed before all network modules are destroyed.
Below is the pseudo code involved in the overall flow.
Setting up a thread pool is basically the same as above, with different values depending on your case. You can set up several thread models not only on servers but also on clients.
As a way to run a pure single-threaded server as many as the number of CPUs, you must create a thread pool object with no threads at all and manually continuously call a function that makes the thread pool breathe.
When specifying a Networker thread pool, do not call things like Process or FrameMove too slowly. The methods that are called should complete the necessary processing as quickly as possible.
Otherwise, you might get weird ping measurements internally, disconnections between server and client, etc.
Above, we separated the user worker and networker to prevent mistakes from happening, but we still need to explicitly call FrameMove. This gives you the advantage of being able to run stacked RMI at any point in time.
Setting up a Thread Model is a way to ensure that you do not have to worry about complicated code on the client side, such as calling Process or FrameMove, causing logic to break or accidentally missing code. ProudNet provides a lot of manipulation over networking, but you can also set it up so that you do not care about it.
ThreadModel_SingleThreaded: RMI and message callbacks complete when the user invokes FrameMove. (Default value)
ThreadModel_MultiThreaded: The callback completes immediately, even if the user does not invoke FrameMove.
ThreadModel_UseExternalThreadPool: When specifying a thread pool, you must set it to this.
You can set the above values in the m_netWorkerThreadModel and m_userWorkerThreadModel of the CNetConnectionParam. The default value is ThreadModel_SingleThreaded.
You can run your function or Lambda expression A asynchronously with Proud.IRmiHost.RunAsync(). Proud.IRmiHost.RunAsync() returns immediately, and A runs on one of the threads in the thread pool.
If you want A to run for host H with a given HostID, you guarantee that H's callback function and A will not run at the same time.
ProudNet's servers and network have the ability to detect and warn when the amount of sending is too much for the line speed. Proud.INetCoreEvent.OnWarning with ErrorType_SendQueueIsHeavy is called.
If you are sending too much, we recommend refining unnecessary messaging or Throttling.
C++ function | C# function |
---|---|
Proud.CNetServer.GetLastPingSec
Nettention.Proud.NetServer.GetLastReliablePingSec
Get the last wait time in seconds for that client.
Proud.CNetServer.GetLastUnreliablePingMs
Nettention.Proud.NetServer.GetLastUnreliablePingMs
Get the last latency for that client in Ms.
Proud.CNetServer.GetRecentPingSec
Nettention.Proud.NetServer.GetRecentReliablePingSec
Get the last wait time in seconds for that client.
Proud.CNetServer.GetRecentUnreliablePingMs
Nettention.Proud.NetServer.GetRecentUnreliablePingMs
Get the last latency for that client in Ms.
Proud.CNetClient.GetLastUnreliablePingSec
Nettention.Proud.NetClient.GetLastUnreliablePingSec
Proud.CNetClient.GetLastUnreliablePingMs
Nettention.Proud.NetClient.GetLastUnreliablePingMs
Proud.CNetClient.GetLastReliablePingSec
Nettention.Proud.NetClient.GetLastReliablePingSec
Proud.CNetClient.GetLastReliablePingMs
Nettention.Proud.NetClient.GetLastReliablePinMs
Proud.CNetClient.GetRecentUnreliablePingSec
-
Proud.CNetClient.GetRecentUnreliablePingMs
Nettention.Proud.NetClient.GetRecentUnreliablePingMs
Proud.CNetClient.GetRecentReliablePingSec
Nettention.Proud.NetClient.GetRecentReliablePingSec
Proud.CNetClient.GetRecentReliablePingMs
Nettention.Proud.NetClient.GetRecentReliablePingMs
Proud.CLanClient.SetHostTag
-
Proud.CLanServer.SetHostTag
-
Proud.CNetClient.SetHostTag
Nettention.Proud.NetClient.SetHostTag
Proud.CNetServer.SetHostTag
Nettention.Proud.NetServer.SetHostTag