#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
msgid ""
msgstr ""
"Project-Id-Version: Apache Traffic Server 4.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2013-11-08 17:57+0900\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:4
msgid "How to Create Traffic Server Plugins"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:28
msgid ""
"This chapter provides a foundation for designing and writing plugins. "
"Reading this chapter will help you to understand:"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:31
msgid ""
"The asynchronous event mode. This is the design paradigm used throughout "
"Traffic Server; plugins must also follow this design. It includes the "
"callback mechanism for Traffic Server to \"wake up\" your plugin and put it "
"to work."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:36
msgid ""
"Traffic Server's HTTP processing, with an overview of the HTTP state "
"machine."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:39
msgid ""
"How plugins can hook onto and modify/extend Traffic Server's HTTP "
"processing."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:47
msgid "The Asynchronous Event Model"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:49
msgid ""
"Traffic Server is a multi-threaded process. There are two main reasons why "
"a server might use multiple threads:"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:52
msgid ""
"To take advantage of the concurrency available with multiple CPUs and "
"multiple I/O devices."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:55
msgid ""
"To manage concurrency from having many simultaneous client connections. For "
"example, a server could create one thread for each connection, allowing the "
"operating system (OS) to control switching between threads."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:60
msgid ""
"Traffic Server uses multiple threads for the first reason. However, Traffic "
"Server does not use a separate OS thread per transaction because it would "
"not be efficient when handling thousands of simultaneous connections."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:65
msgid ""
"Instead, Traffic Server provides special event-driven mechanisms for "
"efficiently scheduling work: the event system and continuations. The "
"**event system** is used to schedule work to be done on threads. A "
"**continuation** is a passive, event-driven state machine that can do some "
"work until it reaches a waiting point; it then sleeps until it receives "
"notification that conditions are right for doing more work. For example, "
"HTTP state machines (which handle HTTP transactions) are implemented as "
"continuations."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:93
msgid "Traffic Server Internals"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:95
msgid ""
"Plugins are typically implemented as continuations. All of the sample code "
"plugins (except ``hello-world``) are continuations that are created when "
"Traffic Server starts up; they then wait for events that trigger them into "
"activity."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:107
msgid "Traffic Server with Plugins"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:109
msgid ""
"A plugin may consist of just one static continuation that is called "
"whenever certain events happen. Examples of such plugins include "
"``blacklist-1.c``, ``basic-auth.c``, and ``redirect-1.c``. Alternatively, a "
"plugin might dynamically create other continuations as needed. Transform "
"plugins are built in this manner: a static parent continuation checks all "
"transactions to see if any are transformable; when a transaction is "
"transformable, the static continuation creates a type of continuation "
"called a **vconnection**. The vconnection lives as long as it takes to "
"complete the transform and then destroys itself. This design can be seen in "
"all of the sample transform plugins. Plugins that support new protocols "
"also have this architecture: a static continuation listens for incoming "
"client connections and then creates transaction state machines to handle "
"each protocol transaction."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:123
msgid ""
"When you write plugins, there are several ways to send events to "
"continuations. For HTTP plugins, there is a \"hook\" mechanism that enables "
"the Traffic Server HTTP state machine to send your plugin wakeup calls when "
"needed. Additionally, several Traffic Server API functions trigger Traffic "
"Server sub-processes to send events to plugins: ``TSContCall``, "
"``TSVConnRead``, ``TSCacheWrite``, and ``TSMgmtUpdateRegister``, to name a "
"few."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:132
msgid "Traffic Server HTTP State Machine"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:151
msgid "HTTP Transaction"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:153
msgid ""
"An HTTP transaction consists of a client request for a web document and "
"Traffic Server's response. The response could be the requested web server "
"content or it could be an error message. The content could come from the "
"Traffic Server cache or Traffic Server might fetch it from the origin "
"server. The following diagram shows some states in a typical transaction - "
"specifically, the scenario wherein content is served from cache."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:168
msgid "Simplified HTTP Transaction"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:170
msgid ""
"In the diagram above, Traffic Server accepts the client connection, reads "
"the request headers, looks up the origin server's IP address, and looks for "
"the requested content in the cache. If the content is not in the cache (a "
"\"miss\"), then Traffic Server opens a connection to the origin server and "
"issues a request for the content. If the content is in the cache (a \"hit"
"\"), then Traffic Server checks it for freshness."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:194
msgid "API Hooks Corresponding to States Listed in"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:211
msgid "Blacklist Plugin"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:213
msgid ""
"Traffic Server calls the Blacklist plugin right after the origin server DNS "
"lookup. The plugin checks the requested host against a list of blacklisted "
"servers; if the request is allowed, then the transaction proceeds. If the "
"host is forbidden, then the Blacklist plugin sends the transaction into an "
"error state. When the HTTP state machine gets to the \"send reply header\" "
"state, it then calls the Blacklist plugin to provide the error message "
"that's sent to the client."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:222
msgid "Types of Hooks"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:234
msgid ""
"**Header manipulation plugins**, such as filtering, basic authorization, or "
"redirects, usually have a global hook to the DNS lookup or the read request "
"header states. If specific actions need to be done to the transaction "
"further on, then the plugin adds itself to a transaction hook. "
"**Transformation plugins** require a \\*\\*global hook \\*\\*to check all "
"transactions for transformability followed by a **transform hook**, which "
"is a type of transaction hook used specifically for transforms."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:42
msgid ""
"A :doc:`roadmap for writing plugins <how-to-create-trafficserver-plugins/"
"roadmap-for-creating-plugins.en>`, with an overview of the functionality "
"provided by the Traffic Server API."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:74
msgid ""
"Continuation objects are used throughout Traffic Server. Some might live "
"for the duration of the Traffic Server process, while others are created "
"(perhaps by other continuations) for specific needs and then destroyed. :"
"ref:`TSInternals` (below) shows how the major components of Traffic Server "
"interact. Traffic Server has several **processors**, such as *cache "
"processor* and *net processor*, that consolidate cache or network I/O "
"tasks. Processors talk to the event system and schedule work on threads. An "
"executing thread calls back a continuation by sending it an event. When a "
"continuation receives an event, it wakes up, does some work, and either "
"destroys itself or goes back to sleep & waits for the next event."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:86
msgid "**Traffic Server Internals**"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:100
msgid "**Traffic Server with Plugins**"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:134
msgid ""
"Traffic Server performs sophisticated HTTP caching and proxying. Important "
"features include checking for alternates and document freshness, filtering, "
"supporting cache hierarchies, and hosting. Traffic Server handles thousands "
"of client requests at a time and each request is handled by an HTTP state "
"machine. These machines follow a complex state diagram that includes all of "
"the states required to support Traffic Server's features. The Traffic "
"Server API provides hooks to a subset of these states, chosen for their "
"relevance to plugins. You can view the API hooks and corresponding HTTP "
"states in the :ref:`http-txn-state-diagram`."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:145
msgid ""
"The example in this section (below) explains how a plugin typically "
"intervenes and extends Traffic Server's processing of an HTTP transaction. "
"Complete details about hooking on to Traffic Server processes are provided "
"in :doc:`http-hooks-and-transactions.en`."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:161
msgid "**Simplified HTTP Transaction**"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:177
msgid ""
"If the content is fresh, then Traffic Server sends a reply header to the "
"client. If the content is stale, then Traffic Server opens a connection to "
"the origin server and requests the content. The figure above, :ref:"
"`SimplifiedHTTPTransaction`, does *not* show behavior in the event of an "
"error. If there is an error at a any stage, then the HTTP state machine "
"jumps to the \"send reply header\" state and sends a reply. If the reply is "
"an error, then the transaction closes. If the reply is not an error, then "
"Traffic Server first sends the response content before it closes the "
"transaction."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:187
msgid "**API Hooks Corresponding to States**"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:196
msgid ""
"You use hooks as triggers to start your plugin. The name of a hook reflects "
"the Traffic Server state that was *just completed*. For example, the \"OS "
"DNS lookup\" hook wakes up a plugin right *after* the origin server DNS "
"lookup. For a plugin that requires the IP address of the requested origin "
"server, this hook is the right one to use. The Blacklist plugin works in "
"this manner, as shown in the :ref:`BlackListPlugin` diagram below."
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:204
msgid "**Blacklist Plugin**"
msgstr ""

#: ../../sdk/how-to-create-trafficserver-plugins.en.rst:224
msgid ""
"The Blacklist plugin's hook to the \"origin server DNS lookup\" state is a "
"****global hook****, meaning that the plugin is called *every time* there's "
"an HTTP transaction with a DNS lookup event. The plugin's hook to the "
"\"send reply header\" state is a **tr**\\ ***ansaction hook***, meaning "
"that this hook is only invoked for *specified transactions* (in the "
"Blacklist example, it's only used for requests to blacklisted servers). "
"Several examples of setting up hooks are provided in the code example "
"chapters: :doc:`header-based-plugin-examples.en` and :doc:`http-"
"transformation-plugin.en`"
msgstr ""
