Hi Alan, So AFAICT this is not a true superset of the TSClientProtoStack API. FWIW, I also think that removing that API should have been reviewed.
TSClientProtoStack would distinguish between requests triggered by SPDY over TLS and raw SPDY, as well as HTTP vs. HTTPS. I don't know whether that capability is still desired, but it's worth pointing the difference. Unless this API chains the new VC up to a parent VC and logs the full chain? I know you proposed doing that ... On May 23, 2014, at 1:39 PM, Alan M. Carroll <a...@network-geographics.com> wrote: > TSHttpConnectWithPluginID > ========================= > > Allows the plugin to initiate an http connection. This will tag the HTTP > state machine with extra data that can be accessed by the logging interface. > > > Synopsis > -------- > > `#include <ts/ts.h>` > > .. c:function:: TSVConn TSHttpConnectWithPluginId(sockaddr const *addr, char > const* tag, int64_t id) > > > Description > ----------- > > This call attempts to create an HTTP state machine and a virtual connection > to that state machine. This is more efficient than using > :c:func:`TSNetConnect` because it avoids using the operating system stack via > the loopback interface. > > *addr* > This is the network address of the target of the connection. This includes > the port which should be stored in the :c:type:`sockaddr` structure. > > *tag* > This is a tag that is passed through to the HTTP state machine. It must be > a persistent string that has a lifetime longer than the connection. It is > accessible via the log field ``pitag``. This is intended as a class or type > identifier that is consistent across all connections for this plugin. In > effect, the name of the plugin. This can be ``NULL``. > > *id* > This is a numeric identifier that is passed through to the HTTP state > machine. It is accessible via the log field ``piid``. This is intended as a > connection identifier and should be distinct for every call to > ``TSHttpConnectWithPluginID``. The easist mechanism is to define a plugin > global value and increment it for each connection. The value ``0`` is > reserved to mean "not set" and can be used as a default if this functionality > is not needed. If you increment a global counter, how would you correlate logs across a Traffic Server restart? You'll end up with duplicate transaction IDs; so how is a plugin supposed to handle that? > The virtual connection returned as the ``TSCVonn`` is API equivalent to a > network virtual connection both to the plugin and to internal mechanisms. > Data is read and written to the connection (and thence to the target system) > by reading and writing on this virtual connection. > > The combination of tag and id is intended to enable correlation in log post > processing. The tag identifies the connection as related to the plugin and > the id can be used in conjuction with plugin generated logs to correlate the > log records. How would this work in practice? It's common for a plugin to hold a request up while it makes sub-requets. How would this let you correlate the sub-requests with the original client-originated request? > This is also intended to be useful for debugging by tagging not just the HTTP > state machine but also the connection virtual connections (if of type > ``PluginVC``) with correlated data. > > .. topic:: Example > > The SPDY plugin uses this to correlate client sessions with SPDY streams. > Each client connection is assigned a distinct numeric identifier. This is > passed as the *id* to ``TSHttpConnectWithPluginId``. The name is selected to > be the NPN string for the client session protocol, e.g. "spdy/3" or > "spdy/3.1". Log post processing can then count the number of connections for > the various supported protocols and the number of streams / sessions / > transactions for each real client connection to Traffic Server. >
