Merge pull request #91 from yrashk/fix-4-heading

Problem: Wikidot ++++ heading was still used

13/README.md

@@ -39,15 +39,15 @@ ZMTP consists of these layers:
 
 ### The Framing Layer
 
-++++ Preamble
+#### Preamble
 
 The framing layer underlies everything in ZMTP. The basic transport layer (e.g. provided by TCP) is a stream. ZMTP's framing layer turns that into a series of frames, in either direction. Frames are length-specified, so that peers can safely reject frames that are oversized. ZMTP's framing design is optimized for bandwidth and performance.
 
 Framing is used to create structured messages, rather than to break large messages into fragments. ZMTP assumes that peers will read and process all frames of a message, or none at all. Framing is particularly used to separate message content from message address envelopes (see the Content Layer).
 
 The framing layer is consistent no matter what work is happening on the connection. That is, it can be fully interpreted from the information sent on the wire.
 
-++++ Specification
+#### Specification
 
 A ZMTP **message** consists of 1 or more frames.
 
@@ -103,11 +103,11 @@ The following diagram shows the layout of a frame with length of 255 or more oct
 
 ### The Connection Layer
 
-++++ Preamble
+#### Preamble
 
 The connection layer provides a way for peers to identify each other at TCP connection time. A ZMTP connection is equivalent to a TCP connection. If peers disconnect and reconnect, this acts as two separate ZMTP connections.
 
-++++ Specification
+#### Specification
 
 A ZMTP connection is bidirectional and asynchronous. That is, either peer MAY send a message to the other peer at any time.
 
@@ -131,7 +131,7 @@ The flags octet (idflags) of an identity frame SHALL not be validated and SHOULD
 
 ### The Content Layer
 
-++++ Preamble
+#### Preamble
 
 The format and semantics of the ZMTP content messages sent across a connection depend on the **content type** of that connection direction, which is not specified in the protocol but must be assumed by both peers.
 
@@ -141,7 +141,7 @@ The following ABNF grammar defines ZMTP content:
 content     = *broadcast / *addressed / *neutral
 ```
 
-++++ Broadcast Content
+#### Broadcast Content
 
 **Broadcast content** is used between publishers and subscribers. A publisher SHALL send broadcast content. A subscriber SHALL NOT send any content.
 
@@ -153,7 +153,7 @@ broadcast   = message
 
 The recipient MAY filter messages. Any matching mechanism may be used (prefix, wildcard, regexp). ZMTP does not standardize this, though the current ZeroMQ implementation uses a prefix match.
 
-++++ Addressed Content
+#### Addressed Content
 
 **Addressed content** is used between peers in a request-reply chain. Any peer MAY send addressed content to any other peer in a request-reply chain.
 
@@ -173,7 +173,7 @@ The envelope SHOULD be used by peers in the following fashion:
 
 In this way, a chain of peers can push addresses onto the envelope as they forward requests, and pop addresses off the envelope to route replies back.
 
-++++ Neutral Content
+#### Neutral Content
 
 **Neutral content** is used between peers that do not require routing. Either peer MAY send neutral content to the other peer though specific peer implementations MAY ignore content coming from their peers.
 

14/README.md

@@ -40,7 +40,7 @@ Peers exchange messages. Each message has a command, extensible supplementary in
 
 Managers don't know their workers, they start by binding a socket and waiting for incoming messages.  Workers know their managers (endpoints, etc.), they start by connecting to each manager and initiating message exchange.
 
-++++ Scheme
+#### Scheme
 
 ```
  W               M
@@ -53,7 +53,7 @@ Managers don't know their workers, they start by binding a socket and waiting fo
    --- DONE  -->   Job is done
 ```
 
-++++ Description
+#### Description
 1. To get a job, worker sends a READY command to all his managers.
 2. Manager receives READY, and remembers an available worker (routing path to worker) until a job is available. If another READY message is received with routing path that is already remembered, the message is ignored.
 3. When a job is available, manager sends WAKE to all corresponding workers (correspondance is defined by custom load-balancing solutions, or it may be "any worker" in the simplest case).

18/README.md

@@ -174,7 +174,7 @@ A **DISCONNECT** command consists of a multipart message of 2 frames, formatted
 * Frame 0: "MDPW02" (six bytes, representing MDP/Worker v0.2)
 * Frame 1: 0x06 (one byte, representing DISCONNECT)
 
-++++ Opening and Closing a Connection
+#### Opening and Closing a Connection
 
 * The worker is responsible for opening and closing a logical connection. One worker MUST connect to exactly one broker using a single ØMQ DEALER socket.
 
@@ -192,15 +192,15 @@ A **DISCONNECT** command consists of a multipart message of 2 frames, formatted
 
 * When the worker receives DISCONNECT it must send no further commands to the broker; it MUST close its socket, and reconnect to the broker on a new socket. This mechanism allows workers to re-register after a broker failure and recovery.
 
-++++ Request and Reply Processing
+#### Request and Reply Processing
 
 * The worker SHALL send zero or more PARTIAL commands for a single REQUEST, followed by exactly one FINAL command.
 
 * The REQUEST, PARTIAL and FINAL commands SHALL contain precisely one client address frame. This frame MUST be followed by an empty (zero sized) frame.
 
 * The address of each directly connected client is prepended by the ROUTER socket to all request messages coming from clients. That ROUTER socket also expects a client address to be prepended to each reply message sent to a client.
 
-++++ Heartbeating
+#### Heartbeating
 
 * HEARTBEAT commands are valid at any time, after a READY command.
 

19/README.md

@@ -118,47 +118,47 @@ S:RTFM          = signature %x81 reason
 
 ### Interconnection Model
 
-++++ ZeroMQ Socket Types
+#### ZeroMQ Socket Types
 
 The server SHALL create a ROUTER socket and SHOULD bind it to port 5670, which is the registered Internet Assigned Numbers Authority (IANA) port for FILEMQ. The server MAY bind its ROUTER socket to other ports in the ephemeral port range (%C000x - %FFFFx). The client SHALL create a DEALER socket and connect it to the server ROUTER host and port.
 
 Note that the ROUTER socket provides the caller with the connection identity of the sender for any message received on the socket, as an identity frame that precedes other frames in the message.
 
-++++ Protocol Signature
+#### Protocol Signature
 
 Every ZeroMQ message SHALL start with the FILEMQ protocol signature, %xAA %xA3. The server and client SHALL silently discard any message received that does not start with these two octets.
 
 This mechanism is designed particularly for servers that bind to ephemeral ports which may have been previously used by other protocols, and to which there are still peers attempting to connect. It is also a general fail-fast mechanism to detect ill-formed messages.
 
-++++ Connection State
+#### Connection State
 
 The server SHALL reply to an unexpected command with a RTFM command. The client SHALL respond to an RTFM command by closing its DEALER connection and starting a new connection.
 
 ### FILEMQ Commands
 
-++++ The OHAI Command
+#### The OHAI Command
 
 The client SHALL start a new connection by sending the OHAI command to the server. This command identifies the protocol and version. This is designed to allow version detection.
 
 If the server does not support the request protocol version it SHALL reply with a RTFM command. The client MAY try again with a lower protocol version.
 
 If the server accepts the OHAI command it SHALL reply with either a OHAI-OK command or, if authentication is required, an ORLY command.
 
-++++ The ORLY Command
+#### The ORLY Command
 
 When a client requests access, the server MAY reply with an ORLY command to initiate a Simple Authentication and Security Layer (SASL) challenge and response exchange. The server SHALL provide a list of mechanisms that it accepts, and a frame of binary data containing a challenge.
 
-++++ The YARLY Command
+#### The YARLY Command
 
 The client SHOULD respond to an ORLY command with a YARLY command that has calculated response data. Note that the SASL challenge/response model uses external SASL libraries that process the challenge data and return suitable response data.
 
 The client or server MUST at least support the SASL "PLAIN" mechanism.
 
-++++ The OHAI-OK Command
+#### The OHAI-OK Command
 
 When the server grants the client access after an OHAI or YARL command, it SHALL reply with an OHAI-OK command. If the server does not grant access it SHALL reply with a SRSLY command.
 
-++++ The ICANHAZ Command
+#### The ICANHAZ Command
 
 The client MAY subscribe to any number of virtual paths by sending ICANHAZ commands to the server. The client MAY specify a full path, or it MAY specify a partial path, which is used as a prefix match. Paths MUST start with "/", thus the path "/" subscribes to *everything*.
 
@@ -170,43 +170,43 @@ The 'options' field provides additional information to the server. The server SH
 
 When the client specifies the RESYNC option, the 'cache' dictionary field tells the server which files the client already has. Each entry in the 'cache' dictionary is a "filename=digest" key/value pair where the digest SHALL be a SHA-1 digest in printable hexadecimal format. If the filename starts with '/' then it SHOULD start with the path, otherwise the server MUST ignore it. If the filename does not start with '/' then the server SHALL treat it as relative to the path.
 
-++++ The ICANHAZ-OK Command
+#### The ICANHAZ-OK Command
 
 When a server accepts a subscription it MUST reply with an ICANHAZ-OK command. If the server refuses a subscription it SHALL reply with a SRSLY command, and discard any further commands from this client.
 
-++++ The NOM Command
+#### The NOM Command
 
 The client MUST initiate the transfer of data by sending credit to the server. The server SHALL only send as much data to the client as it has credit for. The credit is an amount in bytes that corresponds to actual file content (but not bytes used by commands themselves).
 
 The client MAY sent NOM commands at any point after it has received an OHAI-OK from the server. The server SHALL not respond directly to NOM commands.
 
-++++ The CHEEZBURGER Command
+#### The CHEEZBURGER Command
 
 The server SHALL send file content to the client using CHEEZBURGER commands. Each CHEEZBURGER command shall deliver a chunk of file data starting at a specific offset. The server MUST send the content of a single file as consecutive chunks and clients MAY depend on this behavior.
 
 The headers field is reserved for future use.
 
-++++ The HUGZ Command
+#### The HUGZ Command
 
 The server or client MAY sent heartbeat commands at any point after the server has sent OHAI-OK to the client, which has received it.
 
 The HUGZ command acts as a heartbeat, indicating that the peer is alive. The server and client SHALL treat *any* command from a peer as a sign that the peer is alive.
 
 A peer may thus choose to only send HUGZ to another peer when it is not sending any other traffic to that peer.
 
-++++ The HUGZ-OK Command
+#### The HUGZ-OK Command
 
 A peer SHALL respond to a HUGZ command with a HUGZ-OK command. This allows one peer to be responsible for all heartbeating.
 
-++++ The KTHXBAI Command
+#### The KTHXBAI Command
 
 The client MAY end a connection by sending the KTHXBAI command to the server. The server SHALL not respond to this command.
 
-++++ The SRSLY Command
+#### The SRSLY Command
 
 The server SHALL respond to any failed attempt to access a resource on the server with a SRSLY command. This includes failed authentication and failed subscriptions. When a client receives a SRSLY command it SHOULD close the connection and if needed, reconnect with new authentication credentials.
 
-++++ The RTFM Command
+#### The RTFM Command
 
 The server SHALL respond to an invalid command by sending RTFM. Note that the server SHALL not send RTFM to clients which send an invalid protocol signature. When a client receives a RTFM command it SHOULD close the connection and not reconnect.
 

20/README.md

@@ -133,7 +133,7 @@ R:PING-OK       = signature %07 sequence
 
 ### ZRE Commands
 
-++++ The HELLO Command
+#### The HELLO Command
 
 Each node SHALL start a dialog by sending HELLO as the first command on an connection to a peer.
 
@@ -151,31 +151,31 @@ If the recipient has not already connected to this peer it SHALL create a ZeroMQ
 
 The "group status sequence" is a one-octet number that is incremented each time the peer joins or leaves a group. Each peer MAY use this to assert the accuracy of its own group management information.
 
-++++ The WHISPER Command
+#### The WHISPER Command
 
 When a node wishes to send a message to a single peer it SHALL use the WHISPER command. The WHISPER command contains a single field, which is the message content defined as one 0MQ frame. ZRE does not support multi-frame message contents.
 
-++++ The SHOUT Command
+#### The SHOUT Command
 
 When a node wishes to send a message to a set of nodes participating in a group it SHALL use the SHOUT command. The SHOUT command contains two fields: the name of the group, and the the message content defined as one 0MQ frame.
 
 Note that messages are sent via ZeroMQ over TCP, so the SHOUT command is unicast to each peer that should receive it. ZRE does not provide any UDP multicast functionality.
 
-++++ The JOIN Command
+#### The JOIN Command
 
 When a node joins a group it SHALL broadcast a JOIN command to all its peers. The JOIN command has two fields: the name of the group to join, and the group status sequence number *after* joining the group. Group names are case sensitive.
 
-++++ The LEAVE Command
+#### The LEAVE Command
 
 When a node leaves a group it SHALL broadcast a LEAVE command to all its peers. The LEAVE command has two fields: the name of the group to leave, and the group status sequence number *after* leaving the group.
 
-++++ The PING Command
+#### The PING Command
 
 A node SHOULD send a PING command to any peer that it has not received a UDP beacon from within a certain time (typically five seconds). Note that UDP traffic may be dropped on a network that is heavily saturated. If a node receives no reply to a PING command, and no other traffic from a peer within a somewhat longer time (typically 30 seconds), it SHOULD treat that peer as dead.
 
 Note that PING commands SHOULD be used only in targeted cases where a peer is otherwise silent. Otherwise, the cost of PING commands will rise exponentially with the number of peers connected, and can degrade network performance.
 
-++++ The PING-OK Command
+#### The PING-OK Command
 
 When a node receives a PING command it SHALL reply with a PING-OK command.
 

21/README.md

@@ -363,11 +363,11 @@ Property names SHALL follow the General Style for Naming. Property names SHOULD
 
 ### General Rules
 
-++++ Argument Names
+#### Argument Names
 
 Argument names SHALL be consistent with property names.
 
-++++ Return Values
+#### Return Values
 
 Success/failure SHALL be indicated by returning an int, with values zero or -1 respectively.
 
@@ -401,7 +401,7 @@ myp_myclass_test (int verbose)
 
 ### Stateful Classes
 
-++++ The Constructor Method
+#### The Constructor Method
 
 The constructor SHALL take this general form:
 
@@ -426,7 +426,7 @@ myp_myclass_new (<arguments>)
 
 * The constructor SHALL return either a new instance reference, or null, if construction failed.
 
-++++ The Destructor Method
+#### The Destructor Method
 
 The destructor SHALL take this general form:
 
@@ -451,7 +451,7 @@ myp_myclass_destroy (myp_myclass_t **self_p)
 * The destructor SHALL be idempotent, i.e., can be called safely on the same instance reference more than once.
 * The destructor SHALL safely free properties and child class instances that are not null.
 
-++++ The Duplicator Method
+#### The Duplicator Method
 
 The class MAY offer a duplicator method which creates a full copy of an instance; if it offers such semantics, the method MUST be called <tt>myp_myclass_dup ()</tt> and take this general form:
 
@@ -480,7 +480,7 @@ myp_myclass_dup (myp_myclass_t *self)
 
 * A duplicated instance SHALL be entirely independent of the original instance (i.e. all properties SHALL also be duplicated).
 
-++++ List Navigation Methods
+#### List Navigation Methods
 
 A class MAY act as a list container for other items, which may be child class instances, strings, memory blocks, or other structures.
 
@@ -522,7 +522,7 @@ myp_myclass_next (myp_myclass_t *self)
 
 * If the class maintains multiple lists, it SHALL create unique method names for each list by adding a list name, e.g., <tt>myp_myclass_myitem_first ()</tt>.
 
-++++ Accessor Methods
+#### Accessor Methods
 
 The class MAY expose instance properties via its API, in which case this SHALL be done through accessor methods.
 
@@ -552,11 +552,11 @@ myp_myclass_set_myprop (myp_myclass_t *self, <type> myprop)
 
 * Properties exposed by accessor methods MAY not actually exist as such in the instance; they may be calculated rather than simply copied to/from the instance structure.
 
-++++ Formatted String Arguments
+#### Formatted String Arguments
 
 When a method (such as an accessor method) accepts a string argument as primary argument, it SHOULD use a variable argument list and perform vsnprintf formatting on that string argument.
 
-++++ General Methods
+#### General Methods
 
 The class MAY offer any number of other methods that operate on the instance. These methods shall take this general form:
 
@@ -565,7 +565,7 @@ The class MAY offer any number of other methods that operate on the instance. Th
 
 A method may take ownership of an object instance and then act as a destructor of the object instance at some later stage. In that case the method SHALL use the same style as the destructor.
 
-++++ Return Values
+#### Return Values
 
 Methods SHOULD use one of the following patterns for returning values to the caller:
 
@@ -981,4 +981,3 @@ The use of opaque data structures that are accessed via references is thread saf
 * The heavy reliance on heap memory makes CLASS unsuitable for embedded systems where all memory use must be static.
 
 * In most CLASS applications it is difficult to handle an "out of memory" error in any way except to abort.
-

23/README.md

@@ -200,7 +200,7 @@ The flags field consists of a single octet containing various control flags. Bit
 
 * Bit 0 (MORE): *More frames to follow*. A value of 0 indicates that there are no more frames to follow. A value of 1 indicates that more frames will follow. This bit SHALL be zero on command frames.
 
-++++ Commands
+#### Commands
 
 Commands are used by the ZMTP implementation and not generally visible to the application except in some cases. Commands always consist of one frame, containing a printable command name, a null octet separator, and data.
 
@@ -210,7 +210,7 @@ These are the commands that this specification defines:
 
 ZMTP supports extensible security mechanisms and these may define their own commands. Security mechanisms MAY use any command names they need to.
 
-++++ Messages
+#### Messages
 
 Messages carry application data and are not generally created, modified, or filtered by the ZMTP implementation except in some cases. Messages consist of one or more frames and an implementation SHALL always send and deliver messages atomically, that is, all the frames of a message, or none of them.
 
@@ -268,7 +268,7 @@ The implementation MAY provide other metadata properties such as implementation
 
 Metadata names starting with "X-" SHALL be reserved for application use.
 
-++++ The Socket-Type Property
+#### The Socket-Type Property
 
 The Socket-Type announces the ZeroMQ socket type of the sending peer. The Socket-Type SHALL match this grammar:
 
@@ -312,7 +312,7 @@ PAIR   |     |     |        |        |     |      |     |      |      |      |
 
 When a peer validates the socket type, it SHOULD handle errors by returning an ERROR command, and then disconnecting the peer.
 
-++++ The Identity Property
+#### The Identity Property
 
 A REQ, DEALER, or ROUTER peer connecting to a ROUTER MAY announce its identity, which is used as an addressing mechanism by the ROUTER socket. For all other socket types, the Identity property shall be ignored.