Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#621 closed task (invalid)

refactoring in resolver (and auth) for response creation

Reported by: jelte Owned by: jelte
Priority: medium Milestone:
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no


The DNS callback methods have a answer MessagePtr? in which the answer is built while we are doing the processing. In some cases, however, this is not used (for instance, if we encounter a problem with the query, in which case an error response is directly rendered to the buffer we also pass along).

In my initial work for #607, I intended to fix this, refactor makeErrorResponse in src/bin/, and make it use the response MessagePtr? for these error as well (instead of reusing the query_message in that case, which would also allow us to make that const). However, this resulted in the tests being updated to reflect that (i.e. that response message is used instead of query_message).

These tests are shared with bin/auth, which right now always reuses the query message for responses (even though answer messageptr is passed around).

So this ticket is meant to do the initial refactor, and make auth and resolver consistent in this regard.

(big part of the code is already written for the initial work on #607)


Change History (4)

comment:1 Changed 9 years ago by stephen

  • Milestone feature backlog item deleted

Milestone feature backlog item deleted

comment:2 Changed 8 years ago by shane

  • Defect Severity set to N/A
  • Owner set to jelte
  • Status changed from new to assigned
  • Sub-Project set to DNS

Do we still work this way? If so, is this part of our current performance improvement plans?

comment:3 Changed 8 years ago by jelte

  • Milestone set to New Tasks
  • Resolution set to invalid
  • Status changed from assigned to closed

It has not had any love since then, and it was never really a performance thing (more of a cleanliness issue). I think that we'll need to reconsider whether this is still relevant anyway, and *that* may very well be part of the performance work (looking at the server architecture for instance). If any work comes out of that, we are better off creating a new ticket anyway, so I'm closing this one.

comment:4 Changed 8 years ago by shane

  • Milestone New Tasks deleted
Note: See TracTickets for help on using tickets.