| Age | Commit message (Collapse) | Author |
|---|
|
The log level cache changed to the following format,
... {MSG_ID QNAME TYPE TTL} ...
where MSG_ID is the message ID, QNAME is the question name, TYPE is the
type of question, and TTL is the time-to-live of the answer.
This changes require adding field TTL to Answer and exporting the field
Message.
|
|
With help of spdxconv tool [1], we able to bulk update all files license
and copyright format to comply with SPDX formats.
[1] https://kilabit.info/project/spdxconv/
|
|
The previous API for Message is a little bit weird.
Its provides creating Message manually, but expose the method
[UnpackHeaderQuestion], meanwhile the field packet itself is unexported.
In order to make it more clear we refactor [Message.Unpack] to
function [UnpackMessage] that accept raw DNS packet.
|
|
There are several reasons that why we move from github.com.
First, related to the name of package.
We accidentally name the package with "share" a common word in English
that does not reflect the content of repository.
By moving to other repository, we can rename it to better and unique
name, in this "pakakeh.go".
Pakakeh is Minang word for tools, and ".go" suffix indicate that the
repository related to Go programming language.
Second, supporting open source.
The new repository is hosted under sourcehut.org, the founder is known
to support open source, and all their services are licensed under AGPL,
unlike GitHub that are closed sources.
Third, regarding GitHub CoPilot.
The GitHub Terms of Service [1], allow any public content that are hosted
there granted them to parse the content.
On one side, GitHub helps and flourish the open source, but on another
side have an issues regarding scraping the copyleft license [2].
[1]: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#4-license-grant-to-us
[2]: https://githubcopilotinvestigation.com
|
|
Using ":=" simplify the code but we lose the type. For example,
v := F()
The only way we know what the type of v is by inspecting the function
F.
Another disadvantages of using ":=" may cause extra variables
allocation where two or more variables with same type is declared
inside body of function where it could be only one.
While at it, we split the struct for test case into separate type.
|
|
Using the fieldalignment, we got the following output,
answer.go:15:13: struct with 56 pointer bytes could be 24 = 32 bytes
caches.go:27:13: struct with 24 pointer bytes could be 16 = 8
dot_client.go:20:16: struct with 16 pointer bytes could be 8 = 8
hosts_file.go:24:16: struct with 64 pointer bytes could be 48 = 16
message.go:53:14: struct of size 176 could be 168 = 8
rdata_mx.go:20:14: struct with 16 pointer bytes could be 8 = 8
rdata_opt.go:18:15: struct with 16 pointer bytes could be 8 = 8
rdata_srv.go:16:15: struct with 64 pointer bytes could be 56 = 8
rdata_wks.go:30:15: struct with 40 pointer bytes could be 32 = 8
request.go:20:14: struct with 32 pointer bytes could be 24 = 8
resource_record.go:24:21: struct with 56 pointer bytes could be 40 = 16
server.go:76:13: struct with 120 pointer bytes could be 112 = 8
server_options.go:20:20: struct of size 240 could be 224 = 16
tcp_client.go:21:16: struct with 40 pointer bytes could be 24 = 16
udp_client.go:24:16: struct with 24 pointer bytes could be 16 = 8
udp_client_pool.go:25:20: struct with 24 pointer bytes could be 16 = 8
zone_file.go:22:15: struct with 128 pointer bytes could be 120 = 8
zone_parser.go:53:17: struct with 88 pointer bytes could be 72 = 16
Turns out the struct that we frequently used, answer and resource_record,
is not optimized.
This changes reorder all structs field to save space in memory.
|
|
Previously the type for message question section SectionQuestion.
This changes, rename the type to MessageQuestion.
|
|
This changes rename the SectionHeader into MessageHeader.
The pack() method is optimized with the following results,
benchmark old ns/op new ns/op delta
BenchmarkMessageHeader_pack-8 66.2 21.7 -67.31%
benchmark old allocs new allocs delta
BenchmarkMessageHeader_pack-8 3 1 -66.67%
benchmark old bytes new bytes delta
BenchmarkMessageHeader_pack-8 32 16 -50.00%
The unpack() method is simplified by minimizing the if-condition.
This changes also fix the pack and unpack OpCode for value other then 0,
due to wrong shift value, 2 instead of 3.
|
|
Previously, the record class is represented by uint16 using prefix
QueryClassXxx.
This changes make the record class to be an independent type, to make
code more strict (prevent passing invalid value), and readable.
|
|
Previously, we use uint16 to represent type for ResourceRecord Type or
Question type.
To make the code more strict, where parameter or return value, must be
expected as record type, we add new type to represent the RR type:
RecordType.
This changes also rename any variable name of QType or qtype to RType
or rtype because QType is misleading. The type defined the
ResourceRecord to be queried not only question.
|
|
Previously, the test.Assert and test.AssertBench functions has the
boolean parameter to print the stack trace of test in case its not equal.
Since this parameter is not mandatory and its usually always set to
"true", we remove them from function signature to simplify the call
to Assert and AssertBench.
|
|
The CachesLRU method return the list of non-local caches ordered by
the least recently used.
This changes affect the answer type which must be exported, including
most of its fields, so consumer can access it.
|
|
This field is used for storing the actual DNS packet after Message.Pack
has been called.
|
|
There are two reasons for this changes. First, to allow JSON encoded
of ResourceRecord.Value without encoded to base64.
Second, to minimize unreleased packet due to the backing storage is
still used when assigned to Value (or any []byte field in RDataXXX).
|
|
Previously, each record data is represented b¥ its own type, except
for A, NS, CNAME, MB, MG, NULL, PTR, and TXT; represented b¥ slice of
byte.
This changes replace all record data with an interface{}.
|
|
|
|
|
|
There are two type of answer: local and non-local.
Local answer is a DNS record that is loaded from hosts file or master
zone file.
Non-local answer is a DNS record that is received from parent name
servers.
Server caches the DNS answers in two storages: map and list.
The map caches store local and non local answers, using domain name as a
key and list of answers as value,
domain-name -> [{A,IN,...},{AAAA,IN,...}]
The list caches store non-local answers, ordered by last accessed time,
it is used to prune least frequently accessed answers.
Local caches will never get pruned.
|
