Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Platform Networking #3412

Merged
merged 35 commits into from Aug 16, 2023
Merged

Platform Networking #3412

merged 35 commits into from Aug 16, 2023

Conversation

fealebenpae
Copy link
Member

@fealebenpae fealebenpae commented Aug 4, 2023

Description

Add option to use ClientWebSocket instead of the built-in WebSocket client for Sync.

Fixes #2911

TODO

  • Changelog entry
  • Tests (if applicable)

@fealebenpae fealebenpae self-assigned this Aug 4, 2023
@cla-bot cla-bot bot added the cla: yes label Aug 4, 2023
@fealebenpae fealebenpae changed the title Yg/websocket Platform Networking Aug 4, 2023
Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only went through the managed implementation - looks good for the most part, though we need to finish the error handling logic. Once this is done and proven to work on all platforms, we should update the Unity packaging scripts to add the new dependencies.

Realm/Realm/Native/SyncSocketProvider.EventLoop.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.EventLoop.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.EventLoop.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.WebSocket.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.WebSocket.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.cs Outdated Show resolved Hide resolved
Realm/Realm/Native/SyncSocketProvider.WebSocket.cs Outdated Show resolved Hide resolved
catch (Exception e)
{
Logger.LogDefault(LogLevel.Error, $"Error occurred in SyncSocketProvider event loop {e.GetType().FullName}: {e.Message}");
Logger.LogDefault(LogLevel.Trace, e.StackTrace);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we notify sync that we're terminating the work thread?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There isn't an interface we can use to notify Sync about that. But now that you mention it the existing behavior on an exception on the sync worker thread is to bring down the process, so instead of swallowing and logging the exception that's what we should do here.

Realm/Realm/Native/SyncSocketProvider.cs Outdated Show resolved Hide resolved
Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few more comments. I added a branch with suggestions here: #3421. Feel free to pick and choose those that make sense to you.

I also suggest that we use file-scoped namespaces for the new files - I didn't do it in my suggestions branch because then it would reorder too much stuff making it difficult to review the actual suggestions.

await _webSocket.ConnectAsync(_uri, _cts.Token);
await _workQueue.WriteAsync(new WebSocketConnectedWork(_webSocket.SubProtocol, _observer, _cts.Token));
}
catch (WebSocketException e)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we send a websocket closed work in case of a non-websocket error - e.g. I can imagine we can hit an out of memory or similar system exception that would prevent us from connecting but Sync will be waiting forever for the connection.

Comment on lines 184 to 188
if (Environment.GetEnvironmentVariable("REALM_DOTNET_USE_LEGACY_WEBSOCKET") == null)
{
var provider = new SyncSocketProvider(config.OnSyncWebSocketConnection);
nativeConfig.managed_websocket_provider = GCHandle.ToIntPtr(GCHandle.Alloc(provider));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the initial rollout, I suggest that we use OnSyncWebsocketConnection and tell customers that want to opt in to set the callback to a non-null value.

wrappers/src/CMakeLists.txt Show resolved Hide resolved
@coveralls
Copy link

coveralls commented Aug 15, 2023

Pull Request Test Coverage Report for Build 5869588278

  • 10 of 247 (4.05%) changed or added relevant lines in 6 files are covered.
  • 4 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-2.3%) to 80.669%

Changes Missing Coverage Covered Lines Changed/Added Lines %
Realm/Realm/Native/PrimitiveValue.cs 6 7 85.71%
Realm/Realm/Sync/App.cs 2 5 40.0%
Realm/Realm/Native/SyncSocketProvider.EventLoop.cs 0 53 0.0%
Realm/Realm/Native/SyncSocketProvider.cs 0 72 0.0%
Realm/Realm/Native/SyncSocketProvider.WebSocket.cs 0 108 0.0%
Files with Coverage Reduction New Missed Lines %
Realm/Realm/Exceptions/RealmException.cs 2 78.95%
Realm/Realm/Handles/SessionHandle.cs 2 84.65%
Totals Coverage Status
Change from base Build 5856685018: -2.3%
Covered Lines: 6313
Relevant Lines: 7716

💛 - Coveralls

Copy link
Member

@nirinchev nirinchev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I have a few final comments. Also needs a changelog entry and need to update the app creation logic to use legacy websockets by default and only opt into managed ones if the callback is set (or another property on the app config).

Logger.LogDefault(LogLevel.Trace, e.StackTrace);
}

// TODO: The documentation for WebSocketObserver::async_write_binary() says the handler should be called with RuntimeError in case of errors
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we ping someone on the sync team to get an answer here?

Logger.LogDefault(LogLevel.Trace, e.StackTrace);
}

throw;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think throwing in a background thread will bring down the process - you may get a warning or something, but in release, I think it's just ignored on most platforms.

@fealebenpae fealebenpae marked this pull request as ready for review August 15, 2023 16:29
@fealebenpae fealebenpae merged commit f1a2019 into main Aug 16, 2023
66 of 68 checks passed
@fealebenpae fealebenpae deleted the yg/websocket branch August 16, 2023 10:26
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use managed WebSocket library for the Sync client
3 participants