Opened 8 years ago

Closed 8 years ago

#1278 closed task (complete)

SOA serial number comparison utility

Reported by: jinmei Owned by: jelte
Priority: very high Milestone: Sprint-20111206
Component: libdns++ Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket: IXFR-in
Estimated Difficulty: 3 Add Hours to Ticket:
Total Hours: 9.25 Internal?: no

Description

To really complete #1261 (IXFR-in), and also to make AXFR-in more
complete, we need a utility to compare SOA serials in terms of
the serial number arithmetic.

This could be a simple extension to libdns++ (and pydnspp). Or,
if we think it's too generic to be part of DNS (the concept itself
is not specific to DNS) this could be in a generic utility module.

The implementation should be very trivial even from the scratch,
but it would even be better to port a proven existing implementation
(adding tests of course). BIND 9 has its utility in bind9/lib/isc/serial.c.

Subtickets

Change History (17)

comment:1 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Year 3 Task Backlog

comment:2 Changed 8 years ago by jinmei

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed
  • Priority changed from major to blocker

comment:3 Changed 8 years ago by jelte

  • Add Hours to Ticket changed from 0 to 3

comment:4 Changed 8 years ago by jelte

  • Add Hours to Ticket 3 deleted
  • Estimated Difficulty changed from 0 to 3

comment:5 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Year 3 Task Backlog

We didn't include this for next sprint, but I have a feeling it may be a necessary prerequisite for good support of transfers and differences. If it turns out we need it we should pull it in too, otherwise we definitely need to do this next sprint

comment:6 Changed 8 years ago by jinmei

  • Milestone changed from Year 3 Task Backlog to Next-Sprint-Proposed

comment:7 Changed 8 years ago by jelte

I wonder if, since we are using c++ anyway, it wouldn't be cleaner to make a specific type Serial, with overloaded comparison values, rather than a set of utility functions.

comment:8 Changed 8 years ago by jelte

  • Milestone changed from Next-Sprint-Proposed to Sprint-20111206

comment:9 Changed 8 years ago by jelte

  • Owner changed from UnAssigned to jelte
  • Status changed from new to assigned

comment:10 Changed 8 years ago by jelte

  • Owner changed from jelte to UnAssigned
  • Status changed from assigned to reviewing

Ready for review, it's a bit bigger than originally conceived, as I added a full class for this (and included nearly everything relevant I could find in the RFC as tests), but most of it should be pretty straightforward.

One note, rdata::soa::getSerial() returns this new type now (an API change), instead of the uint32_t. One of the instances where it is actually used right now is that datasource database layer, where it still expects a uint32_t. This is intentional, as this type represents 'dns knowledge'. There is is 'converted' back using getValue().

comment:11 Changed 8 years ago by vorner

  • Owner changed from UnAssigned to vorner

comment:12 follow-up: Changed 8 years ago by vorner

  • Owner changed from vorner to jelte

Hello

The documentation in python says „and the + operand“ (should the operator).

Should the python test invalid type to the + operator and the comparison operator, what it does?

When C++ already has the <= and >= operators, it may be better to use these from the python wrapper.

When you do the addition, instead of the conditions, wouldn't it be easier to just sum them up as 64bit integers and mask-off the high bits? Or, is C++ overflow behaviour defined? Because this way it looks quite complicated, when the only needed thing is to + modulo 232.

Should it have a changelog?

Thanks

With regards

comment:13 in reply to: ↑ 12 Changed 8 years ago by jelte

  • Owner changed from jelte to vorner

Replying to vorner:

Hello

The documentation in python says „and the + operand“ (should the operator).

oops, fixed

Should the python test invalid type to the + operator and the comparison operator, what it does?

yeah, added

When C++ already has the <= and >= operators, it may be better to use these from the python wrapper.

ack, changed

When you do the addition, instead of the conditions, wouldn't it be easier to just sum them up as 64bit integers and mask-off the high bits? Or, is C++ overflow behaviour defined? Because this way it looks quite complicated, when the only needed thing is to + modulo 232.

yeah, probably. Done. Added another constant for niceness and no
'magic numbers'. BTW, renamed existing one to include serial in its
name.

Should it have a changelog?

Hmm, yes, probably; proposal:

[func] jelte
libdns++ (and its python wrapper) now includes a class Serial, for SOA
SERIAL comparison and addition. Operations on instances of this class
follow the specification from RFC 1982. Rdata::SOA::getSerial() now
returns values of this type (and not uint32_t).

comment:14 Changed 8 years ago by vorner

Thans, everything seems to be reviewed. Please merge.

comment:15 Changed 8 years ago by vorner

  • Owner changed from vorner to jelte
  • Total Hours changed from 0 to 1.25

comment:16 Changed 8 years ago by shane

  • Feature Depending on Ticket set to IXFR-in

comment:17 Changed 8 years ago by jelte

  • Resolution set to complete
  • Status changed from reviewing to closed
  • Total Hours changed from 1.25 to 9.25

Merged, closing ticket

Note: See TracTickets for help on using tickets.