This section describes the differences between the PiaSession module and the NetZ module from the NEX library.
PiaSession provides features for managing P2P sessions equivalent to those in NetZ in the NEX library, in addition to features for managing matchmaking sessions equivalent to those in the NEX matchmaking module. The PiaSession functions use the same naming conventions as the NetZ module for easier porting, but the internal implementation is completely different and includes various improvements.
In NetZ, you had to manage P2P mesh networks (P2P sessions) separately from matchmaking sessions, which were managed using the NEX matchmaking API. In PiaSession, P2P mesh networks and matchmaking sessions are managed together as sessions. Matchmaking processes are fully automated in PiaSession with internal calls to the NEX matchmaking API. In applications that use the NEX matchmaking API directly, you can also manage P2P mesh networks directly.
All session processing in NetZ occurred as communication between duplicate objects. Processing was multilayered, with complicated processing of duplicate objects when connecting and disconnecting. On the other hand, the PiaSession module uses the protocol features of the Pia library for simpler protocol combinations for all processing. Loose-coupling design and advanced optimizations enable high performance and quality even when many stations are connected.
The NetZ module allocates memory dynamically during communication, making it impossible to know ahead of time how much memory will be used. The module allocates large amounts of memory in certain situations, such as when the wireless signal degrades, which uses up all of the heap memory and keeps games from running. The PiaSession module determines the amount of memory to allocate at initialization. There is never any additional memory allocated during communication. Even if the communication environment becomes poor, communications will be delayed temporarily, and the game can continue.
Creating and joining a session is handled by using the Session singleton object. Joining a session is the same as calling the JoinSession function in NetZ.
In NetZ, leaving and destroying a session is handled automatically when the instance of NetZ is destroyed. In PiaSession, the LeaveSessionAsync() function must be called explicitly to leave a session. Also, the PiaSession module is designed to prevent the time it takes a station to leave the session from getting longer when many stations are connected.
The PiaSession module handles sending by using the appropriate protocol instance. More specifically, using UnreliableProtocol or ReliableProtocol in the PiaTransport transport layer enables you to send data in the same way as calling Send in DirectStream in the NetZ module.
Receiving data with PiaTransport's UnreliableProtocol and ReliableProtocol classes is the same as the approach used in DirectStream in the NetZ module, where you use a function that polls for and gets received data from the application. With DirectStream in NetZ, you can get all of the data sent between the last call to the receive function and the current call to the receive function at one time. To get all of the sent data with UnreliableProtocol and ReliableProtocol in PiaTransport, however, you must repeatedly call the receive function until it no longer returns any more received data.
In NetZ, the library cannot continue processing when the reliable protocol send buffer is full, which causes the game to stop. In PiaSession, reliable protocol sending is separated between the application and the library. When the reliable protocol send buffer of the library is full, the library delays sending to continue processing. When the reliable protocol send buffer for the application is full, the application can choose how to proceed, and can continue with the game by delaying sending.
With DirectStream in NetZ, the duplicate object ID (nex::ConnectionID) was used as the station identifier. In PiaSession, stations are identified using station IDs. Pia station IDs can be converted to a station index. Station indexes can take any value from 0 to (the number of stations connected - 1). Station indexes can also be used to index arrays.
When using the NetZ module, a large amount of data was transmitted when joining or leaving a session to synchronize duplicate objects (such as when migrating). With PiaSession, communication remains stable when stations join and leave a session, reducing the amount of data transmitted.
In NetZ, there were CPU load bottlenecks at times, such as when many stations were connected. PiaSession is designed to minimize CPU load and represents a significant reduction in CPU load in comparison with NetZ. For more information, see the separately provided document Pia Measurement Data.
The PiaSession module uses less memory than NetZ. You can set the sizes of the buffers used in the PiaTransport transport layer to adjust memory down to the minimum required. However, for applications that heavily use reliable communication, memory use is greater than that for NetZ because the send buffer is split. For more information, see the separately provided document Pia Measurement Data.
In PiaSession, the success rate of NAT traversal when endpoint dependent mapping (EDM) connections are included is significantly improved. The wait time when NAT traversal fails is also significantly reduced. In addition, NAT traversal is possible between multiple access points connected in series to the same circuit. For more information, see 11.3. NAT Traversal Reference.
The Pia library contains a module called PiaClone, which provides features that are equivalent to duplicate objects in NetZ. The PiaClone module provides a variety of features for synchronizing game object states during a game (such as game object events and game object access rights). Game object states are required for games that share data between stations.
The Pia library contains a module called PiaReckoning, which provides features that are equivalent to the dead reckoning features in NetZ. The PiaReckoning module contains a pre-built reckoning strategy for estimating 3D positional information for game objects. You can customize this algorithm as necessary to make it more suitable for your application.
Linking with server services other than matchmaking is exactly the same as in NetZ. You do not need to change any calls to NEX login, ranking, or data store functions when porting to PiaSession.
By using the NexVirtualNetwork class of the Pia library, you can now implement local communication with the NetZ module using the same code as for Internet communication. As in the PiaSession module, the LocalNetworkFactory and NexNetworkFactory classes provide a shared interface. This design allows you to quickly develop Internet-communication functionality after developing local-communication functionality.