Hu: What can this legacy-db # that is the epitome of static # possibly have to do with a fast, real-time, dynamic portal, that is epitomized by HTML.5-Web,Sockets? Lengstorf, Leggetter<pg-27, a-r>: Certain pieces of data—such as the names of rooms and the questions that have been asked—will need to be stored in a database for later retrieval: 1) The details of a room: Details such as room name and session information so the presenter can come back to the room at a later date for reference. 2) The questions asked in each room: This allows a new attendee to join late and not miss anything.
H3S1: The room’s address and schedule is static information<Turing!>
Hu: Real life analogies have always helped me, in building with Web.RTC/Sockets. The meeting contents are real-time, dynamic, and subject to change, but the duration of the meeting, when it starts, and where it is, is fixed, both before, and during, the meeting.
H3S2: Content becomes static after the instant of its transmission<Turing!>
Hu: The fact that content is streamed with low latency is independent from whether we want it to be stored, for later viewing, by either users in the room, or later users, to catch up. Ideally, the WebSockets write to server<Turing> is a single | request that handles both the streaming, and sending to MySQL-db, such that the 2 actions, do not have to be duplicated.
H4S1: The MySQL.Web-Sockets paradigm, in private-web:
X.ref-<WP,MIC.H2S70> In private-web, we can think of each interaction<Turing> as having 2 users, and 4 clients: 1a) my browser 1b) my computer, the server, for me 2a) your server 2b) your browser. Communication along this chain is non-transitory<Turing> and ordered, which means that 1a) can talk to 1b), but not the others; 1b) receives from 1a), and sends to 2a), or receives from 2a), and sends to 1a). Db-writes will occur, and can occur, any time 1b) and 2a) are crossed<Turing.good-gawd!>
H5S1: My writes to my server<Turing>
Hu: When I send a msg #, I would like it to be sent, both to you, and to my server. The send to my server, is for the purpose of entering my db, so that the message can be revisited later, by me, on my computer; that server path, also, ideally, is how the message goes to you, through a first socket:socket-connection<fbno>, with my own computer, and from my computer, to your computer. The message should not route through the database, to get to your computer, which means that it will need to fork; this is not the same as sending twice, and can be efficient:
H6S1: Ser.1-ser,2 is prioritized:
Hu: The order of operations # should be that comms between ser-1 and ser-2 are always prioritized over db-writes, since db-writes are for storing async-content, and in most cases, do not need to be immediately | reaccessed. Therefore, introducing a db-write, from server, will not slow down the real.time-aspect, whatsoever. Moreover, since $msg is stored as a variable, it will be passed | cleanly, first to the line that contains the socket-push to ser-2, then to the line that contains MySQL-UPDATE, with 0 redundancy<Turing>
H6S2: Each user maintains an independent-db:
Hu: In private-web, each user keeps his own db, so there will be 2 copies, of the same content. This is not | redundant, because evo-bio has already confirmed to us, that memory is personal, even though the experience was shared. As we continue to process memories, it transforms, such as via the establishing of additional connections, concretely here, attributes, updates, and further MySQL-actions, that I may want, to uniquely alter my db, that would distort your neural-architecture<Turing><#n.p-bio><fbno-conn>.
H7S1: Each user’s select comes from their db:
H5S2: Real.time-comms depends upon cli-1 to cl-2:
Hu: This explains why we need 3 web-sockets: 1) the browsers, cannot connect to each others, directly 2) every step, has to be at socket-speed, else bottleneck<Turing> 3) In this particular | architecture, there are 2 servers<legacy-righteous!>
<Lengstorf, Leggetter, a-r>: Each row is a particular piece of data. For instance, if the table were called rooms, each row would contain a room’s information such as its name, unique | identifier, and other related | data.
Post: Hu: [D, Wang<pg-6>]: Presently, and bear in mind, this diagram only shows half of the full picture, of a bidirectional cli-cli interaction, the bottleneck in web-communications is the half-duplex protocol between browser and web-server, or SER-1, in my diagram. Note, also, that back.end-server to back.end-server comms, is not specified<Turing>
References:
Realtime Web Apps by Lengstorf and Leggetter, via Apress.
Wang, Vanessa, et al. HTML5 WebSocket: Build Real-Time Applications w/ HTML5. Apress.