Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
we used to accumulate hacks and further maps and workaround just to ensure that "to each IP address, establish a single connection" -- esp. at startup of the primary (where it may want to inform a single IP about 100 zones; or when it received a signed SOA request (with a root key) for the root zone, replying with NOTIFY for all authoritative zones) and secondary (where it may want to request the SOA of a single primary for multiple zones). now, instead of having the result
(ip * cstruct.t) list
, using(ip * cstruct.t list) list
allows the effectful layer to send all the notify/requests to that single ip address at once! (i.e. no fold and establish connections necessary :)similarly, the secondary API got slightly revised, turns out
handle_*
may only ever result in one reply and optionally one other packet to the authoritative (i.e. when a notify is received, a notify_ack is replied with, and a SOA request is sent (or directly ixfr/axfr if the notify contained a signed soa)).now, the ad-hoc
tcp_packet_transit
map is gone, there are retransmissions in thetimer
function which care exactly about that (that something is sent, but not acknowledged on the protocol level).this cleans up #169 and #170, could get some unit tests about the above described startup and update struggle, and looks to me as the last blocker of a release.
@cfcs if you could review this as now, that'd be great. i'll surely push some more documentation and unit tests directly on this PR before merging, think a bit more, and likely tag a release (unless you find blockers -- i guess #165 would be good to have fixed as well, I'll propose in a separate PR in a few minutes).