Changes

diff --git a/version2/doc/iotcloud.tex b/version2/doc/iotcloud.tex
index b63cbb236b7a9585c2c7b93efee47cf7bee725ac..147aab06153560b6357c9d61a52a287ede82565c 100644 (file)
--- a/version2/doc/iotcloud.tex
+++ b/version2/doc/iotcloud.tex
@@ -147,6 +147,11 @@ The different types of record payloads are:
             \item Contain the server sequence number of the record that was deleted.\r
             \item Generated when a device deletes a record.\r
         \end{itemize}\r
+    \item New Key notification\r
+        \begin{itemize}\r
+            \item Contains the name of a new key and the machine ID of the machine that is to arbitrate\r
+            \item Generated when a device generates a new (never used) key-value pair.\r
+        \end{itemize}\r
 \end{itemize}\r
 \r
 \subsection{\textbf{Pulling the data structure}}\r
@@ -196,10 +201,20 @@ When deciding which records to delete the following is to be done:
 Note this makes that size of the data structure be bounded:\r
 If there are $n$ devices and the data structure has a minimum size of $m$.  Then the max size of the data structure is given by $m + n -1$ for the case when all the devices make an update at the same time.   \r
 \r
+\subsection{\textbf{Reading a key-value pair}}\r
+When getting a key-value pair the following is done:\r
+\begin{enumerate}\r
+    \item A device pulls the latest version of the data structure.  If the device cannot pull the latest version because of network connectivity or some other issues then that device will just work using the local copy of the data structure it has.\r
+    \item Check the pulled data structure for any malicious activity (as stated in a section below) if not done already.\r
+    \item Find the transaction with the largest server sequence number that contains the key-value pair of interest (this is the latest value).\r
+\end{enumerate}\r
+\r
 \subsection{\textbf{Rescuing Transactions, Commits, Aborts, Ext}}\r
 Data should be proactively rescued from the "oldest" records currently in the data structure.  Unused space in new records should be used to rescue data from old records so that when it comes time to delete the old records, there are no live pieces of data that need to be rescued.  When a piece of data is rescued, it is rescued with its vector clock as well (so that the time of that data can be saved).\\\r
 \r
-When rescuing transactions and commits: only keep the key-value pair sets that do not have a newer key-value pair set (no other transaction/commits sets that key-value pair later in the future).  This means that transactions/commits can shrink in size.\r
+When rescuing transactions and commits: only keep the key-value pair sets that do not have a newer key-value pair set (no other transaction/commits sets that key-value pair later in the future).  This means that transactions/commits can shrink in size.\\\r
+\r
+When rescuing Key Value notifications: save the vector clock and the server sequence number of the notification in the rescued data.\r
 \r
 When deciding which data to rescue the following is to be done:\r
 \begin{enumerate}\r
@@ -226,7 +241,7 @@ The arbitrator can:
     \item Send Commits\r
     \item Send Aborts\r
 \end{enumerate}\r
-    \r
+\r
 \subsubsection{\textbf{Commits}}\r
 Commits have the following properties\r
 \begin{itemize}\r
@@ -242,9 +257,15 @@ Commits have the following properties
 \begin{itemize}\r
     \item Aborts are used to show which transactions have been aborted based on the arbitrators decision.\r
     \item Aborts are considered live until an abort acknowledgement is presented.\r
-    \r
 \end{itemize}\r
  \r
+\subsection{\textbf{Setting Up New Keys (Choosing the Arbitrator)}}\r
+Setting up new keys is done as follows:\r
+\begin{enumerate}\r
+    \item Device wishes to generate new key\r
+    \item Device inserts a New Key notification into the data structure.\r
+\end{enumerate}\r
+In the case where multiple devices are creating the same key, the key with the smallest vector clock is the only valid one.  In the case of a concurrent vector clock, the smallest server sequence number notification is the valid one.\r
     \r
 \subsection{\textbf{Live Status}}\r
 Live Status of entries:\r
@@ -283,10 +304,14 @@ Live Status of entries:
             \item Is dead if it is invalid (contains keys-values for multiple arbitrators)\r
             \item Live until a commit or abort notification for this transaction is generated.\r
         \end{itemize}\r
+        \r
+    \item New Key notification\r
+        \begin{itemize}\r
+            \item Is dead if there exists a New Key notification that has a server sequence number that is smaller and the same key name.\r
+        \end{itemize}\r
     \r
 \end{enumerate}\r
 \r
-\r
 \section{\textbf{Server Approach}}\r
 \r
 The servers view of the system is in terms of data slots where each data slot holds a single record, has a monotonically increasing number associated with it (server sequence number) for the record that currently is present in that data slot and can be set or deleted.  A server may have a finite amount of memory which it can partition into slots, reusing memory that newly deleted slots used to occupy.\r
@@ -331,7 +356,6 @@ In this case the server will delete the data in the slot that has the server seq
 \r
 \end{itemize}\r
     \r
-\r
 \section{System Correctness}\r
 \r
 \end{document}
\ No newline at end of file