M_fifo_index= (m_fifo_index + 1) % intsize(m_response_handlers.get_element_count()).to_int16_verify() M_response_handlers.get_element(m_fifo_index) H_weak_investment_reference callback_reference,Ĭ_investment_server_message_response_handler *server_message_response_handler= T_investment_server_message_table_index server_message_index, H_weak_investment_reference c_investment_server_message_manager::new_response_handler( _investment_bap_message_policy_service_to_world_server_request, _investment_bap_connection_activity_host_0_outbound_to_activity_host_proxy, Investment_bap_connection_enqueue_message_with_callback( Weak_investment_bap_message_queue_callback, H_weak_investment_bap_message_queue_callback server_message_manager_callback=Ĭ_investment_server_message_manager::get()->new_response_handler( H_weak_investment_bap_message_queue_callback weak_investment_bap_message_queue_callback,Ĭonst c_string_hash *optional_additional_context) Void c_investment_server_message_interface::activity_host_send_server_message_internal(Ĭ_investment_server_message_network_id network_id,Ĭonst s_server_request_arguments *request_arguments, Callback handlers were being reserved from a circular FIFO queue for every outgoing message even if that message didn’t require a response! To make matters worse, we never checked to see if the queue of callback handlers was full!! static_class_function_definition H_weak_investment_reference::from(k_invalid_investment_reference_handle), // invalid handle = no response expectedĭiving deeper into activity_host_send_server_message_internal(), the root cause finally manifested. _investment_server_message_network_identifier_incident_activity_host_incident, This is demonstrated by the call to the send-incident function as shown below: activity_host_send_server_message_internal( This is a one-way communication that doesn't require a response and thus shouldn’t need a callback handler. For example, when you get a kill, the AH sends that incident to the WS so the WS can update your bounty progression. The bulk of our messaging between the AH and WS is incident data, which is one-direction and doesn’t require a response. While the discrepancy between those two numbers throws up some red flags, we don’t need a matching number of callback handlers. ![]() Based on these constants, BAP can queue up to 2048 messages, but it is limited to 16 responses. K_server_message_default_callback_handler_count= 16 īAP reserves callback handlers for BAP messages that expect a response. k_investment_bap_message_queue_element_count= 2048 Back in the code, I noticed these two constants. Players were frequently loading into activities without completing the full peer validation process! Now I just needed to figure out why we were dropping the query. I checked logs from a random retail AH, and sure enough I found signs that peer validation was waiting indefinitely after sending the query to the WS. Perhaps peer validator was blocking indefinitely while waiting for a response from the WS? Suspiciously, I couldn't find a timeout mechanism in peer validator. In other words, a player is free to join any activity, but is kicked out whenever the AH receives a negative response from the WS. I learned that peer validation happens asynchronously and in parallel with the normal flow of joining an activity. I couldn't reproduce the bug with my onebox, so I began to look through code to see if I could spot the bug, starting with the peer validator. How could the player get into the activity without the flag getting set? Clearly the player loaded into the correct activity. While this was an interesting theory, was it plausible? At the time, I had no idea how this could happen. But if a player could get into an IB match without the IB intrinsic flag set on their account, none of their kills would count towards their IB bounties because those bounties require the IB flag. In those cases, the game is only looking for if/how you killed an enemy, not where you killed an enemy. ![]() Some rewards are not tied to activity intrinsic flags, such as world drops or Gunsmith bounties. Our rewards system uses those flags to determine the eligible rewards. When a player starts a new activity, the activity intrinsic flags are marked on the player's account. Within those higher-level categories, there are more specific flags, like Nightfall or Iron Banner. For example, there are flags for strikes, pvp, and raids. This was a compelling theory because it could also explain the IB bug.Įach activity in Destiny is associated with various activity intrinsic flags. It was almost like the game didn't know the type of activity (raid). Interestingly, affected players continued to earn world drops (engrams from enemy kills) even though the raid chests didn't spawn loot.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |