Fix formatting to remove (failed) bold and italics
Project: http://git-wip-us.apache.org/repos/asf/trafficserver/repo Commit: http://git-wip-us.apache.org/repos/asf/trafficserver/commit/afdfb419 Tree: http://git-wip-us.apache.org/repos/asf/trafficserver/tree/afdfb419 Diff: http://git-wip-us.apache.org/repos/asf/trafficserver/diff/afdfb419 Branch: refs/heads/master Commit: afdfb4195a6e1acd4e2766af06966f15c1b8743b Parents: 2198745 Author: Miles Libbey <[email protected]> Authored: Tue Apr 7 10:07:01 2015 -0700 Committer: Miles Libbey <[email protected]> Committed: Mon Jun 8 15:44:47 2015 -0700 ---------------------------------------------------------------------- doc/admin/faqs.en.rst | 2 +- doc/arch/cache/cache-arch.en.rst | 2 +- .../configuration/congestion.config.en.rst | 36 ++--- doc/reference/configuration/icp.config.en.rst | 16 +-- .../getting-started/naming-conventions.en.rst | 4 +- doc/sdk/new-protocol-plugins.en.rst | 138 +++++++++---------- 6 files changed, 99 insertions(+), 99 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/admin/faqs.en.rst ---------------------------------------------------------------------- diff --git a/doc/admin/faqs.en.rst b/doc/admin/faqs.en.rst index d6dd259..a3a5aaa 100644 --- a/doc/admin/faqs.en.rst +++ b/doc/admin/faqs.en.rst @@ -377,7 +377,7 @@ Traffic Line commands do not execute under the following conditions: .. XXX: this is wrong You should always start and stop Traffic Server with the - :program:`trafficserver start`` and :program:`trafficserver stop` commands to ensure + :program:`trafficserver start` and :program:`trafficserver stop` commands to ensure that all the processes start and stop correctly. For more information, refer to :ref:`getting-started`. http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/arch/cache/cache-arch.en.rst ---------------------------------------------------------------------- diff --git a/doc/arch/cache/cache-arch.en.rst b/doc/arch/cache/cache-arch.en.rst index fecd0fb..b870a88 100644 --- a/doc/arch/cache/cache-arch.en.rst +++ b/doc/arch/cache/cache-arch.en.rst @@ -535,7 +535,7 @@ extraneous bytes. The computation of the approximate size of the fragment is defined as:: - ( *size* + 1 ) * 2 ^ ( ``CACHE_BLOCK_SHIFT`` + 3 * *big* ) + ( *size* + 1 ) * 2 ^ ( CACHE_BLOCK_SHIFT + 3 * *big* ) Where ``CACHE_BLOCK_SHIFT`` is the bit width of the size of a basic cache block (9, corresponding to a sector size of 512). Therefore the value with http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/reference/configuration/congestion.config.en.rst ---------------------------------------------------------------------- diff --git a/doc/reference/configuration/congestion.config.en.rst b/doc/reference/configuration/congestion.config.en.rst index 26b3d88..143c46f 100644 --- a/doc/reference/configuration/congestion.config.en.rst +++ b/doc/reference/configuration/congestion.config.en.rst @@ -55,16 +55,16 @@ file. Traffic Server recognizes three space-delimited tags:: The following list shows possible primary destinations with allowed values. -*``dest_domain``* {#dest_domain} +``dest_domain`` A requested domain name. -*``dest_host``* {#dest_host} +``dest_host`` A requested hostname. -*``dest_ip``* {#dest_ip} +``dest_ip`` A requested IP address. -*``url_regex``* {#url_regex} +``url_regex`` A regular expression (regex) to be found in a URL. The secondary specifiers are optional in the congestion.config file. The @@ -72,72 +72,72 @@ following list shows possible secondary specifiers with allowed values. You can use more than one secondary specifier in a rule; however, you cannot repeat a secondary specifier. -*``port``* {#port} +``port`` A requested URL port or range of ports. -*``prefix``* {#prefix} +``prefix`` A prefix in the path part of a URL. The following list shows the possible tags and their allowed values. -*``max_connection_failures``* {#max_connection_failures} +``max_connection_failures`` Default: ``5`` The maximum number of connection failures allowed within the fail window described below before Traffic Server marks the origin server as congested. -*``fail_window``* {#fail_window} +``fail_window`` Default: ``120`` seconds. The time period during which the maximum number of connection failures can occur before Traffic Server marks the origin server as congested. -*``proxy_retry_interval``* {#proxy_retry_interval} +``proxy_retry_interval`` Default: ``10`` seconds. The number of seconds that Traffic Server waits before contacting a congested origin server again. -*``client_wait_interval``* {#client_wait_interval} +``client_wait_interval`` Default: ``300`` seconds. The number of seconds that the client is advised to wait before retrying the congested origin server. -*``wait_interval_alpha``* {#wait_interval_alpha} +``wait_interval_alpha`` Default: ``30`` seconds The upper limit for a random number that is added to the wait interval. -*``live_os_conn_timeout``* {#live_os_conn_timeout} +``live_os_conn_timeout`` Default: ``60`` seconds. The connection timeout to the live (uncongested) origin server. If a client stops a request before the timeout occurs, then Traffic Server does not record a connection failure. -*``live_os_conn_retries``* {#live_os_conn_retries} +``live_os_conn_retries`` Default: ``2`` The maximum number of retries allowed to the live (uncongested) origin server. -*``dead_os_conn_timeout``* {#dead_os_conn_timeout} +``dead_os_conn_timeout`` Default: ``15`` seconds. The connection timeout to the congested origin server. -*``dead_os_conn_retries``* {#dead_os_conn_retries} +``dead_os_conn_retries`` Default: ``1`` The maximum number of retries allowed to the congested origin server. -*``max_connection``* {#max_connection} +``max_connection`` Default: ``-1`` The maximum number of connections allowed from Traffic Server to the origin server. -*``error_page``* {#error_page} +``error_page`` Default: ``"congestion#retryAfter"`` The error page sent to the client when a server is congested. You must enclose the value in quotes; -*:file:`congestion.config`* {#congestion_scheme} +``congestion_scheme`` Default: ``"per_ip"`` Specifies if Traffic Server applies the rule on a per-host (``"per_host"``) or per-IP basis (``"per_ip"``). You must enclose http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/reference/configuration/icp.config.en.rst ---------------------------------------------------------------------- diff --git a/doc/reference/configuration/icp.config.en.rst b/doc/reference/configuration/icp.config.en.rst index 94133ba..4757f37 100644 --- a/doc/reference/configuration/icp.config.en.rst +++ b/doc/reference/configuration/icp.config.en.rst @@ -41,42 +41,42 @@ information for a single ICP peer in the following format:: Each field is described in the following list. -*``host``* {#host} +``host`` The hostname of the ICP peer. This field is optional; if you do not specify the hostname of the ICP peer, you must specify the IP address. -*``host_IP``* {#host_IP} +``host_IP`` The IP address of the ICP peer. This field is optional; if you do not specify the IP address of the ICP peer, you must specify the hostname. -*``ctype``* {#ctype} +``ctype`` Use the following options: - 1 to indicate an ICP parent cache - 2 to indicate an ICP sibling cache -*``proxy_port``* {#proxy_port} +``proxy_port`` The port number of the TCP port used by the ICP peer for proxy communication. -*``icp_port``* {#icp_port} +``icp_port`` The port number of the UDP port used by the ICP peer for ICP communication. -*``MC_on``* {#mc_on} +``MC_on`` Enable or disable MultiCast: - 0 if multicast is disabled - 1 if multicast is enabled -*``MC_ip``* {#mc_ip} +``MC_ip`` The MultiCast IP address. -*``MC_ttl``* {#mc_ttl} +``MC_ttl`` The multicast time to live. Use the following options: - 1 if IP multicast datagrams will not be forwarded beyond a single http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/sdk/getting-started/naming-conventions.en.rst ---------------------------------------------------------------------- diff --git a/doc/sdk/getting-started/naming-conventions.en.rst b/doc/sdk/getting-started/naming-conventions.en.rst index 45794a2..04a3aa6 100644 --- a/doc/sdk/getting-started/naming-conventions.en.rst +++ b/doc/sdk/getting-started/naming-conventions.en.rst @@ -25,14 +25,14 @@ The Traffic Server API adheres to the following naming conventions: ``TS_EVENT_NONE``,\ ``TSMutex``, and ``TSContCreate`` - Enumerated values are always written in all uppercase letters. - **Examples**: *``TS_EVENT_NONE``* and *``TS_VC_CLOSE_ABORT``* + **Examples**: ``TS_EVENT_NONE`` and ``TS_VC_CLOSE_ABORT`` - Constant values are all uppercase; enumerated values can be seen as a subset of constants. **Examples**: ``TS_URL_SCHEME_FILE`` and ``TS_MIME_FIELD_ACCEPT`` - The names of defined types are mixed-case. **Examples**: - *``TSHttpSsn``* and *``TSHttpTxn``* + ``TSHttpSsn`` and ``TSHttpTxn`` - Function names are mixed-case. **Examples**: ``TSUrlCreate`` and ``TSContDestroy`` http://git-wip-us.apache.org/repos/asf/trafficserver/blob/afdfb419/doc/sdk/new-protocol-plugins.en.rst ---------------------------------------------------------------------- diff --git a/doc/sdk/new-protocol-plugins.en.rst b/doc/sdk/new-protocol-plugins.en.rst index c0f7fc5..f7e281b 100644 --- a/doc/sdk/new-protocol-plugins.en.rst +++ b/doc/sdk/new-protocol-plugins.en.rst @@ -226,29 +226,29 @@ The steps below describe the flow of execution illustrated in :ref:`"How Transaction State Machines are Implemented in the Protocol Plugin" <ImplementTransStMachine>`. -1. The handler for the TSM, (called **``main_handler``** in the Protocol +1. The handler for the TSM, (called ``main_handler`` in the Protocol plugin) receives events from the TSM. -2. **``main_handler``** examines the state of the transaction-in +2. ``main_handler`` examines the state of the transaction-in particular, it examines the current handler. -3. **``main_handler``** calls the **``current_handler``** (which is one +3. ``main_handler`` calls the ``current_handler`` (which is one of the state handler functions), and then passes the current event to - **``current_handler``**. In :ref:`the image + ``current_handler``. In :ref:`the image below <ImplementTransStMachine>` below, the current handler is - called **``state2_handler``**. + called ``state2_handler``. -4. The **``current_handler``** handles the event and updates the data. +4. The ``current_handler`` handles the event and updates the data. In :ref:`the image below <ImplementTransStMachine>` below, the state is - changed from **``state2``** to **``state3``** (and the current - handler is changed from **``state2_handler``** to - **``state3_handler``**). The next time **``main_handler``** receives - an event, it will be processed by **``state3_handler``**. + changed from ``state2`` to ``state3`` (and the current + handler is changed from ``state2_handler`` to + ``state3_handler``). The next time ``main_handler`` receives + an event, it will be processed by ``state3_handler``. -5. **``state2_handler``** arranges the next callback of the TSM. +5. ``state2_handler`` arranges the next callback of the TSM. Typically, it gives Traffic Server additional work to do (such as writing a file to cache) so that it can progress to the next state. - The TSM (**``main_handler``**) then waits for the next event to + The TSM (``main_handler``) then waits for the next event to arrive from Traffic Server. **How Transaction State Machines are Implemented in the Protocol @@ -280,93 +280,93 @@ typical transaction. two: a client accept port and a server port) and runs an initialization routine, ``init``. -2. The **``init``** function (in ``Protocol.c``) creates the plugin's - log file using **``TSTextLogObjectCreate``**. +2. The ``init`` function (in ``Protocol.c``) creates the plugin's + log file using ``TSTextLogObjectCreate``. -3. The **``init``** function creates the accept state machine using - **``AcceptCreate``**. The code for **``AcceptCreate``** is in the +3. The ``init`` function creates the accept state machine using + ``AcceptCreate``. The code for ``AcceptCreate`` is in the ``Accept.c`` file. 4. The accept state machine, like the transaction state machine, keeps track of its state with a data structure. This data structure, - **``Accept``**, is defined in the ``Accept.h`` file. State data in - **``AcceptCreate``** is associated with the new accept state machine - via **``TSContDataSet``**. + ``Accept``, is defined in the ``Accept.h`` file. State data in + ``AcceptCreate`` is associated with the new accept state machine + via ``TSContDataSet``. -5. The **``init``** function arranges the callback of the accept state +5. The ``init`` function arranges the callback of the accept state machine when there is a network connection by using - **``TSNetAccept``**. + ``TSNetAccept``. -6. The handler for the accept state machine is **``accept_event``** in +6. The handler for the accept state machine is ``accept_event`` in the ``Accept.c`` file. When Traffic Server's Net Processor sends - **``TS_EVENT_NET_ACCEPT``** to the accept state machine, - **``accept_event``** creates a transaction state machine - (**``txn_sm``**) by calling **``TxnSMCreate``**. Notice that - **``accept_event``** creates a mutex for the transaction state + ``TS_EVENT_NET_ACCEPT`` to the accept state machine, + ``accept_event`` creates a transaction state machine + (``txn_sm``) by calling ``TxnSMCreate``. Notice that + ``accept_event`` creates a mutex for the transaction state machine, since each transaction state machine has its own mutex. -7. The **``TxnSMCreate``** function is in the ``TxnSM.c`` file. The +7. The ``TxnSMCreate`` function is in the ``TxnSM.c`` file. The first thing it does is initialize the transaction's data, which is of type ``TxnSM`` (as defined in ``TxnSM.h``). Notice that the - current handler (**``q_current_handler``**) is set to - **``state_start``**. + current handler (``q_current_handler``) is set to + ``state_start``. -8. **``TxnSMCreate``** then creates a transaction state machine using - **``TSContCreate``**. The handler for the transaction state machine - is **``main_handler``**, which is in the ``TxnSM.c`` file. +8. ``TxnSMCreate`` then creates a transaction state machine using + ``TSContCreate``. The handler for the transaction state machine + is ``main_handler``, which is in the ``TxnSM.c`` file. -9. When **``accept_event``** receives **``TS_EVENT_NET_ACCEPT``**, it +9. When ``accept_event`` receives ``TS_EVENT_NET_ACCEPT``, it calls the transaction state machine ( - **``TSContCall (txn_sm, 0, NULL);``** ). The event passed to - **``main_handler``** is ``0`` (**``TS_EVENT_NONE``**). + ``TSContCall (txn_sm, 0, NULL);`` ). The event passed to + ``main_handler`` is ``0`` (``TS_EVENT_NONE``). -10. The first thing **``main_handler``** does is examine the current - **``txn_sm``** state by calling **``TSContDataGet``**. The state is - **``state_start``**. +10. The first thing ``main_handler`` does is examine the current + ``txn_sm`` state by calling ``TSContDataGet``. The state is + ``state_start``. -11. **``main_handler``** then invokes the handler for - **``state_start``** by using the function pointer - **``TxnSMHandler``** (as defined in ``TxnSM.h``). +11. ``main_handler`` then invokes the handler for + ``state_start`` by using the function pointer + ``TxnSMHandler`` (as defined in ``TxnSM.h``). -12. The **``state_start``** handler function (in the ``TxnSM.c`` file) +12. The ``state_start`` handler function (in the ``TxnSM.c`` file) is handed an event (at this stage, the event is - **``TS_EVENT_NET_ACCEPT``**) and a client vconnection. - **``state_start``** checks to see if this client vconnection is - closed; if it is not, then **``state_start``** attempts to read data - from the client vconnection into an **``TSIOBuffer``** - (**``state_start``** is handling the event it receives). - -13. **``state_start``** changes the current handler to - **``state_interface_with_client``** (that is, it updates the state + ``TS_EVENT_NET_ACCEPT``) and a client vconnection. + ``state_start`` checks to see if this client vconnection is + closed; if it is not, then ``state_start`` attempts to read data + from the client vconnection into an ``TSIOBuffer`` + (``state_start`` is handling the event it receives). + +13. ``state_start`` changes the current handler to + ``state_interface_with_client`` (that is, it updates the state of the transaction to the next state). -14. **``state_start``** initiates a read of the client vconnection +14. ``state_start`` initiates a read of the client vconnection (arranges for Traffic Server to send - **``TS_EVENT_VCONN_READ_READY``** events to the TSM) by calling - **``TSVConnRead``**. + ``TS_EVENT_VCONN_READ_READY`` events to the TSM) by calling + ``TSVConnRead``. -15. **``state_interface_with_client``** is activated by the next event +15. ``state_interface_with_client`` is activated by the next event from Traffic Server. It checks for errors and examines the read VIO - for the read operation initiated by **``TSVConnRead``**. + for the read operation initiated by ``TSVConnRead``. -16. If the read VIO is the **``client_read_VIO``** (which we are +16. If the read VIO is the ``client_read_VIO`` (which we are expecting at this stage in the transaction), then - **``state_interface_with_client``** updates the state to - **``state_read_request_from_client``** . + ``state_interface_with_client`` updates the state to + ``state_read_request_from_client`` . -17. **``state_read_request_from_client``** handles actual - **``TS_EVENT_READ_READY``** events and reads the client request. +17. ``state_read_request_from_client`` handles actual + ``TS_EVENT_READ_READY`` events and reads the client request. -18. **``state_read_request_from_client``** parses the client request. +18. ``state_read_request_from_client`` parses the client request. -19. **``state_read_request_from_client``** updates the current state to - the next state, **``state_handle_cache_lookup``** . +19. ``state_read_request_from_client`` updates the current state to + the next state, ``state_handle_cache_lookup`` . -20. **``state_read_request_from_client``** arranges for Traffic Server +20. ``state_read_request_from_client`` arranges for Traffic Server to call back the TSM with the next set of events (initiating the - cache lookup) by calling **``TSCacheRead``**. + cache lookup) by calling ``TSCacheRead``. -21. When the **``TSCacheRead``** sends the TSM either - **``TS_EVENT_OPEN_READ``** (a cache hit) or - **``TS_EVENT_OPEN_READ_FAILED``** (a cache miss), - **``main_handler``** calls **``state_handle_cache_lookup``**. +21. When the ``TSCacheRead`` sends the TSM either + ``TS_EVENT_OPEN_READ`` (a cache hit) or + ``TS_EVENT_OPEN_READ_FAILED`` (a cache miss), + ``main_handler`` calls ``state_handle_cache_lookup``.
