Starting with ACR 1.87, ALFA servers have the ability to perform direct, peer-to-peer communication between eachother, bypassing the database.
Presently, this communication is only used for unreliable, datagram-oriented messages (which can be lost or reordered along the way), so it is only used for non-critical activities like advising a server that it should immediately retrieve an IPC message from the central database. Datagram protocol messages are also unauthenticated, so drastic action shouldn't be taken on receiving them.
The protocol operates as multiplexed over the same data port as game data traffic, and thus requires no additional firewall configuration.
Each protocol message starts out with a standard header. All fields are in little endian. Code to operate on parsing and building network protocol messages lives in CLRScript\ALFANetworkMessages.cs, whereas code for sending and receiving actual messages with payloads lives in alfa2_acr.hak\ACR_ServerCommunicator\ServerNetworkManager.cs.
UInt32: Magic number. This is used to distinguish ALFA protocol messages from standard game network traffic. The magic number always has the value 0x414C4641 (the ASCII string "ALFA").
UInt8: Protocol type. There only ALFA protocol type currently defined is PROTOCOL_DATAGRAM, with the value 0x00. The datagram protocol provides unreliable message delivery (messages can be discarded or reordered along the way, so it can't be used for data that must arrive in one piece). A future connection-oriented protocol that provided reliable semantics might have a different protocol id to allow the messages to be distinguished.
UInt16: Command. This represents one of the protocol-specific command codes.
UInt32: Message length (includes the header described here). This represents the length of the entire message.
The datagram protocol defines several message command codes, which are listed below.
This message is sent to a server in order to cause it to immediately query the database for IPC messages. The purpose of the message is to work around the lack of a LISTEN / NOTIFY mechanism in MySQL for reliable IPC messages. The actual IPC message(s) to process are stored in the server_ipc_messages table, whereas the IPC wake datagram simply causes the target server to check the table immediately. This reduces the latency required for a server to respond to a message (servers normally periodically poll, so the IPC wake message eliminates the added latency from the polling interval if it was successfully delivered).
(Int32) Source server id. The database id of the server that sent the message; the message should be discarded if the sending address doesn't match that server id in the servers table.
(Int32) Destination server id. This should match the database id of the local server, otherwise the message should be discarded.
This message is sent from a server, to all online servers, when a server begins a clean shutdown (as started by the Restart Server tool). The purpose of the message is to allow any future, connection-oriented protocol targetted at the server to be shut down. Currently, no action is taken when the message is received.
(Int32) Source server id. The database id of the server that sent the message; the message should be discarded if the sending address doesn't match that server id in the servers table.
This message is sent to inform one server of what the other server's view of the central database's health is. In the future, it might be used to form a quorum that might try to diagnose whether a failure in connectivity to the central database is likely to be the result of a server-local failure, or a failure actually on the central database.
The #showstate debug command can be used to dump the database online status of each known server. This can be used to try and manually diagnose whether a database connectivity failure is local or global.
Servers rebroadcast this message every 10 minutes. In addition, if a server's connectivity state to the central database changes state, the message is immediately broadcast at that time.
(Int32) Source server id. The database id of the server that sent the message; the message should be discarded if the sending address doesn't match that server id in the servers table.
(UInt8) Database online disposition. This value is 1 if the sending server has a good connection to the database, else 0 if the sending server cannot connect to the database.
Powered by Drupal & phpBB3