Flow Control------------Cockpit's protocol passes messages on reliable, ordered underlyingtransports (eg: WebSockets, HTTP responses, stdio) between multiplepeers, arranged in in a non-rooted tree graph.Cockpit's flow control is not about replaying messages, but avoidingflooding any peer by sending messages along any link in the graphtoo rapidly.Cockpit's flow control operates at the level of channels in the protocol(described in doc/protocol.md). A simple blocking of any peer's message inputwould block all channels, and not have the desired effect of slowingdown a certain channel which is flooding communication.Therefore we use a windowing flow control protocol. It is based aroundper-channel "ping" control messages. In the Cockpit protocol "ping"messages in a channel are responded to by specific leaves of the graph.They are replied to with a "pong" containing otherwise identical content.Other "ping" messages are used as keep alives, but these are beyond thescope of this description.Each channel leaf that participates in flow control sends "ping"messages with a sequence number, and waits to see the corresponding"pong" message with the same sequence and channel number. By checkingthe "ping" sequence numbers responded to, a channel can slow input and/ortransmission to wait for the opposite leaf to catch up.Sadly this is not enough. The leaves in of Cockpit's tree often do notconsume data themselves, but pass it on to other sockets, streams, filesand so on.Various leaves monitor their output edge queues and hold back respondingto "ping" messages if their output edge queue is too full. This is doneby use of "pressure" signals on the output queue to indicate when pressureis high or low.This results in flow control that achieves its intent, but does notmake guarantees. In addition only some channels and leaves implement flowcontrol at this point:* cockpit.js: Responds to "ping" messages indicating that a givensequence has reached the browser.* CockpitChannel: Sends sequence pings, every so often in the channel.Is responsible for responding to channel pings, and holding backresponses to pings if a related queue has output "pressure".Slows down an input pipe via a "pressure" signal when too manysequences are outstanding and have not been responded to.* CockpitStream: Can listen to "pressure" signals and pause reading itsinput stream. Can generate "pressure" signals when its output queueis too full.* CockpitPipe: Can listen to "pressure" signals and pause reading itsinput file descriptor. Can generate "pressure" signals when itsoutput queue is too full.* CockpitWebResponse: Can generate "pressure" signals when its outputqueue is too full.* WebSocketConnection: Can listen to "pressure" signals and pause acceptingincoming web socket messages. Can generate "pressure" signals when itsoutput queue is too full.* CockpitHttpStream: Uses CockpitStream and CockpitChannel together toimplement flow control on a HTTP client connection.* CockpitFsRead: Listens to "pressure" signals from the CockpitChannelto tell it to pause reading a file.