[Accepted with Revisions] SDL 0141 - Supporting simultaneous multiple transports

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0141 - Supporting simultaneous multiple transports" begins now and runs through March 13, 2018. The original review of "Supporting simultaneous multiple transports" occurred February 13 through February 20, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0141-multiple-transports.md

Please be aware that this proposal is contingent upon others, as noted within the proposal file.

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#405

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
theresa@livio.io

[joeljfischer]

Alternate Transport Flow

Why was the decision made to connect all services across all transports instead of picking and choosing which transport will connect to which transport?

For the iOS proxy I would much prefer the following flow:

1. iOS proxy connects over iAP
2. RPC start service response contains the IP address / port, and which service numbers should support which transport. The RPC transport would always use the IAP transport.
3. If the IAP transport disconnects, all other transports disconnect.

I feel that this would eliminate a lot of complexity and edge cases. It's not quite as powerful with the transport switching and such, but it's far less complex, and I don't feel that the extra power is particularly necessary. We wouldn't have to do packet buffering, for example, which alone is a very complex feature. It has the advantage of not needing to scan the network for TCP connections, which should improve the reliability of the transport. It may eliminate the need for proposal 0142 entirely, as there would never be two different apps connecting on two different transports; since IAP would always be the "primary" transport. This may still be necessary for Android however.

The only downside I can see is that a head unit could not only support TCP and not support IAP at all. However, due to the massive downsides of only supporting TCP (if the user's screen turns off their app goes away, media apps don't work, etc.), I think that's an acceptable requirement.

Receiver Report

The receiverReport may encounter issues on iOS. Scheduled repeating timers do not always work well in the background (at least they did not when heartbeat was used). There may need to be a workaround (e.g. the head unit always sends a receiver report request with their latest and the proxy always responds with its latest, this way the head unit is in charge).

Additional Notes

Because SDLProtocol and SDLProxy are public file in the iOS proxy, the addition of the SDLProtocolSelector and change of functionalities would likely constitute a major version change. It's been accepted that the protocol layer should be made private via a major version change, but I did want to note that.

The design allows the developer to choose which transports they can use, I believe they should not have this choice. It should be managed strictly and only by us. Even if it is decided that the developer should have this choice, it should happen in the LifecycleConfiguration, not via the API described in this proposal.

The modification to HMI_API.xml is breaking and requires a major version change of the HMI_API and Core.

[shoamano83]

Thanks @joeljfischer for your review comments.

Alternate Transport Flow

This is a very good point. The proposal is created in mind that we will pursue the use-case of utilizing just Wi-Fi transport, especially on Android phones. We are aware that on iOS, iAP transport is almost mandatory for production apps. Perhaps @robinmk can tell the background a little more.
Also, we want apps to be transport agnostic on Android. Ideally, we don't want to say like "this transport is mandatory and others are optional".

It may eliminate the need for proposal 0142 entirely, as there would never be two different apps connecting on two different transports; since IAP would always be the "primary" transport. This may still be necessary for Android however.

I'll reply to this comment in SDL 0142.

The receiverReport may encounter issues on iOS. Scheduled repeating timers do not always work well in the background (at least they did not when heartbeat was used).

Thanks for the info. The idea is to send Receiver Report frames periodically from both Core and Proxy. I don't know the optimal value for an interval of the frames, but I think 500 or 1000 msecs will work. So iOS Proxy will be woken up periodically when it receives frames from Core, and I think it will have chances to send frames while it is awake.
By the way, do you know the interval and timeout value used for HeartBeat?

Because SDLProtocol and SDLProxy are public file in the iOS proxy, the addition of the SDLProtocolSelector and change of functionalities would likely constitute a major version change.

OK thanks, I wasn't aware that SDLProtocol is public. I'm looking at iOS Proxy's code now and I would like to keep consistency of SDLProxy's public interface as much as possible.

The design allows the developer to choose which transports they can use, I believe they should not have this choice. It should be managed strictly and only by us.

Right now it is up to each app developer to decide which transport is used. I thought I should not break this basic design, and that was why I proposed an API like this. I'm completely fine to switch to an idea in which Proxy selects the transport instead of app. I just want to know if everyone is OK with it (since that seems to be a major change).

Even if it is decided that the developer should have this choice, it should happen in the LifecycleConfiguration, not via the API described in this proposal.

Regarding the LifecycleConfiguration, I think you are right. I was looking at the methods in ProxyManager.m, which are example codes.

The modification to HMI_API.xml is breaking and requires a major version change of the HMI_API and Core.

Yes. Actually this proposal was developed prior to the discussion in SDL 0138. I think we may need to come up with another HMI_API idea which has less impact.

[robinmk]

Alternate Transport Flow

From what I understand, this design sacrifices the ability for apps from multiple Android devices connected over Wi-Fi from registering since there is a dependency on BT. However, the design does indeed greatly reduce the complexity of the feature.
We will make an internal assessment on sacrifice in the use cases vs reduction in complexity and provide our feedback.

[joeljfischer]

By the way, do you know the interval and timeout value used for HeartBeat?

I believe it was 5 seconds.

OK thanks, I wasn't aware that SDLProtocol is public. I'm looking at iOS Proxy's code now and I would like to keep consistency of SDLProxy's public interface as much as possible.

It's been in the works for quite a while now to hide the SDLProxy, Protocol, and Transport layers by making them private. That should happen this year anyway. I'm just making everyone aware that by the time this was implemented, this would have to be done or it would be a breaking change.

Right now it is up to each app developer to decide which transport is used. I thought I should not break this basic design, and that was why I proposed an API like this. I'm completely fine to switch to an idea in which Proxy selects the transport instead of app. I just want to know if everyone is OK with it (since that seems to be a major change).

Technically, yes. The developer can choose, however, they only have a choice between a debug and a production transport. I think this should stay, and a developer shouldn't have to choose between production transports. To put that decision on the developer is a recipe for confusion.

Yes. Actually this proposal was developed prior to the discussion in SDL 0138. I think we may need to come up with another HMI_API idea which has less impact.

Thanks, this is important to note.

[robinmk]

Alternate Transport Flow

We agree that the simplicity offered by the design mentioned by Joel outweighs the limits imposed on the certain use-cases. We will work on creating proposals which explains the design more in depth.