Similarities and differences
There are a lot of similarities and differences between various things I come across throughout my life.
- On the IBM Z architecture, there is a "program status word", which consists of various CPU flags as well as the instruction pointer. In my mind, it's as if the PSW is just EFLAGS and RIP on x86 clashed together.
- In DC voltage wiring, a red wire is used for power, and a black wire is used for ground. But in AC voltage wiring, a black wire is used for power (hot wire), a white wire is used for power return (neutral wire), and a green (or bare) wire is used for ground. This can be confusing (and dangerous) for electrical engineers who do household electrical wiring, as "grounding" the electrical box with the hot wire can, of course, result in a very dangerous situation (if the circuit breaker did not end up tripping)
- For a given network socket, the "Local Address" column in netstat is equivalent to the address returned by getsockname and the "Foreign Address" column is equivalent to the address returned by getpeername.
- I was once talking about my "special interest" in my economics class in high school, and someone else thought I was talking about interest rates. (as a joke: The interest rate of something can be defined as the percent of people who are interested in something, so the interest rate of math class is 5%.)
- I no longer have any colored shirts because I don't want to be mistaken as an employee in the places that I go shopping in, because they are similar to the shirts and pants that the employees in the store wear. If you're familiar with people who didn't even realize that they wore e.g. a red shirt and khakis to Target or a blue shirt to Walmart, you should understand what I mean. (r/IDontWorkHereLady is the MBOSC heaven for this kind of situation.)
- It took me a lot of effort to convince a Matrix group that DNS and HTTP are related in a certain way, namely that you can have a DNS server which takes in DNS requests and forwards them to an HTTP server, and the HTTP server returns a DNS resource record like object, which the DNS server signs and returns back to the requestor. (See programmatic DNS server.)
- Universal Relay's Transparent Happy Eyeballs feature regarding assignment of "cookie" IP addresses is not much different to Matrix's "portal room" feature, where certain room "aliases" starting with # followed by a human-friendly phrase (often seen with certain bridge bots like those to IRC or Discord) are mapped to automatically generated rooms upon alias resolution, and a room ID for that room (starting with ! followed by random letters) is returned to the client or federation. Room aliases act like DNS names, and room IDs act like IP addresses.
- It could be the case that an increase in crime rate results in an increase in ice cream sales, because children might be concerned about the crimes, so their parents buy them ice cream to make them feel better. Or people may be forced to give criminals ice cream in e.g. a robbery. (This was in Psychology 100 class where the professor discussed that correlation does not imply causation, namely that an increase in ice cream sales does not cause an increase in crime rate.)
- ChatMBR
- Universal Relay and Socketbox, which use getsockname to determine the destination IP address to use in lookup tables, are not much different to memory management, except that it works on IP addresses instead of memory addresses.
- In German, the "B" note in music uses the letter "H". For a long time I thought this was some weird joke on the symbols for the magnetic field.
Protocol converters
"Protocol converters" and "compatibility layers" are particularly interesting to me since you sort of have to know how one interface fits into another. Things to consider are:
- What are the similarities and differences between their interfaces? Do the interfaces appear to share something in common? For example, does the interface operate on a request/response basis or does it push messages without prior intervention?
- For example, SMTP and HTTP both use a request and response system. However, SMTP is stateful whereas HTTP is stateless. If converting SMTP directly to HTTP verbs, then SMTP state information (e.g. the HELO/EHLO hostname, the source IP address, the MAIL FROM address, and the list of recipients in the RCPT TO commands) has to also be sent as much as necessary to evaluate the result of the SMTP verb.
- What high-level object is being conveyed? For example, in a HTTP to SMTP gateway, an email message is the high-level object. An email message can simply be conveyed through a single HTTP POST request. On the other hand, it is not necessary to map HTTP requests and responses directly to SMTP verbs, as it would require tracking of a state object, which, in many cases, would result in unnecessary complication. Similarly, in NTP, the high-level object is the current time.
- Can I simulate an "everything exists" situation in a particular protocol? For example, an SMTP server should give a positive response to a RCPT TO command if the email address in the command exists, and a negative response if the email address does not; this is effectively evaluating a function that takes in an email address as input and returns a Boolean (true/false) that tells whether or not it exists. But it is also possible to always give a positive response to a RCPT TO command and evaluate the existence or nonexistence of a particular email address at the end of the DATA command after the client has sent its email message. (This might not be the best example because it fails to account for the possibility that only some of the email addresses actually exist.)
- Things to consider: Is that part of that protocol the only way to check for the existence or nonexistence of a particular identifier? Does that part of that protocol de facto determine whether or not something exists according to the protocol? Is there a way in the protocol to enumerate the set of valid identifiers? (If the answer to the last question is yes, then it might be much harder to pull off the "everything exists" illusion.)
- Examples of "protocol converters" on peterjin.org:
- Socketbox-preload: converts TCP bind/listen/accept to Socketbox "A" protocol -- high-level object is the socket "stream" returned by multiple successive invocations of
accept(). - Universal Relay: converts regular DNS resolution + connect() as packets from a remote system to domain-name-sensitive TCP stream abstraction -- high-level object is the TCP stream and the destination domain name (not IP address) and port number associated with it.
- Universal Relay programmatic DNS server: converts DNS to HTTP -- high-level object is the set of resource records in the question, answer, and authority sections of the DNS packet (not the DNS packet itself).
- Socketbox-preload: converts TCP bind/listen/accept to Socketbox "A" protocol -- high-level object is the socket "stream" returned by multiple successive invocations of
- Other examples:
- Matrix bridges convert from the Matrix protocol to some other chat protocol -- high-level object is the chat message.
- The primary rationale for protocol converts is to decouple the "logical" aspects of a certain protocol or interface with the "expressive" aspects.
Programmatic [X] servers
| X | High level object | Implementation details |
|---|---|---|
| DNS | DNS record data | DNS requests can be parsed and converted to HTTP requests containing query name and type. HTTP responses contain resource record information and the DNS server converts that information back to a DNS response, and optionally generates RRSIGs (DNSSEC is part of the DNS protocol only; it is not necessary within HTTP since it can still be secured using other means.) |
| DHCP | Host configuration (IP address, subnet mask, default gateway, DNS server, etc.) | DHCP discover and request can be parsed and converted to HTTP requests containing MAC address, requested options, as well as other aspects like VLAN ID. HTTP response contains IP address, subnet mask, and other DHCP options, which is converted to a DHCP offer or DHCP ACK or NAK. |
