1 /*
2  * include/types/channel.h
3  * Channel management definitions, macros and inline functions.
4  *
5  * Copyright (C) 2000-2014 Willy Tarreau - w@1wt.eu
6  *
7  * This library is free software; you can redistribute it and/or
8  * modify it under the terms of the GNU Lesser General Public
9  * License as published by the Free Software Foundation, version 2.1
10  * exclusively.
11  *
12  * This library is distributed in the hope that it will be useful,
13  * but WITHOUT ANY WARRANTY; without even the implied warranty of
14  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
15  * Lesser General Public License for more details.
16  *
17  * You should have received a copy of the GNU Lesser General Public
18  * License along with this library; if not, write to the Free Software
19  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
20  */
21 
22 #ifndef _TYPES_CHANNEL_H
23 #define _TYPES_CHANNEL_H
24 
25 #include <common/config.h>
26 #include <common/buffer.h>
27 
28 /* The CF_* macros designate Channel Flags, which may be ORed in the bit field
29  * member 'flags' in struct channel. Here we have several types of flags :
30  *
31  *   - pure status flags, reported by the data layer, which must be cleared
32  *     before doing further I/O :
33  *     CF_*_NULL, CF_*_PARTIAL
34  *
35  *   - pure status flags, reported by stream-interface layer, which must also
36  *     be cleared before doing further I/O :
37  *     CF_*_TIMEOUT, CF_*_ERROR
38  *
39  *   - read-only indicators reported by lower data levels :
40  *     CF_STREAMER, CF_STREAMER_FAST
41  *
42  *   - write-once status flags reported by the stream-interface layer :
43  *     CF_SHUTR, CF_SHUTW
44  *
45  *   - persistent control flags managed only by application level :
46  *     CF_SHUT*_NOW, CF_*_ENA
47  *
48  * The flags have been arranged for readability, so that the read and write
49  * bits have the same position in a byte (read being the lower byte and write
50  * the second one). All flag names are relative to the channel. For instance,
51  * 'write' indicates the direction from the channel to the stream interface.
52  */
53 
54 #define CF_READ_NULL      0x00000001  /* last read detected on producer side */
55 #define CF_READ_PARTIAL   0x00000002  /* some data were read from producer or a read exception occurred */
56 #define CF_READ_TIMEOUT   0x00000004  /* timeout while waiting for producer */
57 #define CF_READ_ERROR     0x00000008  /* unrecoverable error on producer side */
58 #define CF_READ_ACTIVITY  (CF_READ_NULL|CF_READ_PARTIAL|CF_READ_ERROR)
59 
60 #define CF_WAKE_CONNECT   0x00000010  /* wake the task up after connect succeeds */
61 #define CF_SHUTR          0x00000020  /* producer has already shut down */
62 #define CF_SHUTR_NOW      0x00000040  /* the producer must shut down for reads ASAP */
63 #define CF_READ_NOEXP     0x00000080  /* producer should not expire */
64 
65 #define CF_WRITE_NULL     0x00000100  /* write(0) or connect() succeeded on consumer side */
66 #define CF_WRITE_PARTIAL  0x00000200  /* some data were written to the consumer */
67 #define CF_WRITE_TIMEOUT  0x00000400  /* timeout while waiting for consumer */
68 #define CF_WRITE_ERROR    0x00000800  /* unrecoverable error on consumer side */
69 #define CF_WRITE_ACTIVITY (CF_WRITE_NULL|CF_WRITE_PARTIAL|CF_WRITE_ERROR)
70 
71 #define CF_WAKE_WRITE     0x00001000  /* wake the task up when there's write activity */
72 #define CF_SHUTW          0x00002000  /* consumer has already shut down */
73 #define CF_SHUTW_NOW      0x00004000  /* the consumer must shut down for writes ASAP */
74 #define CF_AUTO_CLOSE     0x00008000  /* producer can forward shutdown to other side */
75 
76 /* When CF_SHUTR_NOW is set, it is strictly forbidden for the producer to alter
77  * the buffer contents. When CF_SHUTW_NOW is set, the consumer is free to perform
78  * a shutw() when it has consumed the last contents, otherwise the session processor
79  * will do it anyway.
80  *
81  * The SHUT* flags work like this :
82  *
83  *  SHUTR SHUTR_NOW  meaning
84  *    0       0      normal case, connection still open and data is being read
85  *    0       1      closing : the producer cannot feed data anymore but can close
86  *    1       0      closed: the producer has closed its input channel.
87  *    1       1      impossible
88  *
89  *  SHUTW SHUTW_NOW  meaning
90  *    0       0      normal case, connection still open and data is being written
91  *    0       1      closing: the consumer can send last data and may then close
92  *    1       0      closed: the consumer has closed its output channel.
93  *    1       1      impossible
94  *
95  * The SHUTW_NOW flag should be set by the session processor when SHUTR and AUTO_CLOSE
96  * are both set. And it may also be set by the producer when it detects SHUTR while
97  * directly forwarding data to the consumer.
98  *
99  * The SHUTR_NOW flag is mostly used to force the producer to abort when an error is
100  * detected on the consumer side.
101  */
102 
103 #define CF_STREAMER       0x00010000  /* the producer is identified as streaming data */
104 #define CF_STREAMER_FAST  0x00020000  /* the consumer seems to eat the stream very fast */
105 
106 #define CF_WROTE_DATA     0x00040000  /* some data were sent from this buffer */
107 #define CF_ANA_TIMEOUT    0x00080000  /* the analyser timeout has expired */
108 #define CF_READ_ATTACHED  0x00100000  /* the read side is attached for the first time */
109 #define CF_KERN_SPLICING  0x00200000  /* kernel splicing desired for this channel */
110 #define CF_READ_DONTWAIT  0x00400000  /* wake the task up after every read (eg: HTTP request) */
111 #define CF_AUTO_CONNECT   0x00800000  /* consumer may attempt to establish a new connection */
112 
113 #define CF_DONT_READ      0x01000000  /* disable reading for now */
114 #define CF_EXPECT_MORE    0x02000000  /* more data expected to be sent very soon (one-shoot) */
115 #define CF_SEND_DONTWAIT  0x04000000  /* don't wait for sending data (one-shoot) */
116 #define CF_NEVER_WAIT     0x08000000  /* never wait for sending data (permanent) */
117 
118 #define CF_WAKE_ONCE      0x10000000  /* pretend there is activity on this channel (one-shoot) */
119 #define CF_FLT_ANALYZE    0x20000000  /* at least one filter is still analyzing this channel */
120 #define CF_EOI            0x40000000  /* end-of-input has been reached */
121 #define CF_ISRESP         0x80000000  /* 0 = request channel, 1 = response channel */
122 
123 /* Masks which define input events for stream analysers */
124 #define CF_MASK_ANALYSER  (CF_READ_ATTACHED|CF_READ_ACTIVITY|CF_READ_TIMEOUT|CF_ANA_TIMEOUT|CF_WRITE_ACTIVITY|CF_WAKE_ONCE)
125 
126 /* Mask for static flags which cause analysers to be woken up when they change */
127 #define CF_MASK_STATIC    (CF_SHUTR|CF_SHUTW|CF_SHUTR_NOW|CF_SHUTW_NOW)
128 
129 
130 /* Analysers (channel->analysers).
131  * Those bits indicate that there are some processing to do on the buffer
132  * contents. It will probably evolve into a linked list later. Those
133  * analysers could be compared to higher level processors.
134  * The field is blanked by channel_init() and only by analysers themselves
135  * afterwards.
136  */
137 /* AN_REQ_FLT_START_FE:         0x00000001 */
138 #define AN_REQ_INSPECT_FE       0x00000002  /* inspect request contents in the frontend */
139 #define AN_REQ_WAIT_HTTP        0x00000004  /* wait for an HTTP request */
140 #define AN_REQ_HTTP_BODY        0x00000008  /* wait for HTTP request body */
141 #define AN_REQ_HTTP_PROCESS_FE  0x00000010  /* process the frontend's HTTP part */
142 #define AN_REQ_SWITCHING_RULES  0x00000020  /* apply the switching rules */
143 /* AN_REQ_FLT_START_BE:         0x00000040 */
144 #define AN_REQ_INSPECT_BE       0x00000080  /* inspect request contents in the backend */
145 #define AN_REQ_HTTP_PROCESS_BE  0x00000100  /* process the backend's HTTP part */
146 #define AN_REQ_HTTP_TARPIT      0x00000200  /* wait for end of HTTP tarpit */
147 #define AN_REQ_SRV_RULES        0x00000400  /* use-server rules */
148 #define AN_REQ_HTTP_INNER       0x00000800  /* inner processing of HTTP request */
149 #define AN_REQ_PRST_RDP_COOKIE  0x00001000  /* persistence on rdp cookie */
150 #define AN_REQ_STICKING_RULES   0x00002000  /* table persistence matching */
151 /* AN_REQ_FLT_HTTP_HDRS:        0x00004000 */
152 #define AN_REQ_HTTP_XFER_BODY   0x00008000  /* forward request body */
153 #define AN_REQ_WAIT_CLI         0x00010000
154 /* AN_REQ_FLT_XFER_DATA:        0x00020000 */
155 /* AN_REQ_FLT_END:              0x00040000 */
156 #define AN_REQ_ALL              0x0001bfbe  /* all of the request analysers */
157 
158 /* response analysers */
159 /* AN_RES_FLT_START_FE:         0x00080000 */
160 /* AN_RES_FLT_START_BE:         0x00100000 */
161 #define AN_RES_INSPECT          0x00200000  /* content inspection */
162 #define AN_RES_WAIT_HTTP        0x00400000  /* wait for HTTP response */
163 #define AN_RES_STORE_RULES      0x00800000  /* table persistence matching */
164 #define AN_RES_HTTP_PROCESS_BE  0x01000000  /* process backend's HTTP part */
165 #define AN_RES_HTTP_PROCESS_FE  0x01000000  /* process frontend's HTTP part (same for now) */
166 /* AN_RES_FLT_HTTP_HDRS:        0x02000000 */
167 #define AN_RES_HTTP_XFER_BODY   0x04000000  /* forward response body */
168 #define AN_RES_WAIT_CLI         0x08000000
169 /* AN_RES_FLT_XFER_DATA:        0x10000000 */
170 /* AN_RES_FLT_END:              0x20000000 */
171 #define AN_RES_ALL              0x0de00000  /* all of the response analysers */
172 
173 /* filters interleaved with analysers, see above */
174 #define AN_REQ_FLT_START_FE     0x00000001
175 #define AN_REQ_FLT_START_BE     0x00000040
176 #define AN_REQ_FLT_HTTP_HDRS    0x00004000
177 #define AN_REQ_FLT_XFER_DATA    0x00020000
178 #define AN_REQ_FLT_END          0x00040000
179 
180 #define AN_RES_FLT_START_FE     0x00080000
181 #define AN_RES_FLT_START_BE     0x00100000
182 #define AN_RES_FLT_HTTP_HDRS    0x02000000
183 #define AN_RES_FLT_XFER_DATA    0x10000000
184 #define AN_RES_FLT_END          0x20000000
185 
186 /* Magic value to forward infinite size (TCP, ...), used with ->to_forward */
187 #define CHN_INFINITE_FORWARD    MAX_RANGE(unsigned int)
188 
189 
190 struct channel {
191 	unsigned int flags;             /* CF_* */
192 	unsigned int analysers;         /* bit field indicating what to do on the channel */
193 	struct buffer buf;		/* buffer attached to the channel, always present but may move */
194 	struct pipe *pipe;		/* non-NULL only when data present */
195 	size_t output;                  /* part of buffer which is to be forwarded */
196 	unsigned int to_forward;        /* number of bytes to forward after out without a wake-up */
197 	unsigned short last_read;       /* 16 lower bits of last read date (max pause=65s) */
198 	unsigned char xfer_large;       /* number of consecutive large xfers */
199 	unsigned char xfer_small;       /* number of consecutive small xfers */
200 	unsigned long long total;       /* total data read */
201 	int rex;                        /* expiration date for a read, in ticks */
202 	int wex;                        /* expiration date for a write or connect, in ticks */
203 	int rto;                        /* read timeout, in ticks */
204 	int wto;                        /* write timeout, in ticks */
205 	int analyse_exp;                /* expiration date for current analysers (if set) */
206 };
207 
208 
209 /* Note about the channel structure
210 
211    A channel stores information needed to reliably transport data in a single
212    direction. It stores status flags, timeouts, counters, subscribed analysers,
213    pointers to a data producer and to a data consumer, and information about
214    the amount of data which is allowed to flow directly from the producer to
215    the consumer without waking up the analysers.
216 
217    A channel may buffer data into two locations :
218      - a visible buffer (->buf)
219      - an invisible buffer which right now consists in a pipe making use of
220        kernel buffers that cannot be tampered with.
221 
222    Data stored into the first location may be analysed and altered by analysers
223    while data stored in pipes is only aimed at being transported from one
224    network socket to another one without being subject to memory copies. This
225    buffer may only be used when both the socket layer and the data layer of the
226    producer and the consumer support it, which typically is the case with Linux
227    splicing over sockets, and when there are enough data to be transported
228    without being analyzed (transport of TCP/HTTP payload or tunnelled data,
229    which is indicated by ->to_forward).
230 
231    In order not to mix data streams, the producer may only feed the invisible
232    data with data to forward, and only when the visible buffer is empty. The
233    producer may not always be able to feed the invisible buffer due to platform
234    limitations (lack of kernel support).
235 
236    Conversely, the consumer must always take data from the invisible data first
237    before ever considering visible data. There is no limit to the size of data
238    to consume from the invisible buffer, as platform-specific implementations
239    will rarely leave enough control on this. So any byte fed into the invisible
240    buffer is expected to reach the destination file descriptor, by any means.
241    However, it's the consumer's responsibility to ensure that the invisible
242    data has been entirely consumed before consuming visible data. This must be
243    reflected by ->pipe->data. This is very important as this and only this can
244    ensure strict ordering of data between buffers.
245 
246    The producer is responsible for decreasing ->to_forward. The ->to_forward
247    parameter indicates how many bytes may be fed into either data buffer
248    without waking the parent up. The special value CHN_INFINITE_FORWARD is
249    never decreased nor increased.
250 
251    The buf->o parameter says how many bytes may be consumed from the visible
252    buffer. This parameter is updated by any buffer_write() as well as any data
253    forwarded through the visible buffer. Since the ->to_forward attribute
254    applies to data after buf->p, an analyser will not see a buffer which has a
255    non-null ->to_forward with buf->i > 0. A producer is responsible for raising
256    buf->o by min(to_forward, buf->i) when it injects data into the buffer.
257 
258    The consumer is responsible for decreasing ->buf->o when it sends data
259    from the visible buffer, and ->pipe->data when it sends data from the
260    invisible buffer.
261 
262    A real-world example consists in part in an HTTP response waiting in a
263    buffer to be forwarded. We know the header length (300) and the amount of
264    data to forward (content-length=9000). The buffer already contains 1000
265    bytes of data after the 300 bytes of headers. Thus the caller will set
266    buf->o to 300 indicating that it explicitly wants to send those data, and
267    set ->to_forward to 9000 (content-length). This value must be normalised
268    immediately after updating ->to_forward : since there are already 1300 bytes
269    in the buffer, 300 of which are already counted in buf->o, and that size
270    is smaller than ->to_forward, we must update buf->o to 1300 to flush the
271    whole buffer, and reduce ->to_forward to 8000. After that, the producer may
272    try to feed the additional data through the invisible buffer using a
273    platform-specific method such as splice().
274 
275    The ->to_forward entry is also used to detect whether we can fill the buffer
276    or not. The idea is that we need to save some space for data manipulation
277    (mainly header rewriting in HTTP) so we don't want to have a full buffer on
278    input before processing a request or response. Thus, we ensure that there is
279    always global.maxrewrite bytes of free space. Since we don't want to forward
280    chunks without filling the buffer, we rely on ->to_forward. When ->to_forward
281    is null, we may have some processing to do so we don't want to fill the
282    buffer. When ->to_forward is non-null, we know we don't care for at least as
283    many bytes. In the end, we know that each of the ->to_forward bytes will
284    eventually leave the buffer. So as long as ->to_forward is larger than
285    global.maxrewrite, we can fill the buffer. If ->to_forward is smaller than
286    global.maxrewrite, then we don't want to fill the buffer with more than
287    buf->size - global.maxrewrite + ->to_forward.
288 
289    A buffer may contain up to 5 areas :
290      - the data waiting to be sent. These data are located between buf->p-o and
291        buf->p ;
292      - the data to process and possibly transform. These data start at
293        buf->p and may be up to ->i bytes long.
294      - the data to preserve. They start at ->p and stop at ->p+i. The limit
295        between the two solely depends on the protocol being analysed.
296      - the spare area : it is the remainder of the buffer, which can be used to
297        store new incoming data. It starts at ->p+i and is up to ->size-i-o long.
298        It may be limited by global.maxrewrite.
299      - the reserved area : this is the area which must not be filled and is
300        reserved for possible rewrites ; it is up to global.maxrewrite bytes
301        long.
302  */
303 
304 #endif /* _TYPES_CHANNEL_H */
305 
306 /*
307  * Local variables:
308  *  c-indent-level: 8
309  *  c-basic-offset: 8
310  * End:
311  */
312