Info

Download ZIP (15.6 KB)

Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.

Voting

44

Comments

Huge Giraffe Oct 16, 2019 at 11:36
Implements Manual DNS (pretty well, hopefully). Also check out suggested flexible format for registering DNS entries. Read full details in readme
2
Huge Giraffe Oct 16, 2019 at 20:49
Found a small issue: my code returns (-1, null) instead of (0, null) from dnsresolve in failure case. For some reason I thought this is was what spec said. This only needs to be corrected in one place (TRUE -> ZERO): https://github.com/nikstar/ton-dns/blob/master/stdlib_ext.fc#L7
Huge Giraffe Oct 21, 2019 at 14:22
Just to clarify, this contract works fine with zero separators (as well as any others). "org∅ton∅test∅" is handled correctly; terminating zero can be omitted in dnsresolve
You have not added any comments yet...
by rating

Issues

Clever Turkey Nov 4, 2019 at 19:03
Manual DNS:
+ Ability to completely delete expired domains.
+ Support for different value types.
- Returns number of bytes instead of number of bits.
- not_found() return TRUE as first value in contradiction with the specification.
- When domain is found, but category is not found the returned length must be non-zero.
- resolvedns can return value of "org\0" for "org\0\0".
10
Huge Giraffe Nov 4, 2019 at 19:13
Thanks. FWIW I've updated dnsresolve to fully match spec https://github.com/nikstar/ton-dns/blob/master/manual-dns.fc#L83
Hi, thanks for review.

1) I think you should have stored subdomains with separating and terminating zero bytes, otherwise your dns resolve function does not handle inputs as mentioned in requirements. For example if you have registered subdomain 'org.ton', it must be stored as 'org\0ton\0' in prefix dict. And for request 'org\0\ton\0test\0' dnsresolve should return the value for the category -1 (next resolver) stored in that subdomain. In your case it will return not found. 

2) If i understand it correctly, the returned lenght should be in bits, since in requirements it says ((8m, dns-record-value), where *m* is one plus the number of bytes in the subdomain found.). So 8m means bits.
Huge Giraffe Oct 19, 2019 at 09:44
Thanks for your review!

1) I wanted to avoid storing terminating zeros - prefix dict does not need them and it's wasted space. My contract does not need \0 after full domain in dnsresolve, but it will still work with it. This allows for using dnsresolve from command line without hex encoding.

My code is completely separator agnostic (it can be dots, zeros, or anything). Your example will in fact work - is's still a prefix. And it will return category -1 (assuming you pass terminating zero to register - this is why I don't like this interpretation of the task; if this is indeed the desired behavior, only register.fif needs to be changed). My version cont: https://pastebin.com/JF2FbtuE
Shiny Giraffe Oct 21, 2019 at 10:38
Prefix dictionary actually needs the trailing ∅, otherwise if you register dom, it would not be possible to register domain, because dom is prefix of domain. If storing ending ∅, then dom∅ will not be prefix of domain∅.

Although I would like to apprise the usage of forward declarations and overall structure and simplicity of the code. I wonder if those inlines really work, because for me the compilator did not care.
Huge Giraffe Oct 21, 2019 at 11:38
That's true, I guess I just wanted to point out that special symbol can be arbitrary (like dot in my example), and contract code does not need to know about it at all.

As for inline, it changes calldict -> inlinecalldict in compiled .fif file, and significantly improves performance. Compare gas for first call in test-register: steps: 74 gas: used=3556 (with inline) vs steps: 94 gas: used=6396 (no inline). Full comparison in gist
https://gist.github.com/nikstar/02f17d70aca271a7b6204a7ccdc49946/revisions#diff-c45b9eb4047adbfd095f68350d86787f (left is with inline - better)
(Hopefully compiler will learn to do this automatically)
Nobody added any issues yet...