Changed IP address to endpoint.

doc/BlocktreeCloudPaper/BlocktreeCloudPaper.tex

@@ -263,8 +263,8 @@ anonymous connections are rejected.
 When a client connects with credentials,
 mutual TLS authentication is performed as part of the connection handshake,
 which cryptographically verifies the credentials of each runtime.
-These credentials contain the filesystem paths where each runtime is located,
-which ensures that messages addressed to a specific path will only be delivered to that path.
+These credentials contain the filesystem paths where each runtime is located.
+This information is used to securely route messages between runtimes.
 The \texttt{bttp} server is always authenticated during the handshake,
 even when the client is connecting anonymously.
 Because QUIC supports the concurrent use of many different streams,
@@ -272,10 +272,10 @@ it serves as an ideal transport for a message oriented system.
 \texttt{bttp} uses different streams for independent messages,
 ensuring that head of line blocking does not occur.
 Note that although data from separate streams can arrive in any order,
-the protocol does provide reliable in-order delivery of data in a given stream.
+the protocol does provide reliable in-order delivery of data in any given stream.
 The same stream is used for sending the reply to a message dispatched with \texttt{call}.
 Once a connection is established,
-message may flow both directions (provided both runtimes have execute permissions for the other),
+messages may flow both directions (provided both runtimes have execute permissions for the other),
 regardless of which runtime is acting as the client or the server.
 
 % Delivering messages locally.
@@ -366,18 +366,23 @@ and the message is delivered to the first provider of \texttt{service} which is
 When there are multiple service providers to which a given message could be delivered,
 the one to which it is actually delivered is unspecified,
 which allows the runtime to balance load.
-Delivery will occur for at most one recipient,
+Delivery will occur to at most one recipient,
 even in the case that there are multiple potential recipients.
 In order to contact other runtimes and deliver messages to them,
-their IP addresses need to be known.
-This is achieved by maintaining a file with a runtime's IP address in the same directory as the
-runtime.
+their network endpoint (IP address and UDP port) needs to be known.
+This is achieved by maintaining a file with a runtime's endpoint address in the same directory as
+the runtime.
 The runtime is granted write permissions on the file,
 and it is updated by \texttt{bttp} when it begins listening on a new endpoint.
+The port a \texttt{bttp} server uses to listen for unicast connections is uniformly
+randomly selected from the set of ports in the dynamic range (49152-65535) which are unused on the
+server's host.
+Use of a random port allows many different \texttt{bttp} servers to share a single IP address
+and makes Blocktree more resistent to censorship.
 The services which are allowed to be registered in a given runtime are specified in the runtime's
 file.
 The runtime reads this list and uses it to deny service registrations for unauthorized services.
-The list is also read by other runtime's when they are searching a directory for service providers.
+The list is also read by other runtime's when they're searching for service providers.
 
 % The sector and filesystem service.
 The filesystem is itself implemented as a service.
@@ -396,11 +401,9 @@ It stores sector data in the local filesystem of each computer on which it is re
 The details of how this is accomplished are deferred to the next section.
 
 % Runtime queries.
-While it is possible to resolve runtime paths to IP addresses when the filesystem is available,
-a different mechanism is needed to allow the filesystem and sector services to discover service
-providers.
-To facilitate this,
-runtimes are able to query one another to learn about other runtimes.
+While it is possible to resolve runtime paths to network endpoints when the filesystem is available,
+another mechanism is needed to allow the filesystem service providers to be discovered.
+This is accomplished by allowing runtimes to query one another to learn of other runtimes.
 Because queries are intended to facilitate message delivery,
 the query fields and their meanings mirror those used for addressing messages:
 \begin{enumerate}
@@ -416,16 +419,16 @@ As long as at least one other runtime is known,
 a query can be issued to learn of more runtimes.
 A runtime which receives a query may not be able to answer it directly.
 If it cannot,
-it returns the IP address of the next runtime to which the query should be sent.
+it returns the endpoint of the next runtime to which the query should be sent.
 
 % Bootstrap discovery methods.
 In order to bootstrap the discovery processes,
 another mechanism is needed to find the first peer to query.
 There were several possibilities explored for doing this.
-One way is to use a blockchain to store the IP addresses of the runtimes hosting the sector service
+One way is to use a blockchain to store the endpoints of the runtimes hosting the filesystem service
 in the root directory.
-As long as these runtimes could be located,
-then all others could be found using the filesystem.
+As long as these runtimes can be located,
+then all others can be found using the filesystem.
 This idea may be worth revisiting in the future,
 but the author wanted to avoid the complexity of implementing a new proof of work blockchain.
 Instead, two independent mechanisms are used,
@@ -435,13 +438,16 @@ their paths.
 
 % Searching DNS for root principals.
 When the path to a runtime is known,
-DNS is used to resolve a fully qualified domain name
-(FQDN) derived from the root principal's identifier in this path.
-This FQDN is expected to resolve to the public IP addresses of the runtimes hosting the
-sector service in the root directory of the root principal.
-Each process is configured with a search domain which is used as a suffix of the FQDN.
-The leading labels in the FQDN are computed by base32 encoding a hash of the root
-principal's public key.
+DNS is used to resolve SRV records using a fully qualified domain name
+(FQDN) derived from the path's root principal identifier.
+The SRV records are resolved using the name \texttt{\_bttp.\_udp.<FQDN>},
+where \texttt{<FQDN>} is the FQDN derived from the root principal's identifier.
+One SRV record may be created for each of the filesystem service providers in the root
+directory.
+Each record contains the UDP port and hostname where a runtime is listening.
+Every runtime is configured with a search domain that is used as a suffix in the FQDN.
+The leading labels in the FQDN are computed by base32 encoding the binary representation of the
+root principal's identifier.
 If the encoded string is longer than 63 bytes (the limit for each label in a hostname),
 it is separated into the fewest number of labels possible,
 working from left to right along the string.
@@ -450,7 +456,7 @@ This method has the advantages of being simple to implement
 and allowing runtimes to discover each other over the internet.
 Implementing this system would be facilitated by hosting DNS servers in actors in the same
 runtimes as the root sector service providers.
-Then, A or AAAA records could be served which point to these runtimes.
+Then, records could be dynamically created which point to these runtimes.
 These runtimes would also need to be configured with static IP addresses,
 and the NS records for the search domain would need to point to them.
 Of course it is also possible to build such a system without hosting DNS inside of Blocktree.
@@ -458,7 +464,8 @@ The downside of using DNS is that it couples Blocktree with a centralized,
 albeit distributed, system.
 
 % Using link-local multicast datagrams to find runtimes.
-Because this mechanism requires knowledge of the root principal of a domain to perform discovery,
+Because the previous mechanism requires knowledge of the root principal of a domain to perform
+discovery,
 it will not work if a runtime is first starting up with no credentials and so does not know its
 own root principal.
 This runtime needs a way to discover other runtimes so it can connect to the filesystem and sector
@@ -471,7 +478,7 @@ if the IPv4 or IPv6 networking stack is available, respectively.
 If the host is attached to a dual-stack network,
 the server listens on both addresses.
 When a runtime is attempting to discover other runtimes,
-it sends out datagrams to these IP addresses.
+it sends out datagrams to these endpoints.
 Each \texttt{bttp} server replies with its unicast address and filesystem path
 (as specified in its credentials).
 If the server is available at both IPv4 and IPv6 unicast addresses,
@@ -482,8 +489,8 @@ Once a client has discovered the \texttt{bttp} servers on its network,
 it can route messages to them,
 such as the provisioning requests which are used to obtain new credentials.
 Provisioning is described in the Cryptography section.
-Note that port 50142 is in the dynamic range, as specified by RFC 6335,
-so it does not need to registered with the Internet Assigned Names and Numbers (IANA) corporation.
+Note that port 50142 is in the dynamic range,
+so it does not need to registered with the Internet Assigned Names and Numbers Authority (IANA).
 Both addresses 224.0.0.142 and FE02::142 are currently unassigned.
 but they will need to be registered with IANA if Blocktree is widely adopted.