The sending party may finish setting up encryption and start
sending encrypted packets while the receiving party is still configuring
encryption and expecting unencrypted packets
PiperOrigin-RevId: 549267838
During the destruction of NearbyConnections, Core (which owns ClientProxy) is destructed before ServiceController (which owns EndpointManager), which means any pending tasks on the EndpointManager executor that use ClientProxy will be using
garbage memory. To fix this issue, EndpointManager::DiscardEndpoint will check
for an `is_shutdown` boolean set during ~EndpointManager before accessing
ClientProxy. The assumption is that any accessing of ClientProxy after the
destruction will be invalid.
PiperOrigin-RevId: 532581122
This extends the endpoint disconnection timeout to be slightly longer than the WebRTC connection attempt timeout. This allows an in-progress bandwidth upgrade to resolve before we clean up the endpoint.
Failing to properly clean up the bandwidth upgrade can lead to a delay when shutting down Nearby Connections and can crash the process instead of allowing a clean shutdown.
PiperOrigin-RevId: 496750001
This CL should be a no-op.
Provide better access to the service ID during bandwidth upgrade handling. Notably, 1) have the endpoint channel store its associated service ID, and 2) send the service ID on a connect/disconnect.
The service ID identifies the application, for example, "NearbySharing". In future CLs, we will use the service IDs to better handle bandwidth-upgrade bookkeeping when multiple services are running simultaneously. Specifically, we will better handle reverting a bandwidth-upgrade medium without interfering with other services.
PiperOrigin-RevId: 442019209
Francis Tsui