-
Notifications
You must be signed in to change notification settings - Fork 5.4k
matching: add UDP support for network input types #20116
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
Changes from 4 commits
3a914cf
d0865a8
d322434
557b729
6751438
536e089
59b6bdb
8525928
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -19,6 +19,22 @@ class MatchingDataImpl : public MatchingData { | |
| const ConnectionSocket& socket_; | ||
| }; | ||
|
|
||
| /** | ||
| * Implementation of Network::UdpMatchingData, providing UDP data to the match tree. | ||
| */ | ||
| class UdpMatchingDataImpl : public UdpMatchingData { | ||
| public: | ||
| explicit UdpMatchingDataImpl(const Address::InstanceConstSharedPtr& local_address, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No need for
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, fixed.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have added some tests integrating matcher with network inputs. And I have opened #20324 to track issues about templated factory registrations inheritance. |
||
| const Address::InstanceConstSharedPtr& remote_address) | ||
| : local_address_(local_address), remote_address_(remote_address) {} | ||
| const Address::InstanceConstSharedPtr& localAddress() const override { return local_address_; } | ||
| const Address::InstanceConstSharedPtr& remoteAddress() const override { return remote_address_; } | ||
|
|
||
| private: | ||
| const Address::InstanceConstSharedPtr& local_address_; | ||
| const Address::InstanceConstSharedPtr& remote_address_; | ||
| }; | ||
|
|
||
| } // namespace Matching | ||
| } // namespace Network | ||
| } // namespace Envoy | ||
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 think it would be simpler if we merged this into
MatchingDataand madesocketoptional. We can modify the inputs to avoid usingsocketwhenever possible, so they apply to both TCP and UDP.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 am not sure if it works, since
MatchingDatacurrently have inputs likeServerNameInputwhich only works on TCP now.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.
But you can have SNI in DTLS, no? So in theory, the input could work for datagrams. I'm not certain it's a good idea to combine TCP/UDP datatype, just thinking through.
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 get your idea. Do you think it would be better if we provide interfaces like
onSocket,onDestinationIpwhich is similar toHttpMatchingDataImpl? @snowpThere 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 issue is not the callback but the way we get the local address is different between TCP, HTTP, UDP. So I guess it's fine to have separate UDPMatchingData since we have to implement Input functions three times anyways. It's unfortunate that we can't reuse code as much as we'd like.
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.
Yes, I mean we can make
Socket,DestinationIpinMatchingDataasOptRefs and use certain methods to assign their value. It is also a feasible way, but I vote for separatingMatchingDatasince the way to construct aMatchingDatawithsocketlooks more natural. And I wish some day we can have template inheritance, so their will be no waste of codes.Uh oh!
There was an error while loading. Please reload this page.
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.
Given how icky the situation is without, can we take a stab at getting something generic working? I can imagine something like
which would require all the data impls to specify either their "base class" or a singleton type. We could probably come up with something clever to avoid having to specify terminal type but might not be worth the complexity
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.
We are going to register
Factory<BaseMatchingData>forFactory<DerivedMatchingData>, and the method we make factories to find their base class may not work, since their is no direct inheritance betweenFactory<Base>andFactory<Derived>.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.
Thanks for digging into this, seems like it will require some more work so let's get this merged