Via a fairlyarbitraryprocess, I've got to a stage of explaining pragmatic problems with naming stuff in a computer.
Many naming schemes require a name resolution process. The process used by DNS is overly complicated. Although it would be easy to poke fun at systemd's repeatedfailures in this field, djbdns has been attacked with cache poisoning and steps have been taken to mitigate timing attacks by implementing UDP port randomization. An observation which could be made from djb's similar syncookies is that it is insufficient to implement baseline TCP or DNS because the Internet has become too hostile.
I investigated the implementation of Project Xanadutransclusion using DNS. The use of UDP to assemble small fragments of data in a fault-tolerant manner has obvious appeal. DNS's maximum fragment length of 255 bytes is unfortunate but can be overcome. However, popular DNS implementations, such as BIND are don't cache unknown response types. This means A records, TXT records or suchlike would have to be overloaded. Ideally, this should be handled carefully due to compressed encoding workarounds and record permutation compatible with the POSIX legacy singleton record interface.
It is possible to ignore these pleasantries and transport raw data as A records but this has two problems. Firstly, to obtain raw records, the local resolving has to be located without the benefit of the host's DHCP or suchlike. Secondly, administrators baulk at volume of data transported via their DNS infrastructure - and rightly so because this doesn't degrade gracefully. One user's browsing would be sufficient to cause intermittant or sustained host resolution failure within a local network. Video streaming over DNS is feasible to implement but would be anti-social to anyone sharing upstream infrastructure.
An erroneous assumption made by Project Xanadu is that multi-media can be handled almost as a corollary of handling text. I presume the logic is that multi-media is traditionally serialized and therefore can be subjected to similar constraints as paragraphs of text. However, I believe this is backward. If multi-media can be handled as three dimensional data (horizontal, vertical, frame number) or two dimensional data (audio channel, position) then one dimensional data (text) is the corollary.
So, an outline of requirements is as follows:-
Simplified DNS is desirable.
Traffic priority should be lower than legacy DNS implementation.
Should be optimized for small payloads but allow arbitrary volumes of data.
Should permit addressing of one frame of video.
If possible, should permit addressing of a range of video frames.
Although this looks like a system favoring a hierarchy of servers within one domain of trust, it remains possible to implement a federation of server hierarchies.
Problems With Names, Part 3
(This is the fourth of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)
Via a fairly arbitrary process, I've got to a stage of explaining pragmatic problems with naming stuff in a computer.
Many naming schemes require a name resolution process. The process used by DNS is overly complicated. Although it would be easy to poke fun at systemd's repeated failures in this field, djbdns has been attacked with cache poisoning and steps have been taken to mitigate timing attacks by implementing UDP port randomization. An observation which could be made from djb's similar syncookies is that it is insufficient to implement baseline TCP or DNS because the Internet has become too hostile.
I investigated the implementation of Project Xanadu transclusion using DNS. The use of UDP to assemble small fragments of data in a fault-tolerant manner has obvious appeal. DNS's maximum fragment length of 255 bytes is unfortunate but can be overcome. However, popular DNS implementations, such as BIND are don't cache unknown response types. This means A records, TXT records or suchlike would have to be overloaded. Ideally, this should be handled carefully due to compressed encoding workarounds and record permutation compatible with the POSIX legacy singleton record interface.
It is possible to ignore these pleasantries and transport raw data as A records but this has two problems. Firstly, to obtain raw records, the local resolving has to be located without the benefit of the host's DHCP or suchlike. Secondly, administrators baulk at volume of data transported via their DNS infrastructure - and rightly so because this doesn't degrade gracefully. One user's browsing would be sufficient to cause intermittant or sustained host resolution failure within a local network. Video streaming over DNS is feasible to implement but would be anti-social to anyone sharing upstream infrastructure.
An erroneous assumption made by Project Xanadu is that multi-media can be handled almost as a corollary of handling text. I presume the logic is that multi-media is traditionally serialized and therefore can be subjected to similar constraints as paragraphs of text. However, I believe this is backward. If multi-media can be handled as three dimensional data (horizontal, vertical, frame number) or two dimensional data (audio channel, position) then one dimensional data (text) is the corollary.
So, an outline of requirements is as follows:-
Although this looks like a system favoring a hierarchy of servers within one domain of trust, it remains possible to implement a federation of server hierarchies.
Post Comment