-
Notifications
You must be signed in to change notification settings - Fork 77
Refactored connection configuration & added alpha locator flow #646
Conversation
41363d7
to
602e797
Compare
63b1e28
to
31e706c
Compare
workers/unity/Packages/com.improbable.gdk.core/Worker/DefaultWorkerConnector.cs
Outdated
Show resolved
Hide resolved
workers/unity/Packages/com.improbable.gdk.core/Worker/DefaultWorkerConnector.cs
Outdated
Show resolved
Hide resolved
workers/unity/Packages/com.improbable.gdk.core/Worker/DefaultWorkerConnector.cs
Show resolved
Hide resolved
workers/unity/Packages/com.improbable.gdk.core/Worker/Worker.cs
Outdated
Show resolved
Hide resolved
workers/unity/Packages/com.improbable.gdk.mobile/Worker/MobileWorkerConnector.cs
Show resolved
Hide resolved
/// </summary> | ||
/// <returns>True, if should connect via the Locator, false otherwise.</returns> | ||
protected override bool ShouldUseLocator() | ||
protected override ConnectionService GetConnectionService() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is getting more complicated now, why not accept a command line argument for connectionService
? Then we assert the parameters using that. The logic within here is too magical at this point.
(Can be done in another PR, shall I make a ticket for it?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The launcher does not pass that argument in... so we would need to check for both cases:
- it is available
- it is not available
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see... will the launcher always be using a particular kind of service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it provides everything to use the alpha locator flow, but you can also use the normal locator flow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
discussed offline, looks good
protected override ConnectionParameters GetConnectionParameters(string workerType, ConnectionService service) | ||
{ | ||
// UseExternalIp needs to be true when using the locator | ||
var useExternalIp = service != ConnectionService.Receptionist || UseExternalIp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be service == this || service == that
instead of service != other /* this imples it's this or that */
(if we add a new method it'll be a bug)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point!
DeploymentTag = steamDeploymentTag, | ||
Ticket = steamTicket, | ||
}, | ||
ProjectName = CommandLineUtility.GetCommandLineValue( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if project name is empty?
/// <param name="connectionFuture">The <see cref="Future{T}"/> of the <see cref="Connection"/> object that we use to connect to the SpatialOS Runtime.</param> | ||
/// <param name="workerType">The type of the worker.</param> | ||
/// <param name="logger">The logger used by the worker.</param> | ||
/// <param name="origin">The position of the worker.</param> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was the text changed from "the origin of this worker in local Unity space" changed to "The position of the worker"? The latter is more ambiguous
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, will change back
140cd83
to
5cd27e2
Compare
/// <summary> | ||
/// Stores the configuration needed to connect via the Alpha Locator. | ||
/// </summary> | ||
public struct AlphaLocatorConfig |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly better to swap these names around. If we know this one is definitely going to be the one we use going forward it might be better to call this the LocatorConfig and the other one the LegacyLocatorConfig.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or we change the names to say what kind of tokens they are using. We can change this later though so it's not that big a deal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Main reason why I call them that way is because the Worker SDK is calling them like that. The current locator flow is still the standard locator, while the new locator is in the alpha namespace
UseExternalIp = true, | ||
}, | ||
EnableProtocolLoggingAtStartup = false, | ||
DefaultComponentVtable = new ComponentVtable(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels weird to be in the worker connector classes. I think it needs a larger refactor to get it out so there is no change to make for now, but it does feel weird.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't find it too weird, as the worker connector takes care of specifying the exact connection logic, but I agree that we could probably separate it out a bit more. Gonna create a ticket to redesign this in the near future
/// <param name="logger">The logger used by this worker.</param> | ||
/// <param name="origin">The origin of this worker in the local Unity space.</param> | ||
/// <returns>A <see cref="Task{TResult}"/> to run this method asyncally and retrieve the created <see cref="Worker"/> object upon connecting successfully.</returns> | ||
private static async Task<Worker> TryToConnect(Future<Connection> connectionFuture, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit - All async functions should have the world Async in them. So this should be TryToConnectAsync
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
cf8d530
to
f9e28a1
Compare
* Cleanup pass * Remove include
Description
Added the new alpha locator flow and refactored the Connection config as part of it.
Read in commit order:
When is which flow chosen for the default worker connector?
Tests
ran a cloud deployment, connected successfully
Documentation
none yet
Primary reviewers
@jamiebrynes7 @samiwh