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

[SDL 0141] Supporting simultaneous multiple transports #900

Closed
theresalech opened this Issue Mar 16, 2018 · 1 comment

Comments

Projects
1 participant
@theresalech
Contributor

theresalech commented Mar 16, 2018

Note that separate discussions will need to take place to confirm proxy implementation details for this proposal.

Proposal: Supporting simultaneous multiple transports

This proposal aims to support multiple transports between Core and Proxy.

Review: smartdevicelink/sdl_evolution#405

Steering Committee Decision:

The Steering Committee has voted to accept this proposal with revisions. The revisions are as follows:

  • Introduce a new Control Frame, RegisterSecondaryTransport, which will be used once a Secondary Transport is connected to notify Core that the Proxy has established a connection and tell Core which session is registering.
  • Rename Transport Config Update to TransportEventUpdate. The original parameters will be refactored to a flat structure.
  • StartServiceACK for the RPC service will contain a Secondary Transport param that will contain an array of potential secondary transports instead of a single value. The service to transport priority parameters will become flat instead of document style; each service param will contain an ordered array in terms of priority of potential transports.
  • Proxy connection retry strategy will include the new TransportEventUpdate Control Frame. When a connection is interrupted/ended, a TransportEventUpdate control frame will be sent to the proxy on the primary transport. If the proxy is to retry (in case of WiFi), it will include the IP address and Port. If the proxy is not to retry, the frame will contain either empty strings for IP address and port or not include the parameters at all.
  • Will recommend, but not require, using 5GHz
  • Proxy implementations will be discussed outside of this proposal.

The proposal .md was updated on March 16, 2018 to include the agreed upon revisions.

@theresalech

This comment has been minimized.

Contributor

theresalech commented Sep 26, 2018

Closed via #947

v6.1.0 automation moved this from In Review to Done Sep 26, 2018

@joeljfischer joeljfischer referenced this issue Oct 19, 2018

Merged

v6.1.0 Release #999

3 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment