H2S79: RFC.6455-5.4: Fragmentation:


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 copypaste 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 conditionalcode, written at the behest # of the product owner, in the language of the serverside, totally independently of consideration of Web-Sockets.

Eg:

  1. Server.side-code has established a conditional function that counts the length of a composing message #
  2. When a length of 64 is reached, the code automatically terminates the string, analogous to the action of a protease at the C-terminus.
  3. A fragment, comprised of bits corresponding to # 1-64, is sent.
  4. 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.

// cont

References:

https://www.rfc-editor.org/rfc/rfc6455#section-5.4


Leave a Reply

Your email address will not be published. Required fields are marked *