Beaconizer-protocols: Difference between revisions

From OuroDev
Asuffield (talk | contribs)
Asuffield (talk | contribs)
Line 98: Line 98:


==== BMSG_C2ST_MAP_DATA_IS_LOADED "MapDataIsLoaded" ====
==== BMSG_C2ST_MAP_DATA_IS_LOADED "MapDataIsLoaded" ====
If the client type is BCT_SERVER and the client is a request server:
packint(1) node_uid
string unique_storage_name
If the uid and storage name match the work that is currently assigned to this server, and all map data has been sent to it, then BMSG_S2CT_PROCESS_REQUESTED_MAP is sent to the client. Otherwise this message is ignored.
If the client type is BCT_WORKER, then the state must be BCS_RECEIVING_MAP_DATA or this message is ignored. When it is in state BCS_RECEIVING_MAP_DATA:
If the map data has not been fully sent, then the state is moved to BCS_ERROR_PROTOCOL and the response is sent with ''good'' set to 1 (bug???).
Otherwise:
bits(32) client_map_crc
If the map crc matches the one loaded by this server, then the state is moved to BCS_READY_TO_GENERATE and the response will have ''good'' set to 1. Otherwise, the state is moved to BCS_ERROR_DATA and the response will have ''good'' set to 0.
In any case where the state was BCS_RECEIVING_MAP_DATA, a BMSG_S2CT_MAP_DATA_LOADED_REPLY reply will be sent.
==== BMSG_C2ST_NEED_MORE_EXE_DATA "NeedMoreExeData" ====
==== BMSG_C2ST_NEED_MORE_EXE_DATA "NeedMoreExeData" ====
==== BMSG_C2ST_GENERATE_FINISHED "GenerateFinished" ====
==== BMSG_C2ST_GENERATE_FINISHED "GenerateFinished" ====

Revision as of 18:26, 9 June 2019

Beaconizers connect to the master server on port 48813 and to other BeaconServer instances on ports ranging from 48812 to 48913. They use the common Network protocol.

Commands, client to server

All BeaconServer modes accept the same messages from clients. Clients have a state, stored in BeaconServerClientData.state, which is BCS_NOT_CONNECTED for newly connected clients. The possible states are:

  • BCS_NOT_CONNECTED: the client has not yet send a connect message
  • BCS_CONNECTED: the client has connected with BMSG_C2S_CONNECT, and is not a sentry
  • BCS_READY_TO_WORK
  • BCS_RECEIVING_MAP_DATA
  • BCS_NEEDS_MORE_MAP_DATA
  • BCS_READY_TO_GENERATE
  • BCS_GENERATING
  • BCS_READY_TO_CONNECT_BEACONS
  • BCS_CONNECTING_BEACONS
  • BCS_SENTRY: the client has connected with BMSG_C2S_CONNECT, and is a sentry
  • BCS_SERVER: the client has connected with BMSG_C2S_SERVER_CONNECT
  • BCS_NEEDS_MORE_EXE_DATA: the client is waiting to be sent the next chunk of a new executable
  • BCS_RECEIVING_EXE_DATA: the client has been sent a chunk of a new executable, and is waiting for it to ask for more
  • BCS_REQUESTER: the client has connected with BMSG_C2S_REQUESTER_CONNECT
  • BCS_REQUEST_SERVER_IDLE
  • BCS_REQUEST_SERVER_PROCESSING
  • BCS_ERROR_DATA: some invalid data has been received, and all future messages will be ignored
  • BCS_ERROR_PROTOCOL: some invalid protocol message has been received, and all future messages will be ignored
  • BCS_ERROR_NONLOCAL_IP: the server has been set into "local IPs only" mode (via the console menu) and the client is not connecting from a local IP


BMSG_C2S_CONNECT

bits(32) exe_crc_old
optional, if exe_crc_old is 0:
  packint(1) protocol_version
  bits(32) exe_crc
string user_name
string computer_name
bits(1) is_sentry

If the client is in state BCS_ERROR_NONLOCAL_IP then this message is ignored, other than recording the names and version. If the client is in any other state which is not BCS_NOT_CONNECTED then the state is set to BCS_ERROR_PROTOCOL and this message is ignored. Otherwise, when the state is BCS_NOT_CONNECTED:

If exe_crc_old is not 0, then it is the exe_crc value. Otherwise, the optional version is used.

If exe_crc does not match the crc of the executable for the server receiving the message, then the client will be moved to state BCS_ERROR_PROTOCOL in production mode, and sent a BMSG_S2C_CONNECT_REPLY with good set to 0 in development mode, and the client is moved to state BCS_NEEDS_MORE_EXE_DATA.

If exe_crc does match, then the client will be accepted. If is_sentry is true then the client type will be set to BCT_SENTRY and the state to BCS_SENTRY. If is_sentry is false then the client type will be set to BCT_WORKER and the client state to BCS_CONNECTED.

BMSG_S2C_CONNECT_REPLY is sent with good set to 1.

BMSG_C2S_SERVER_CONNECT

packint(1) protocol_version
bits(32) exe_crc
string user_name
string computer_name
packint(1) server_port
when protocol_version is at least 1:
  bits(1) is_request_server

If the client is in state BCS_ERROR_NONLOCAL_IP then this message is ignored, other than recording the names and version. If the client is in any other state which is not BCS_NOT_CONNECTED then the state is set to BCS_ERROR_PROTOCOL and this message is ignored. Otherwise, when the state is BCS_NOT_CONNECTED:

The crc match is checked against this binary and printed on the console but otherwise ignored.

The other fields are recorded for later use.

The client state is moved to BCS_SERVER and BMSG_S2C_CONNECT_REPLY is sent with good set to 1.

BMSG_C2S_REQUESTER_CONNECT

packint(1) protocol_version
string user_name
string computer_name
string dbserver_ip

If the client is in state BCS_ERROR_NONLOCAL_IP then this message is ignored, other than recording the names and version. If the client is in any other state which is not BCS_NOT_CONNECTED then the state is set to BCS_ERROR_PROTOCOL and this message is ignored. Otherwise, when the state is BCS_NOT_CONNECTED:

If protocol_version is not 0, 1, or 2 then the client is moved to state BCS_ERROR_PROTOCOL, otherwise it is moved to state BCS_REQUESTER.

The rest of the fields are stored for later use.

BMSG_C2S_TEXT_CMD

string cmd

The rest of this packet is determined based on the text command sent. If it is not one of these values, the command is ignored.

In each case, it is listed with both the constant used in the source code (BMSG_C2ST_*) and the name sent in the message ("...").

BMSG_C2ST_READY_TO_WORK "ReadyToWork"

This message has no body.

If the client is in state BCS_CONNECTED, then it moves to state BCS_READY_TO_WORK, and marked as ready for commands.

If the client is in state BCS_SENTRY, the message is printed on the console and ignored.

Receiving this message in all other states will move to BCS_ERROR_PROTOCOL.

BMSG_C2ST_NEED_MORE_MAP_DATA "NeedMoreMapData"

packint(1) received_byte_count

If the client type is BCT_SERVER, then the server responds with BMSG_S2CT_MAP_DATA.

If the client type is BCT_WORKER, and the state is BCS_RECEIVING_MAP_DATA, then received_byte_count is checked against the sent byte count, and the state is moved to BCS_ERROR_PROTOCOL if it does not match. If it does match, then the state moves to BCS_NEEDS_MORE_MAP_DATA.

BMSG_C2ST_MAP_DATA_IS_LOADED "MapDataIsLoaded"

If the client type is BCT_SERVER and the client is a request server:

packint(1) node_uid
string unique_storage_name

If the uid and storage name match the work that is currently assigned to this server, and all map data has been sent to it, then BMSG_S2CT_PROCESS_REQUESTED_MAP is sent to the client. Otherwise this message is ignored.

If the client type is BCT_WORKER, then the state must be BCS_RECEIVING_MAP_DATA or this message is ignored. When it is in state BCS_RECEIVING_MAP_DATA:

If the map data has not been fully sent, then the state is moved to BCS_ERROR_PROTOCOL and the response is sent with good set to 1 (bug???).

Otherwise:

bits(32) client_map_crc

If the map crc matches the one loaded by this server, then the state is moved to BCS_READY_TO_GENERATE and the response will have good set to 1. Otherwise, the state is moved to BCS_ERROR_DATA and the response will have good set to 0.

In any case where the state was BCS_RECEIVING_MAP_DATA, a BMSG_S2CT_MAP_DATA_LOADED_REPLY reply will be sent.

BMSG_C2ST_NEED_MORE_EXE_DATA "NeedMoreExeData"

BMSG_C2ST_GENERATE_FINISHED "GenerateFinished"

BMSG_C2ST_BEACON_CONNECTIONS "BeaconConnections"

BMSG_C2ST_SENTRY_CLIENT_LIST "SentryClientList"

BMSG_C2ST_SERVER_STATUS "ServerStatus"

BMSG_C2ST_REQUESTER_MAP_DATA "RequesterMapData"

BMSG_C2ST_REQUESTER_CANCEL "RequesterCancel"

BMSG_C2ST_USER_INACTIVE "UserInactive"

BMSG_C2ST_BEACON_FILE "BeaconFile"

BMSG_C2ST_NEED_MORE_BEACON_FILE "NeedMoreBeaconFile"

BMSG_C2ST_REQUESTED_MAP_LOAD_FAILED "RequestedMapLoadFailed"

BMSG_C2ST_PING "Ping"

Commands, server to client

BMSG_S2C_CONNECT_REPLY

bits(1) good
when good is 1:
  bits(32) client_uid
  string server_uid
optional, when good is 0:
  packint(1) size
  bits(size * 8) data

When good is 1, the connection is being accepted. Otherwise, this indicates that the client should get a new executable, and optionally contains the data.

BMSG_S2C_TEXT_CMD

string cmd

The rest of this packet is determined based on the text command sent. If it is not one of these values, the command is ignored.

In each case, it is listed with both the constant used in the source code (BMSG_S2CT_*) and the name sent in the message ("...").

BMSG_S2CT_KILL_PROCESSES "KillProcesses"

BMSG_S2CT_MAP_DATA "MapData"

BMSG_S2CT_MAP_DATA_LOADED_REPLY "MapDataLoadedReply"

BMSG_S2CT_EXE_DATA "ExeData"

BMSG_S2CT_NEED_MORE_BEACON_FILE "NeedMoreBeaconFile"

BMSG_S2CT_PROCESS_LEGAL_AREAS "ProcessLegalAreas"

BMSG_S2CT_BEACON_LIST "BeaconList"

BMSG_S2CT_CONNECT_BEACONS "ConnectBeacons"

BMSG_S2CT_TRANSFER_TO_SERVER "TransferToServer"

BMSG_S2CT_CLIENT_CAP "ClientCap"

BMSG_S2CT_STATUS_ACK "StatusAck"

BMSG_S2CT_REQUEST_CHUNK_RECEIVED "RequestChunkReceived"

BMSG_S2CT_REQUEST_ACCEPTED "RequestAccepted"

BMSG_S2CT_PROCESS_REQUESTED_MAP "ProcessRequestedMap"

BMSG_S2CT_EXECUTE_COMMAND "ExecuteCommand"

BMSG_S2CT_BEACON_FILE "BeaconFile"

BMSG_S2CT_REGENERATE_MAP_DATA "RegenerateMapData"

BMSG_S2CT_PING "Ping"