blob: 01a0a2488bb7d45a59376c44465131bad59cf5c6 [file] [log] [blame]
Willy Tarreaubaaee002006-06-26 02:48:02 +02001/*
Willy Tarreauf1d32c42020-06-04 21:07:02 +02002 * include/haproxy/channel-t.h
Willy Tarreauc7e42382012-08-24 19:22:53 +02003 * Channel management definitions, macros and inline functions.
Willy Tarreau7c3c5412009-12-13 15:53:05 +01004 *
Willy Tarreaua27dc192014-11-27 22:10:04 +01005 * Copyright (C) 2000-2014 Willy Tarreau - w@1wt.eu
Willy Tarreau7c3c5412009-12-13 15:53:05 +01006 *
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 */
Willy Tarreaubaaee002006-06-26 02:48:02 +020021
Willy Tarreauf1d32c42020-06-04 21:07:02 +020022#ifndef _HAPROXY_CHANNEL_T_H
23#define _HAPROXY_CHANNEL_T_H
Willy Tarreaubaaee002006-06-26 02:48:02 +020024
Willy Tarreauf1d32c42020-06-04 21:07:02 +020025#include <haproxy/api-t.h>
Willy Tarreaub2551052020-06-09 09:07:15 +020026#include <haproxy/buf-t.h>
Willy Tarreaubaaee002006-06-26 02:48:02 +020027
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020028/* 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 :
Willy Tarreau3da77c52008-08-29 09:58:42 +020030 *
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020031 * - pure status flags, reported by the data layer, which must be cleared
Willy Tarreau3da77c52008-08-29 09:58:42 +020032 * before doing further I/O :
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020033 * CF_*_NULL, CF_*_PARTIAL
Willy Tarreau3da77c52008-08-29 09:58:42 +020034 *
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020035 * - pure status flags, reported by stream-interface layer, which must also
36 * be cleared before doing further I/O :
37 * CF_*_TIMEOUT, CF_*_ERROR
Willy Tarreau3da77c52008-08-29 09:58:42 +020038 *
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020039 * - read-only indicators reported by lower data levels :
40 * CF_STREAMER, CF_STREAMER_FAST
Willy Tarreau3da77c52008-08-29 09:58:42 +020041 *
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020042 * - write-once status flags reported by the stream-interface layer :
43 * CF_SHUTR, CF_SHUTW
Willy Tarreau3da77c52008-08-29 09:58:42 +020044 *
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020045 * - persistent control flags managed only by application level :
Willy Tarreaub31c9712012-11-11 23:05:39 +010046 * CF_SHUT*_NOW, CF_*_ENA
Willy Tarreau3da77c52008-08-29 09:58:42 +020047 *
48 * The flags have been arranged for readability, so that the read and write
Willy Tarreau418fd472009-09-06 21:37:23 +020049 * bits have the same position in a byte (read being the lower byte and write
Willy Tarreauc7e42382012-08-24 19:22:53 +020050 * 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.
Willy Tarreau54469402006-07-29 16:59:06 +020052 */
Willy Tarreaue393fe22008-08-16 22:18:07 +020053
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020054#define CF_READ_NULL 0x00000001 /* last read detected on producer side */
Christopher Fauletdf994082021-09-23 14:17:20 +020055#define CF_READ_PARTIAL 0x00000002 /* some data were read from producer or a read exception occurred */
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020056#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)
Willy Tarreau0f9f5052006-07-29 17:39:25 +020059
Christopher Faulet22dc2482019-07-16 14:43:08 +020060/* unused: 0x00000010 */
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020061#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 */
Willy Tarreau54469402006-07-29 16:59:06 +020064
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020065#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)
Willy Tarreau54469402006-07-29 16:59:06 +020070
Willy Tarreaud7ad9f52013-12-31 17:26:25 +010071#define CF_WAKE_WRITE 0x00001000 /* wake the task up when there's write activity */
Willy Tarreau03cdb7c2012-08-27 23:14:58 +020072#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 */
Willy Tarreau54469402006-07-29 16:59:06 +020075
Willy Tarreaub31c9712012-11-11 23:05:39 +010076/* 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.
Willy Tarreau418fd472009-09-06 21:37:23 +020080 *
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 *
Willy Tarreau520d95e2009-09-19 21:04:57 +020095 * The SHUTW_NOW flag should be set by the session processor when SHUTR and AUTO_CLOSE
Willy Tarreaub31c9712012-11-11 23:05:39 +010096 * are both set. And it may also be set by the producer when it detects SHUTR while
97 * directly forwarding data to the consumer.
Willy Tarreau418fd472009-09-06 21:37:23 +020098 *
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
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200103#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 */
Willy Tarreau0f9f5052006-07-29 17:39:25 +0200105
Willy Tarreau9dc1c612014-09-01 20:35:55 +0200106#define CF_WROTE_DATA 0x00040000 /* some data were sent from this buffer */
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200107#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 */
Willy Tarreau9a2d1542008-08-30 12:31:07 +0200112
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200113#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) */
Willy Tarreauf1ba4b32009-10-17 14:37:52 +0200117
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200118#define CF_WAKE_ONCE 0x10000000 /* pretend there is activity on this channel (one-shoot) */
Christopher Faulete6006242017-03-10 11:52:44 +0100119#define CF_FLT_ANALYZE 0x20000000 /* at least one filter is still analyzing this channel */
Christopher Faulet297d3e22019-03-22 14:16:14 +0100120#define CF_EOI 0x40000000 /* end-of-input has been reached */
Willy Tarreauef573c02014-11-28 14:17:09 +0100121#define CF_ISRESP 0x80000000 /* 0 = request channel, 1 = response channel */
Willy Tarreau0499e352010-12-17 07:13:42 +0100122
Willy Tarreaufe3718a2008-11-30 18:14:12 +0100123/* Masks which define input events for stream analysers */
Willy Tarreauede3d882018-10-24 17:17:56 +0200124#define CF_MASK_ANALYSER (CF_READ_ATTACHED|CF_READ_ACTIVITY|CF_READ_TIMEOUT|CF_ANA_TIMEOUT|CF_WRITE_ACTIVITY|CF_WAKE_ONCE)
Willy Tarreaufe3718a2008-11-30 18:14:12 +0100125
Willy Tarreau1d315ea2010-06-04 12:25:31 +0200126/* Mask for static flags which cause analysers to be woken up when they change */
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200127#define CF_MASK_STATIC (CF_SHUTR|CF_SHUTW|CF_SHUTR_NOW|CF_SHUTW_NOW)
Willy Tarreau3da77c52008-08-29 09:58:42 +0200128
Willy Tarreau2df28e82008-08-17 15:20:19 +0200129
Willy Tarreauc7e42382012-08-24 19:22:53 +0200130/* Analysers (channel->analysers).
Willy Tarreau2df28e82008-08-17 15:20:19 +0200131 * Those bits indicate that there are some processing to do on the buffer
Willy Tarreau70cb6332008-12-07 11:28:08 +0100132 * contents. It will probably evolve into a linked list later. Those
Willy Tarreau2df28e82008-08-17 15:20:19 +0200133 * analysers could be compared to higher level processors.
Willy Tarreau8263d2b2012-08-28 00:06:31 +0200134 * The field is blanked by channel_init() and only by analysers themselves
Willy Tarreau2df28e82008-08-17 15:20:19 +0200135 * afterwards.
136 */
Christopher Faulet0184ea72017-01-05 14:06:34 +0100137/* AN_REQ_FLT_START_FE: 0x00000001 */
Willy Tarreau6e595772010-10-15 14:12:12 +0200138#define AN_REQ_INSPECT_FE 0x00000002 /* inspect request contents in the frontend */
139#define AN_REQ_WAIT_HTTP 0x00000004 /* wait for an HTTP request */
Willy Tarreau748179e2015-05-01 21:52:31 +0200140#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 */
Christopher Faulet0184ea72017-01-05 14:06:34 +0100143/* 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 */
Willy Tarreau4a5cade2012-04-05 21:09:48 +0200149#define AN_REQ_PRST_RDP_COOKIE 0x00001000 /* persistence on rdp cookie */
Christopher Faulet0184ea72017-01-05 14:06:34 +0100150#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 */
William Lallemand90b1ca12018-10-26 14:47:46 +0200153#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 */
Willy Tarreau2df28e82008-08-17 15:20:19 +0200157
Willy Tarreaub37c27e2009-10-18 22:53:08 +0200158/* response analysers */
William Lallemand90b1ca12018-10-26 14:47:46 +0200159/* 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 */
Willy Tarreaub37c27e2009-10-18 22:53:08 +0200172
William Lallemand90b1ca12018-10-26 14:47:46 +0200173/* filters interleaved with analysers, see above */
Christopher Faulet0184ea72017-01-05 14:06:34 +0100174#define AN_REQ_FLT_START_FE 0x00000001
175#define AN_REQ_FLT_START_BE 0x00000040
176#define AN_REQ_FLT_HTTP_HDRS 0x00004000
William Lallemand90b1ca12018-10-26 14:47:46 +0200177#define AN_REQ_FLT_XFER_DATA 0x00020000
178#define AN_REQ_FLT_END 0x00040000
Willy Tarreaub37c27e2009-10-18 22:53:08 +0200179
William Lallemand90b1ca12018-10-26 14:47:46 +0200180#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
William Lallemandcf62f7e2018-10-26 14:47:40 +0200185
Willy Tarreau31971e52009-09-20 12:07:52 +0200186/* Magic value to forward infinite size (TCP, ...), used with ->to_forward */
Willy Tarreau983eb312013-12-28 19:16:26 +0100187#define CHN_INFINITE_FORWARD MAX_RANGE(unsigned int)
Willy Tarreau31971e52009-09-20 12:07:52 +0200188
Willy Tarreau01bf8672008-12-07 18:03:29 +0100189
Willy Tarreau7421efb2012-07-02 15:11:27 +0200190struct channel {
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200191 unsigned int flags; /* CF_* */
Willy Tarreau0a8535f2012-10-13 10:05:56 +0200192 unsigned int analysers; /* bit field indicating what to do on the channel */
Willy Tarreauc9fa0482018-07-10 17:43:27 +0200193 struct buffer buf; /* buffer attached to the channel, always present but may move */
Willy Tarreau0a8535f2012-10-13 10:05:56 +0200194 struct pipe *pipe; /* non-NULL only when data present */
Olivier Houchard08afac02018-06-22 19:26:39 +0200195 size_t output; /* part of buffer which is to be forwarded */
Willy Tarreau0a8535f2012-10-13 10:05:56 +0200196 unsigned int to_forward; /* number of bytes to forward after out without a wake-up */
Willy Tarreaub145c782014-02-09 17:45:16 +0100197 unsigned short last_read; /* 16 lower bits of last read date (max pause=65s) */
Willy Tarreau0a8535f2012-10-13 10:05:56 +0200198 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 */
Willy Tarreau0c303ee2008-07-07 00:09:58 +0200201 int rex; /* expiration date for a read, in ticks */
Willy Tarreau26ed74d2008-08-17 12:11:14 +0200202 int wex; /* expiration date for a write or connect, in ticks */
Willy Tarreau0c303ee2008-07-07 00:09:58 +0200203 int rto; /* read timeout, in ticks */
204 int wto; /* write timeout, in ticks */
Willy Tarreau0a8535f2012-10-13 10:05:56 +0200205 int analyse_exp; /* expiration date for current analysers (if set) */
Willy Tarreaubaaee002006-06-26 02:48:02 +0200206};
207
Willy Tarreau03cdb7c2012-08-27 23:14:58 +0200208
209/* Note about the channel structure
Tim Duesterhus73866682021-06-19 16:56:30 +0200210 *
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.
Willy Tarreau0abebcc2009-01-08 00:09:41 +0100302 */
303
Willy Tarreauf1d32c42020-06-04 21:07:02 +0200304#endif /* _HAPROXY_CHANNEL_T_H */
Willy Tarreaubaaee002006-06-26 02:48:02 +0200305
306/*
307 * Local variables:
308 * c-indent-level: 8
309 * c-basic-offset: 8
310 * End:
311 */