Skip to content

[tls] Introduce HandshakerAndConnectionInfo interface.#13081

Closed
ambuc wants to merge 2 commits intoenvoyproxy:masterfrom
ambuc:custom-handshaker-interfaces
Closed

[tls] Introduce HandshakerAndConnectionInfo interface.#13081
ambuc wants to merge 2 commits intoenvoyproxy:masterfrom
ambuc:custom-handshaker-interfaces

Conversation

@ambuc
Copy link
Contributor

@ambuc ambuc commented Sep 14, 2020

Signed-off-by: James Buckland jbuckland@google.com

Commit Message: Introduce HandshakerAndConnectionInfo interface.
Additional Description: @mattklein123 pointed out in #12658 (comment) that the current design of dynamic_pointer_cast-ing an extension impl only works if, as in the test, our custom impl extends the real impl. This PR introduces a new interface with the necessary method, which allows us to remove this unsafe cast.
Risk Level: Low
Testing: N/a
Docs Changes: N/a
Release Notes: N/a

…namic_pointer_cast.

Signed-off-by: James Buckland <jbuckland@google.com>
@ambuc
Copy link
Contributor Author

ambuc commented Sep 14, 2020

/assign lizan

Signed-off-by: James Buckland <jbuckland@google.com>
* which can both perform handshakes and provide connection-specific
* information.
*/
class HandshakerAndConnectionInfo : public Handshaker, public ConnectionInfo {
Copy link
Member

Choose a reason for hiding this comment

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

I'm not thrilled with this interface, with extra virtual method. What is the goal of this PR? If we just want to provide an impl, then we might just make some mixin pattern class for ConnectionInfoImpl. If we want make the cast to ConnectionInfo safe, then perhaps make Handshaker return a ConnectionInfo pointer (in the default impl it just return this).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The goal of this PR is to make the cast safe.

If we have Handshaker return a connectioninfo pointer and save that as info_, it's unclear to me who holds on to the SslHandshaker class for lifetime reasons. Plus info_ also needs socketstate setter/getters, which aren't a part of either the ConnectionInfo or Handshaker interfaces.

But, I agree, I don't love this interface. WDYT?

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 like this either. So we're requiring one class to implement both of these interfaces. Why not just combine them into the same interface? Or if that isn't the right solution, some other refactoring appears needed.

@mattklein123 any thoughts (since you left the original comment)?

Copy link
Member

Choose a reason for hiding this comment

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

My original thinking was to have a connectionInfo() method on the Handshaker interface and then you can handle the lifetime independently, but I don't have a strong opinion either way.

@ambuc ambuc requested a review from lizan September 15, 2020 15:38
@asraa asraa assigned ggreenway and unassigned lizan Sep 16, 2020
@asraa
Copy link
Contributor

asraa commented Sep 16, 2020

@ggreenway are you able to take this over (feel free to re-assign) since Lizan is out?

@ggreenway
Copy link
Member

/wait

@stale
Copy link

stale bot commented Oct 4, 2020

This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Oct 4, 2020
@mattklein123 mattklein123 removed the stale stalebot believes this issue/PR has not been touched recently label Dec 9, 2020
@github-actions
Copy link

github-actions bot commented Jan 8, 2021

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot added the stale stalebot believes this issue/PR has not been touched recently label Jan 8, 2021
@github-actions
Copy link

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

@github-actions github-actions bot closed this Jan 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale stalebot believes this issue/PR has not been touched recently waiting

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants