Added: incubator/trafficserver/site/trunk/docs/sdk/ContinuationFunctions.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/ContinuationFunctions.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/ContinuationFunctions.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/ContinuationFunctions.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,93 @@ + + + +Continuation Functions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Continuation Functions

+

+
+

+INKContCall

+

Calls a continuation.

+
+
Prototype
+

int INKContCall (INKCont + contp, INKEvent + event, void + *edata)

+
Description
+

Sends event and + edata to the + contp’s handler + function. It is an error to call a continuation without holding + the continuation’s lock.

+
Returns
+

The values returned by the continuation contp event + handler.

+
First release
+

Traffic Server 3.0

+
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/ContinuationFunctions.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/Continuations.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/Continuations.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/Continuations.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/Continuations.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,169 @@ + + + +Chapter 12. Continuations + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Chapter 12. Continuations

+
+

Table of Contents

+
+
Mutexes and Data
+
How to Activate Continuations
+
Writing Handler Functions
+
+
+

The continuation interface is Traffic Server’s basic callback + mechanism. Continuations are instances of the opaque data type INKCont. In + its basic form a continuation represents a handler function and a mutex. + This chapter contains:

+
+
+

+Mutexes and Data

+

A continuation must be created with a mutex if your continuation + does one of the following:

+
    +
  • is registered globally (INKHttpHookAdd or + INKHttpSsnHookAdd) to an HTTP hook and uses + INKContDataSet/Get.

  • +
  • is registered locally (INKHttpTxnHookAdd) + but for multiple transactions and uses + INKContDataSet/Get.

  • +
  • uses INKCacheXXX, + INKNetXXX, INKHostLookup + or INKContSchedule APIs.

  • +
+

Before being activated, a caller must grab the continuation’s + mutex. This requirement makes it possible for a continuation’s handler + function to safely access its data and to prevent it from being run by + multiple callers at the same time. See the sample Protocol plugin for + usage. The data protected by the mutex is: any global or continuation + data associated to the continuation by + INKContDataSet. This does not include the local + data created by the continuation handler function. A typical example of + continuations created with associated data structures and mutexes is the + transaction state machine created in the sample Protocol plugin. See + “One Way to Implement a Transaction State Machine”

+

A reentrant call occurs when the continuation passed as an + argument to the API can be called in the same stack trace as the + function calling the API. For instance, if you call INKCacheRead + (contp, mykey), it is possible that contp’s handler will be + called directly and then INKCacheRead returns. + Caveats that could cause a possible issues if:

+
    +
  • a continuation has data associated with it + (INKContDataGet).

  • +
  • the reentrant call passes itself as a continuation to the + reentrant API. In this case, the continuation should not try to + access its data after having called the reentrant API. The reason + for this is that data may be modified by the section of code of the + continuation’s handler that handles the event sent by the API. It is + recommended that you always return after a reentrant call to avoid + accessing something that has been deallocated.

  • +
+

Below is an example with an explaination.

+
continuation_handler (INKCont contp, INKEvent event, void *edata) {
+   switch (event) {
+   case event1:
+      INKReentrantCall (contp);
+      /* Return right away after this call */
+      break;
+   case event2:
+      INKContDestroy (contp);
+      break;
+   }
+}
+

The above example first assumes that the continuation is called + back with event1 and does the first reentrant call which + schedules the continuation to receive event2. Because the + call is reentrant, the processor calls back the continuation right away + with event2 and the continuation is destroyed. If you try + to access the continuation, or one of its members after the reentrant + call, you might access something that has been deallocated. To avoid + accessing something that has been deallocated, never access the + continuation or any of its members after a reentrant call, just exit the + handler.

+

Note that most HTTP transaction plugin continuations do not need + non-null mutexes, because they are called within the processing of an + HTTP transaction and thus have the transaction’s mutex.

+

It is also possible to specify a continuation’s mutex as + NULL. This should be done only when registering a + continuation to a global hook, by a call to + INKHttpHookAdd. In this case, the continuation can + be called simultaneously by different instances of HTTP SM running on + different threads. Having a mutex here would slow down Traffic Server + performance since all the threads will try to lock the same mutex. The + drawback of not having a mutex is that such a continuation cannot have + data associated with it (INKContDataGet/Set can not + be used).

+

When using a NULL mutex, it is dangerous to access + the continuation’s data, but it is usually the case that continuations + with NULL mutexes have no data associated with them. An + example of such a continuation would be one that gets called back every + time an HTTP request is read and determines from the request alone + whether to let the request through or whether to reject it. An HTTP + transaction gives its continuation data to the + contp.

+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/Continuations.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/Conventions.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/Conventions.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/Conventions.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/Conventions.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,99 @@ + + + +Typographical Conventions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Typographical Conventions

+

This document uses the following typographic conventions:

+
+

Table 1. Typographical Conventions

+ ++++ + + + + + + + + + + + + + + + + + + + + + + +
ConventionPurpose
italicsItalics introduce terms.
monospaced faceRepresents C language statements, commands, file content + and computer output.
monospaced + italicRepresents variables for which you should substitute a + value, as in the example, “enter a filename.”
ellipsis ... +Indicates the omission of irrelevant or unimportant + information.
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/Conventions.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/CoupledStatistics.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/CoupledStatistics.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/CoupledStatistics.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/CoupledStatistics.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,158 @@ + + + +Coupled Statistics + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Coupled Statistics

+

Use coupled statistics for quantities that are related and must be + updated jointly. As a very simple example, suppose that you have three + statistics: sum, part_1 and + part_2, and they must always preserve the relationship that + sum = part_1 + part_2. If you update part_1 + without updating sum at the same time, the equation would be untrue. The + mechanism for updating coupled statistics jointly is to create local + copies of global coupled statistics in the routines that modifiy them. + When each local copy is updated appropriately, you do a global update + using INKStatsCoupledUpdate. To specify which statistics + are related to one another, you establish a coupled statistic category, + and make sure that each coupled statistic belongs to the appropriate + category. When it is time to do the global update, you specify the + category to be updated.

+
+ + + + + +
[Note]Note

The local statistic copy must have a duplicate set of statistics + as that of the master copy. Local statistics must also be added to the + local statistic category in the same order as their master copy + counterparts were added originally.

+

Here are the steps you needed, followed by an example of code that + is taken from the redirect-1.c sample + plugin.

+

+To add coupled statistics:

+
    +
  1. Declare the global category for your coupled statistics as a + global INKCoupledStat variable in your plugin.

  2. +
  3. Declare your coupled statistics as global INKStat + variables in your plugin.

  4. +
  5. In INKPluginInit, create a new global coupled + category using + INKStatCoupledGlobalCategoryCreate.

  6. +
  7. +

    In INKPluginInit, create new global coupled + statistics using INKStatCoupledGlobalAdd.

    +

    When you create a new statistic, you need to give it an + “external” name that the Traffic Server command line interface + (Traffic Line) uses to access the statistic.

    +
  8. +
  9. In any routine where you want to modify (increment, decrement, + or other modification) your coupled statistics, declare local copies + of the coupled category and coupled statistics.

  10. +
  11. Then create local copies using + INKStatCoupledLocalCopyCreate and + INKStatCoupledLocalAdd.

  12. +
  13. Modify the local copies of your statistics. Then to update the + global copies jointly, call + INKStatsCoupledUpdate.

  14. +
  15. When you are done, you must destroy the all of the local + copies in the category using + INKStatCoupledLocalCopyDestroy.

  16. +
+
+

+Example Using the redirect-1.c Sample Plugin

+
static INKCoupledStat request_outcomes;
+
+static INKStat requests_all;
+static INKStat requests_redirects;
+static INKStat requests_unchanged;
+
+request_outcomes = INKStatCoupledGlobalCategoryCreate ("request_outcomes"); 
+
+requests_all = INKStatCoupledGlobalAdd (request_outcomes, "requests.all", INKSTAT_TYPE_FLOAT);
+requests_redirects = INKStatCoupledGlobalAdd (request_outcomes, "requests.redirects",
+    INKSTAT_TYPE_INT64);
+requests_unchanged = INKStatCoupledGlobalAdd (request_outcomes, "requests.unchanged", 
+    INKSTAT_TYPE_INT64);
+
+INKCoupledStat local_request_outcomes;
+INKStat local_requests_all;
+INKStat local_requests_redirects;
+INKStat local_requests_unchanged;
+
+local_request_outcomes = INKStatCoupledLocalCopyCreate("local_request_outcomes", 
+    request_outcomes); 
+local_requests_all = INKStatCoupledLocalAdd(local_request_outcomes, "requests.all.local", 
+    INKSTAT_TYPE_FLOAT);
+local_requests_redirects = INKStatCoupledLocalAdd(local_request_outcomes, 
+    "requests.redirects.local", INKSTAT_TYPE_INT64);
+local_requests_unchanged = INKStatCoupledLocalAdd(local_request_outcomes, 
+    "requests.unchanged.local", INKSTAT_TYPE_INT64);
+
+INKStatFloatAddTo( local_requests_all, 1.0 ) ; 
+...
+INKStatIncrement (local_requests_unchanged); 
+INKStatsCoupledUpdate(local_request_outcomes); 
+
+INKStatCoupledLocalCopyDestroy(local_request_outcomes); 
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/CoupledStatistics.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/CoupledStatsFunctions.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/CoupledStatsFunctions.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/CoupledStatsFunctions.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/CoupledStatsFunctions.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,236 @@ + + + +Coupled Statistics + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Coupled Statistics

+

+
+

+INKStatCoupledGlobalAdd

+

.Creates a global coupled stat.

+
+
Prototype
+

INKStat INKStatCoupledGlobalAdd (INKCoupledStat + global_copy , const char * + the_name , INKStatTypes + the_type )

+
Description
+
+

global_copy is + the name of the global coupled stat category to which your new + coupled stat belongs.

+

the_name is the + name you use to view the statistic using Traffic Line. See + “Viewing Statistics Using Traffic Line”. There are two + INKStatTypes: + INKSTAT_TYPE_INT64, and + INKSTAT_TYPE_FLOAT.

+

See “To add coupled statistics:”.

+
+
Returns
+
+

A handle to the newly created global coupled + stat.

+

INK_ERROR_PTR if an error occurs.

+
+
First release
+

Traffic Server 3.5

+
+
+
+

+INKStatCoupledLocalAdd

+

Creates a local copy of a global coupled stat.

+
+
Prototype
+

INKStat INKStatCoupledLocalAdd (INKCoupledStat + local_copy , const char * + the_name , INKStatTypes + the_type )

+
Description
+
+

local_copy is + the name of the local coupled stat category to which your new + coupled stat belongs.

+

the_name is the + name you use to view the statistic using Traffic Line. See + “Viewing Statistics Using Traffic Line”. There are two + INKStatTypes: + INKSTAT_TYPE_INT64, and + INKSTAT_TYPE_FLOAT.

+

See “To add coupled statistics:”.

+
+
Returns
+
+

A handle to a local copy of the global coupled + stat.

+

INK_ERROR_PTR if an error occurs.

+
+
First release
+

Traffic Server 3.5

+
+
+
+

+INKStatCoupledGlobalCategoryCreate

+

Creates a global coupled stat category.

+
+
Prototype
+

INKCoupledStat INKStatCoupledGlobalCategoryCreate + ( const char * the_name + )

+
Description
+
+

Returns a new global coupled stat category. Use this + function in INKPluginInit. The name + argument is the name you use to access this stat in Traffic + Line. See “Viewing Statistics Using Traffic Line”.

+

See “To add coupled statistics:”.

+
+
Returns
+
+

A handle to a the newly created global coupled stat + category.

+

INK_ERROR_PTR if an error occurs.

+
+
First release
+

Traffic Server 3.5

+
+
+
+

+INKStatCoupledLocalCopyCreate

+

.Creates a local copy of a global coupled stat + category.

+
+
Prototype
+

INKCoupledStat INKStatCoupledLocalCopyCreate ( + const char * the_name , + INKCoupledStat + global_copy)

+
Description
+
+

Returns a new local coupled stat category. Use this + function in any routine where you need to modify local copies + of global statistics. The name argument is the name you use to + access this stat in Traffic Line. See “Viewing Statistics Using Traffic Line”.

+

See “To add coupled statistics:”.

+
+
Returns
+
+

A handle to the local copy of the global coupled stat + category.

+

INK_ERROR_PTR

+
+
First release
+

Traffic Server 3.5

+
+
+
+

+INKStatCoupledLocalCopyDestroy

+

.Destroys a local category of statistics.

+
+
Prototype
+

INKReturnCode INKStatCoupledLocalCopyDestroy + (INKCoupledStat + local_copy)

+
Description
+

Destroys a local statistics category. Always destroy the + local category when you are done with it. See “To add coupled statistics:”.

+
Returns
+
+

INK_SUCCESS if the operation completes + successfully.

+

INK_ERROR if an error occurs.

+
+
First release
+

Traffic Server 3.5

+
+
+
+

+INKStatsCoupledUpdate

+

Updates a category of coupled statistics.

+
+
Prototype
+

INKReturnCode INKStatsCoupledUpdate + (INKCoupledStat + local_copy)

+
Description
+

Updates all of the coupled stats belonging to the + category local_copy. + See “To add coupled statistics:”.

+
Returns
+
+

INK_SUCCESS if the operation completes + successfully.

+

INK_ERROR if an error occurs.

+
+
First release
+

Traffic Server 3.5

+
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/CoupledStatsFunctions.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/CreatingTSPlugins.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/CreatingTSPlugins.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/CreatingTSPlugins.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/CreatingTSPlugins.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,459 @@ + + + +Chapter 2. How to Create Traffic Server Plugins + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Chapter 2. How to Create Traffic Server Plugins

+
+

Table of Contents

+
+
The Asynchronous Event Model
+
+
Traffic Server HTTP State Machine
+
+
HTTP Transaction
+
Types of Hooks
+
+
+
Roadmap for Creating Plugins
+
Index
+
+
+

This chapter provides a foundation for designing and writing + plugins. Reading this chapter will help you understand:

+
+
+

+The Asynchronous Event Model

+

Traffic Server is a multi-threaded process. There are two main + reasons why a server might use multiple threads:

+
    +
  • To take advantage of the concurrency available with multiple + CPUs and multiple I/O devices.

  • +
  • 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.

  • +
+

Traffic Server uses multiple threads for the first reason. But + Traffic Server does not use a separate OS thread per transaction because + it would not be efficient when handling thousands of simultaneous + connections.

+

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 instance, HTTP state + machines (which handle HTTP transactions) are implemented as + continuations.

+

Continuation objects are used throughout Traffic Server. Some + might live for the duration of the Traffic Server process; others are + created (perhaps by other continuations) for specific needs and then + destroyed. Figure 2.1, “Traffic Server Internals” shows how the major + components of Traffic Server interact. Traffic Server has several + processors, such + as cache processor and net processor, which 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 waiting for the + next event.

+
+

Figure 2.1. Traffic Server Internals

+
Traffic Server Internals
+
+

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 wait + for events that trigger them into activity.

+
+

Figure 2.2. Traffic Server with Plugins

+
Traffic Server with Plugins
+
+

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 could + 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. You can see this design 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 creates transaction state machines to handle each + protocol transaction.

+

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: + INKContCall, INKVConnRead, + INKCacheWrite, and INKMgmtUpdateRegister, to + name a few.

+
+

+Traffic Server HTTP State Machine

+

Traffic Server does sophisticated HTTP caching and proxying. Its + 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 Figure 8.1, “HTTP Transaction State Diagram”.

+

The example in this section 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 Chapter 8, HTTP Hooks and Transactions.

+
+

+HTTP Transaction

+

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:

+
+

Figure 2.3. Simplified HTTP Transaction

+
Simplified HTTP Transaction
+
+

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 + it’s 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.

+

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. + What Figure 2.3, “Simplified HTTP Transaction” does + not show is that 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 closing the + transaction.

+
+

Figure 2.4. API Hooks Corresponding to States Listed in Figure 2.3, “Simplified HTTP Transaction”

+
API Hooks Corresponding to States Listed in
+
+

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 would + wake 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 Figure 2.5, “Blacklist Plugin”.

+
+

Figure 2.5. Blacklist Plugin

+
Blacklist Plugin
+
+

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 an error message that's sent + to the client.

+
+
+

+Types of Hooks

+

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 transaction + 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, Chapter 4, Header-Based Plugin Examples, and Chapter 5, HTTP Transformation Plugins.

+

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 + specifically used for transforms.

+
+
+
+
+

+Index

+
+
+

C

+
+
compiling on HPUX, HPUX Example +
+
compiling on UNIX, Unix Example +
+
compiling on Windows NT, Compiling for Windows NT +
+
compiling plugins, examples, Compile Your Plugin +
+
+
+
+

D

+
+
deprecated functions, Deprecated Functions +
+
duplicate MIME fields, Duplicate MIME Fields Are Not Coalesced +
+
+
+
+

G

+
+
global hook, Setting a Global Hook +
+
global HTTP hooks, Adding Hooks +
+
+
+
+

H

+
+
hello-world example, A Simple Plugin +
+
HTTP header, MIME Headers +
+
HTTP session, HTTP Sessions +
+
HTTP transaction, HTTP Sessions +
+
+
+
+

I

+
+
INKEventFunc, Accessing the Transaction Being Processed +
+
INKHttpAltInfo, HTTP Alternate Selection +
+
INKHttpTxn, Accessing the Transaction Being Processed, HTTP Transactions +
+
INKMBufferCreate, HTTP Headers +
+
INKVIO, VIOs +
+
INK_HTTP_RESPONSE_TRANSFORM_HOOK, The Append-Transform Plugin +
+
INK_HTTP_SSN_CLOSE_HOOK, HTTP Sessions +
+
INK_HTTP_SSN_START_HOOK, HTTP Sessions +
+
INK_LOG_MODE_ADD_TIMESTAMP, blacklist-1.c +
+
INT_MAX, The vconnection user’s view +
+
+
+
+

L

+
lock, Mutexes +
+
+
+

M

+
+
memory leak
+
in transformation plugins, Transformation VConnection +
+
method(HTTP), About HTTP Headers +
+
MIME field, About HTTP Headers, MIME Headers +
+
MIME field name, MIME Headers +
+
MIME field value, MIME Headers +
+
MIME fields, MIME Fields Always Belong to an Associated MIME + Header +
+
MIME header, About HTTP Headers, MIME Headers +
+
Backus-Naur form, MIME Headers +
+
multiple plugins, Update the plugin.config File +
+
mutexes, Mutexes +
+
+
+
+

N

+
+
new MIME field functions, MIME Fields Always Belong to an Associated MIME + Header +
+
NT
+
compiling plugins, Compiling for Windows NT +
+
null-terminated strings, No Null-Terminated Strings +
+
+
+
+

P

+
+
parent continuation, Creating the Parent Continuation +
+
parent INKMLoc, Release Marshal Buffer Handles +
+
parent MIME header, MIME Fields Always Belong to an Associated MIME + Header +
+
plugin.config, Plugin Configuration +
+
+
+
+

R

+
+
read VIO, Writing Content Transform Plugins +
+
releasing mbuffer handles, Release Marshal Buffer Handles +
+
+
+
+

S

+
+
sample code
+
+
INKPluginRegister, Plugin Registration and Version Checking +
+
version check, Plugin Registration and Version Checking +
+
+
statistics
+
viewing, Viewing Statistics Using Traffic Line +
+
+
+ + + +
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/CreatingTSPlugins.html ------------------------------------------------------------------------------ svn:keywords = Id Added: incubator/trafficserver/site/trunk/docs/sdk/CustInstallLicenseFunctions.html URL: http://svn.apache.org/viewvc/incubator/trafficserver/site/trunk/docs/sdk/CustInstallLicenseFunctions.html?rev=831152&view=auto ============================================================================== --- incubator/trafficserver/site/trunk/docs/sdk/CustInstallLicenseFunctions.html (added) +++ incubator/trafficserver/site/trunk/docs/sdk/CustInstallLicenseFunctions.html Thu Oct 29 23:23:25 2009 @@ -0,0 +1,82 @@ + + + +Customer Installation and Licensing Functions + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+Home +

Traffic Server Software Developers Kit

+
+ +
+
+

+Customer Installation and Licensing Functions

+

+
+

+INKInstallDirGet

+

Gets Traffic Server’s install directory.

+
+
Prototype
+

const char * INKInstallDirGet(void)

+
Description
+

Get Traffic Server’s installation directory.

+
Returns
+

A pointer to a string containing the Traffic Server’s + installation directory.

+
First release
+

Traffic Server 3.5

+
+
+
+ + Propchange: incubator/trafficserver/site/trunk/docs/sdk/CustInstallLicenseFunctions.html ------------------------------------------------------------------------------ svn:keywords = Id