Skip to content
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

FilterChain: Arguments should be a context object, and return a response object #94

Closed
markmandel opened this issue Aug 26, 2020 · 0 comments · Fixed by #102
Closed
Assignees
Labels
kind/cleanup Refactoring code, fixing up documentation, etc kind/design Proposal discussing new features / fixes and how they should be implemented

Comments

@markmandel
Copy link
Member

markmandel commented Aug 26, 2020

Passing in a context and returning a result object means we can add extra fields to our Filter methods without breaking the type signatures down the line.

Something like this:

pub struct DownstreamContext {
    endpoints: [EndPoint],
    from: SocketAddr,
    contents: Vec<u8>,
}

pub struct UpstreamContext {
    endpoint: EndPoint,
    from: SocketAddr,
    to: SocketAddr,
    contents: Vec<u8>,
}

pub struct DownstreamResponse {
    endpoints: Vec<EndPoint>,
    contents: Vec<u8>,
}

pub struct UpstreamStreamResponse {
    contents: Vec<u8>,
}

/// Filter is a trait for routing and manipulating packets.
pub trait Filter: Send + Sync {
    /// on_downstream_receive filters packets received from the local port, and potentially sends them
    /// to configured endpoints.
    /// This function should return the array of endpoints that the packet should be sent to,
    /// and the packet that should be sent (which may be manipulated) as well.
    /// If the packet should be rejected, return None.
    fn on_downstream_receive(
        &self,
        ctx: &DownstreamContext
    ) -> Option<DownstreamResponse>;

    /// on_upstream_receive filters packets received from `from`, to a given endpoint,
    /// that are going back to the original sender.
    /// This function should return the packet to be sent (which may be manipulated).
    /// If the packet should be rejected, return None.
    fn on_upstream_receive(
        &self,
        ctx: &UpstreamContext
    ) -> Option<UpstreamstreamResponse>;
}

How do people feel about this?

@markmandel markmandel added kind/cleanup Refactoring code, fixing up documentation, etc kind/design Proposal discussing new features / fixes and how they should be implemented labels Aug 26, 2020
@iffyio iffyio self-assigned this Sep 9, 2020
iffyio added a commit that referenced this issue Sep 9, 2020
Since the objects are exposed to the filter API we would
like to be able to control how they're created so that we don't
break code whenever we e.g add new fields - for this we use
phantoms, we might also need to make the `Context::new()` constructors
private from the filter functions since a filter shouldn't need
to create them to begin with.

Fixes #94
markmandel pushed a commit that referenced this issue Sep 11, 2020
* Pass context objects in filter APIs

Since the objects are exposed to the filter API we would
like to be able to control how they're created so that we don't
break code whenever we e.g add new fields - for this we use
phantoms, we might also need to make the `Context::new()` constructors
private from the filter functions since a filter shouldn't need
to create them to begin with.

Fixes #94

* Fix docs example
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Refactoring code, fixing up documentation, etc kind/design Proposal discussing new features / fixes and how they should be implemented
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants