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

Introduce a new net::server module #482

Draft
wants to merge 25 commits into
base: new-base
Choose a base branch
from
Draft

Introduce a new net::server module #482

wants to merge 25 commits into from

Conversation

bal-e
Copy link
Contributor

@bal-e bal-e commented Jan 27, 2025

This is a work-in-progress PR for overhauling net::server on top of new_base. It aims to address some of the shortcomings we have encountered with the service layering design, while otherwise being a relatively faithful refactoring of the entire module.

bal-e added 3 commits January 27, 2025 12:47
'Service' and 'ServiceLayer' are the most important traits defined here
('{Consume,Produce,Transform}Message' are auxiliary traits providing
high-level message parsing and building, specific to DNS server code).
The vast majority of the code is complex blanket implementations which
make these traits effortless to use.  As some examples:

- (ServiceLayer, Service): Service
- (Vec<ServiceLayer>, Service): Service
- (Vec<ServiceLayer>, Arc<ServiceLayer>, Service): Service

This makes it incredibly easy to compose services together, without
the restrictions of nesting that 'net::server' imposes.  Each service
layer is also much simpler, since it does not have to be generic over
the next layer in the pipeline.

The provided tuple implementations make it easy to use these layers in
static contexts, and it allows the compiler to inline everything into a
single function.

The auxiliary traits are also critical to the design -- they allow
messages to be parsed and built in a single iteration, preventing the
repetitive parsing of e.g. compressed names.  There are still open
questions regarding their flexibility for certain use cases.

The next step is to implement services and service layers using these
traits, and to use the traits from a transport implementation.
@bal-e bal-e self-assigned this Jan 27, 2025
bal-e added 22 commits January 28, 2025 10:19
- 'Service' and 'ServiceLayer' have been split into "local" (i.e.
  single-threaded) and non-local versions, both using 'async'.  A
  synchronous trait could be added for them in the future.

- Rust was having issues with the 'req lifetime and its interactions
  with 'async' through an associated type.  I gave up and dropped the
  'ConsumeMessage' trait, now directly providing the request message to
  'respond()'.

- A stub 'RequestMessage' type has been defined, which will provide
  relatively efficient access to the message.  It contains caches of
  indices for the initial records and EDNS options.
- Layers can now modify requests before passing them forward.

- Layers can now see the entire request, allowing them to ensure that
  it is entirely consistent.  Previously, they could only see one piece
  at a time, in order, preventing them from modifying a record based on
  the contents of a record following it.

- Layers can now truncate a message when they see fit.

- 'ParsedMessage' is used to represent requests and responses; it will
  allocate on the heap, but it provides extremely fast traversal of the
  entire message (as every message component is directly indexable).

  - EDNS support is hardcoded in 'ParsedMessage'; this could make it
    brittle to future changes in the DNS specs, but service layers rely
    on EDNS and need to be able to find EDNS options quickly.

- Trait objects are better supported, in terms of performance; there
  will only be two method calls to every 'dyn ServiceLayer'.  The old
  API would have one method call for every message component in the
  request and the response.

- The 'Service' and 'ServiceLayer' traits no longer have associated
  types, and are now possible to use as trait objects directly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant