RFC: The primary purpose of fragmentation is to allow sending a message that is of unknown | size when the message is started without having to buffer that message. Hu: In the initial implementation of Flare, with only text.based-messages, fragmentation is not necessary, because messages will be sent, char.by-char, and each message, at most, will consist of only 1 char. However, in future versions #, we may allow copy–paste into the form, which would introduce the possibility of a bulk | message, such as a link, and it’s possible that Web-Sockets will also be our protocol for delivering images. RFC: If messages couldn’t be fragmented, then an endpoint would have to buffer the entire | message so its length could be counted before the first | byte is sent. With fragmentation, a server or intermediary may choose a reasonable size buffer and, when the buffer is full, write a fragment to the network. Hu: It’s important to distinguish between the domain of Web.Sockets-protocol and cond.oriented-prog<WP.MIC-H2S58>; whereas the logic of fragmentation continuity is built-in to Web.Sockets-prot, it is not prescriptive about 1) whether messages are fragmented or 2) the size of fragments. These are determined by conditional–code, written at the behest # of the product owner, in the language of the server–side, totally independently of consideration of Web-Sockets.
- Server.side-code has established a conditional function that counts the length of a composing message #
- When a length of 64 is reached, the code automatically terminates the string, analogous to the action of a protease at the C-terminus.
- A fragment, comprised of bits corresponding to # 1-64, is sent.
- The next fragment will be bits corresponding to 65-128, at most #
The entire logic here # can be written without Web-Sockets; a server can decide to send things this way just as well # in HTTP. Where Web-Sockets comes in, at least in fragmentation, is that it requires specific encoding | patterns, for specifying whether a particular fragment is a stand-alone | message or chained to another | fragment.
H3S1: Rules of fragmentation:
H4S1: RFC: An unfragmented message consists of a single frame with the FIN bit set (Section 5.2)<WP.MIC-H2S and an opcode other than 0.