doc/iotcloud.tex

   1 \documentclass[11pt]{article}\r
   2 \newcommand{\tuple}[1]{\ensuremath \langle #1 \rangle}\r
   3 \usepackage{color}\r
   4 \usepackage{amsthm}\r
   5 \usepackage{algpseudocode}\r
   6 \newtheorem{theorem}{Theorem}\r
   7 \newtheorem{defn}{Definition}\r
   8 \newcommand{\note}[1]{{\color{red} \bf [[#1]]}}\r
   9 \r
  10 \begin{document}\r
  11 \section{Approach}\r
  12 \r
  13 \subsection{Keys}\r
  14 \r
  15 Each device has: user id + password\r
  16 \r
  17 Server login is:\r
  18 hash1(user id), hash1(password)\r
  19 \r
  20 Symmetric Crypto keys is:\r
  21 hash2(user id | password)\r
  22 \r
  23 Server has finite length queue of entries + max\_entry\_identifier +\r
  24 server login key\r
  25 \r
  26 \subsection{Entry layout}\r
  27 Each entry has:\r
  28 \begin{enumerate}\r
  29 \item Sequence identifier\r
  30 \item Random IV (if needed by crypto algorithm)\r
  31 \item Encrypted payload\r
  32 \end{enumerate}\r
  33 \r
  34 Payload has:\r
  35 \begin{enumerate}\r
  36 \item Sequence identifier\r
  37 \item Machine id (most probably something like a 64-bit random number \r
  38 that is self-generated by client)\r
  39 \item HMAC of previous slot\r
  40 \item Data entries\r
  41 \item HMAC of current slot\r
  42 \end{enumerate}\r
  43 \r
  44 A data entry can be one of these:\r
  45 \begin{enumerate}\r
  46 \item All or part of a Key-value entry\r
  47 \item Slot sequence entry: Machine id + last message identifier \r
  48 \newline {The purpose of this is to keep the record of the last slot \r
  49 from a certain client if a client's update has to expunge that other \r
  50 client's last entry from the queue. This is kept in the slot until \r
  51 the entry owner inserts a newer update into the queue.}\r
  52 \item Queue state entry: Includes queue size \newline {The purpose \r
  53 of this is for the client to tell if the server lies about the number \r
  54 of slots in the queue, e.g. if there are 2 queue state entry in the queue, \r
  55 e.g. 50 and 70, the client knows that when it sees 50, it should expect \r
  56 at most 50 slots in the queue and after it sees 70, it should expect \r
  57 50 slots before that queue state entry slot 50 and at most 70 slots. \r
  58 The queue state entry slot 70 is counted as slot number 51 in the queue.}\r
  59 \end{enumerate}\r
  60 \r
  61 \subsection{Live status}\r
  62 \r
  63 Live status of entries:\r
  64 \begin{enumerate}\r
  65 \item Key-Value Entry is dead if either (a) there is a newer key-value pair or (b) it is incomplete.\r
  66         \r
  67 \item Slot sequence number (of either a message version data\r
  68 or user-level data) is dead if there is a newer slot from the same machine.\r
  69 \r
  70 \item Queue state entry is dead if there is a newer queue state entry.\r
  71 {In the case of queue state entries 50 and 70, this means that queue state \r
  72 entry 50 is dead and 70 is live. However, not until the number of slotes reaches \r
  73 70 that queue state entry 50 will be expunged from the queue.}\r
  74 \end{enumerate}\r
  75 \r
  76 When data is at the end of the queue ready to expunge, if:\r
  77 \begin{enumerate}\r
  78 \item The key-value entry is not dead, it must be reinserted at the\r
  79 beginning of the queue.\r
  80 \r
  81 \item If the slot sequence number is not dead, then a message sequence\r
  82 entry must be inserted.\r
  83 \r
  84 \item If the queue state entry is not dead, it must be reinserted at the\r
  85 beginning of the queue.\r
  86 \end{enumerate}\r
  87 \r
  88 \r
  89 \paragraph{Reads:}\r
  90 Client sends a sequence number.  Server replies with either: all data\r
  91 entries or all newer data entries.\r
  92 \r
  93 \paragraph{Writes:}\r
  94 Client sends slot, server verifies that sequence number is valid,\r
  95 checks entry hash, and replies with an accept message if all checks\r
  96 pass.  On success, client updates its sequence number.  On failure,\r
  97 server sends updates slots to client and client validates those slots.\r
  98 \r
  99 \paragraph{Local state on each client:}\r
 100 A list of machines and the corresponding latest sequence numbers.\r
 101 \r
 102 \paragraph{Validation procedure on client:}\r
 103 \begin{enumerate}\r
 104 \item Decrypt each new slot in order.\r
 105 \item For each slot:\r
 106     (a) check its HMAC, and\r
 107     (b) check that the previous entry HMAC field matches the previous\r
 108     entry.\r
 109 \item Check that the last message version for our machine matches our\r
 110 last message sent.\r
 111 \item For all other machines, check that the latest sequence number is\r
 112 at least as large (never goes backwards).\r
 113 \item That the queue has a current queue state entry.\r
 114 \item That the number of entries received is consistent with the size\r
 115 specified in the queue state entry.\r
 116 \end{enumerate}\r
 117 \r
 118 Key-value entries can span multiple slots.  They aren't valid until\r
 119 they are complete.\r
 120 \r
 121 \subsection{Resizing Queue}\r
 122 Client can make a request to resize the queue. This is done as a write that combines:\r
 123   (a) a slot with the message, and\r
 124         (b) a request to the server\r
 125 \r
 126 \subsection{Server Algorithm}\r
 127 \begin{algorithmic}[1]\r
 128 \Function{Server}{$m$,$max$,$s$,$Data*$}\r
 129 \textit{\r
 130 \newline{// m = client message (read/write/resize)}\r
 131 \newline{// max = maximum number of slots (input only for resize message)}\r
 132 \newline{// n = number of slots}\r
 133 \newline{// s = sequence number}\r
 134 \newline{// t = latest sequence number on server}\r
 135 \newline{// d = sequence number difference (1 by default)}\r
 136 \newline{// Data = array of slots written/read (input only for write)}\r
 137 \newline{// Q = queue of slots on server}\r
 138 \newline{// Resize() returns the old last slot in the queue}\r
 139 \newline{// Append() updates Q and latest s after appending the new slot}\r
 140 \newline{// Append() returns the latest Slot written with its correct s}\r
 141 }\r
 142 \If{$m = read$}\r
 143 \If{$s \in T = \{t_1, t_2, \dots, t_n\}$}\r
 144 \State $Data := \{Slot_{s}, Slot_{s+1}, \dots, Slot_{t_n}\} \forall Slot_i \in Q$\r
 145 \Else\r
 146 \State $Data := \emptyset$\r
 147 \EndIf\r
 148 \ElsIf{$m = write$}\r
 149 \If{$s = t_n + d$ \textbf{and} $n \leq max$ \textbf{and} $Data.length = 1$}\r
 150 \State $newSlot := Data[1]$\r
 151 \If{$n = max$}\r
 152 \State $DeleteFirst(Q)$\r
 153 \Else\r
 154 \State // $n < max$\r
 155 \State $n := n + 1$\r
 156 \EndIf\r
 157 \State $Data := Append(newSlot,Q)$\r
 158 \Else\r
 159 \State $Data := \emptyset$\r
 160 \EndIf\r
 161 \ElsIf{$m = resize$}\r
 162 \State $Data := Resize(max)$\r
 163 \EndIf\r
 164 \State \Return{$Data$}\r
 165 \EndFunction\r
 166 \end{algorithmic}\r
 167 \r
 168 \subsection{Formal Guarantees}\r
 169 \r
 170 \textit{To be completed ...}\r
 171 \r
 172 \begin{defn}[System Execution]\r
 173 Formalize a system execution as a sequence of slot updates...  There\r
 174 is a total order of all slot updates.\r
 175 \end{defn}\r
 176 \r
 177 \begin{defn}[Transitive Closure]\r
 178 Define transitive closure relation for slot updates...  There is an\r
 179 edge from a slot update to a slot receive event if the receive event\r
 180 reads from the update event.\r
 181 \end{defn}\r
 182 \r
 183 \begin{defn}[Suborder]\r
 184 Define suborder of total order.  It is a sequence of contiguous slots\r
 185 updates (as observed by a given device).\r
 186 \end{defn}\r
 187 \r
 188 \begin{defn}[Prefix of a suborder]\r
 189 Given a sub order $o=u_{i},u_{i+1},...,u_j, u_{j+i},..., u', ...$ and\r
 190 a slot update $u'$ in $o$, the prefix of $o$ is a sequence of all\r
 191 updates that occur before $u'$ and $u'$.\r
 192 \end{defn}\r
 193 \r
 194 \begin{defn}[Consistency between a suborder and a total order]\r
 195 A suborder $o$ is consistent with a total order $t$, if all updates in $o$ appear in $t$ and they appear in the same order.\r
 196 \end{defn}\r
 197 \r
 198 \begin{defn}[Consistency between suborders]\r
 199 Define notion of consistency between suborders...  Two suborders U,V\r
 200 are consistent if there exist a total order T such that both U and V\r
 201 are suborders of T.\r
 202 \end{defn}\r
 203 \r
 204 \begin{defn}[Error-free execution]\r
 205 Define error-free execution --- execution for which the client does\r
 206 not flag any errors...\r
 207 \end{defn}\r
 208 \r
 209 \begin{theorem} Error-free execution of algorithm ensures that the suborder\r
 210 for node n is consistent with the prefix suborder for all other nodes\r
 211 that are in the transitive closure.\r
 212 \end{theorem}\r
 213 \begin{proof}\r
 214 \textit{TODO}\r
 215 \end{proof}\r
 216 \r
 217 \begin{defn}[State of Data Structure]\r
 218 Define in terms of playing all updates sequentially onto local data\r
 219 structure.\r
 220 \end{defn}\r
 221 \r
 222 \begin{theorem}\r
 223 Algorithm gives consistent view of data structure.\r
 224 \end{theorem}\r
 225 \begin{proof}\r
 226 \textit{TODO}\r
 227 \end{proof}\r
 228 \r
 229 \subsection{Future Work}\r
 230 \paragraph{Support Messages}\r
 231   A message is dead once receiving machine sends an entry with a newer\r
 232   sequence identifier\r
 233 \r
 234 \paragraph{Persistent data structures}\r
 235         Root object w/ fields\r
 236         Other objects can be reachable from root\r
 237         Each object has its own entries\r
 238         Dead objects correspond to dead \r
 239 \r
 240 \paragraph{Multiple App Sharing}\r
 241 \r
 242 Idea is to separate subspace of entries...  Shared with other cloud...\r
 243 \end{document}\r