upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-02-18 10:08:36 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 8
haproxy/include/types/connection.h

613 lines
28 KiB
C
Raw Normal View History

REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
/*
* include/types/connection.h
* This file describes the connection struct and associated constants.
*
CLEANUP: connection: fix comments in connection.h to reflect new behaviour. The polling has substantially changed, better fix the comments.
2014-01-23 09:26:18 -05:00
* Copyright (C) 2000-2014 Willy Tarreau - w@1wt.eu
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation, version 2.1
* exclusively.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#ifndef _TYPES_CONNECTION_H
#define _TYPES_CONNECTION_H
#include <stdlib.h>
#include <sys/socket.h>
#include <common/config.h>
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 13:40:52 -04:00
#include <common/ist.h>
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
REORG: split "protocols" files into protocol and listener It was becoming confusing to have protocols and listeners in the same files, split them.
2012-09-12 16:58:11 -04:00
#include <types/listener.h>
MAJOR: connection: replace struct target with a pointer to an enum Instead of storing a couple of (int, ptr) in the struct connection and the struct session, we use a different method : we only store a pointer to an integer which is stored inside the target object and which contains a unique type identifier. That way, the pointer allows us to retrieve the object type (by dereferencing it) and the object's address (by computing the displacement in the target structure). The NULL pointer always corresponds to OBJ_TYPE_NONE. This reduces the size of the connection and session structs. It also simplifies target assignment and compare. In order to improve the generated code, we try to put the obj_type element at the beginning of all the structs (listener, server, proxy, si_applet), so that the original and target pointers are always equal. A lot of code was touched by massive replaces, but the changes are not that important.
2012-11-11 18:42:33 -05:00
#include <types/obj_type.h>
MEDIUM: connection: introduce "struct conn_src" for servers and proxies Both servers and proxies share a common set of parameters for outgoing connections, and since they're not stored in a similar structure, a lot of code is duplicated in the connection setup, which is one sensible area. Let's first define a common struct for these settings and make use of it. Next patches will de-duplicate code. This change also fixes a build breakage that happens when USE_LINUX_TPROXY is not set but USE_CTTPROXY is set, which seem to be very unlikely considering that the issue was introduced almost 2 years ago an never reported.
2012-12-08 16:29:20 -05:00
#include <types/port_range.h>
REORG: split "protocols" files into protocol and listener It was becoming confusing to have protocols and listeners in the same files, split them.
2012-09-12 16:58:11 -04:00
#include <types/protocol.h>
BUILD: connection: fix build breakage on openbsd due to missing in_systm.h Recent commit 93b227d ("MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword") introduced an include of netinet/ip.h which requires in_systm.h on OpenBSD. No backport is needed.
2016-08-10 12:57:38 -04:00
#include <netinet/in_systm.h>
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
#include <netinet/ip.h>
#include <netinet/ip6.h>
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
/* referenced below */
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
struct connection;
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
struct conn_stream;
MEDIUM: conn_stream: Add a way to get mux's info on a CS from the upper layer Time to time, the need arises to get some info owned by the multiplexer about a connection stream from the upper layer. Today we really need to get some dates and durations specific to the conn_stream. It is only true for the mux H1 and H2. Otherwise it will be impossible to have correct times reported in the logs. To do so, the structure cs_info has been defined to provide all info we ever need on a conn_stream from the upper layer. Of course, it is the first step. So this structure will certainly envloved. But for now, only the bare minimum is referenced. On the mux side, the callback get_cs_info() has been added in the structure mux_ops. Multiplexers can now implement it, if necessary, to return a pointer on a structure cs_info. And finally, the function si_get_cs_info() should be used from the upper layer. If the stream interface is not attached to a connection stream, this function returns NULL, likewise if the callback get_cs_info() is not defined for the corresponding mux.
2018-11-29 05:29:26 -05:00
struct cs_info;
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
struct buffer;
MINOR: connection: pass the proxy when creating a connection Till now it was very difficult for a mux to know what proxy it was working for. Let's pass the proxy when the mux is instanciated at init() time. It's not yet used but the H1 mux will definitely need it, just like the H2 mux when dealing with backend connections.
2018-09-12 06:02:05 -04:00
struct proxy;
MINOR: connection: add new prepare_srv()/destroy_srv() entries to xprt_ops These one will be used by the SSL layer to prepare and destroy a server-side SSL context.
2016-12-22 15:13:18 -05:00
struct server;
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 13:42:40 -05:00
struct session;
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
struct pipe;
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
/* socks4 upstream proxy definitions */
struct socks4_request {
uint8_t version; /* SOCKS version number, 1 byte, must be 0x04 for this version */
uint8_t command; /* 0x01 = establish a TCP/IP stream connection */
uint16_t port; /* port number, 2 bytes (in network byte order) */
uint32_t ip; /* IP address, 4 bytes (in network byte order) */
char user_id[8]; /* the user ID string, variable length, terminated with a null (0x00); Using "HAProxy\0" */
};
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
/* Note: subscribing to these events is only valid after the caller has really
* attempted to perform the operation, and failed to proceed or complete.
*/
MINOR: connections/mux: Add the wait reason(s) to wait_list. Add a new element to the wait_list, that let us know which event(s) we are waiting on.
2018-08-01 11:06:43 -04:00
enum sub_event_type {
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
SUB_RETRY_RECV = 0x00000001, /* Schedule the tasklet when we can attempt to recv again */
SUB_RETRY_SEND = 0x00000002, /* Schedule the tasklet when we can attempt to send again */
MINOR: connections/mux: Add the wait reason(s) to wait_list. Add a new element to the wait_list, that let us know which event(s) we are waiting on.
2018-08-01 11:06:43 -04:00
};
MEDIUM: connection: merge the send_wait and recv_wait entries In practice all callers use the same wait_event notification for any I/O so instead of keeping specific code to handle them separately, let's merge them and it will allow us to create new events later.
2020-01-10 01:06:05 -05:00
/* Describes a set of subscriptions. Multiple events may be registered at the
* same time. The callee should assume everything not pending for completion is
* implicitly possible. It's illegal to change the tasklet if events are still
* registered.
*/
MEDIUM: connections: Change struct wait_list to wait_event. When subscribing, we don't need to provide a list element, only the h2 mux needs it. So instead, Add a list element to struct h2s, and use it when a list is needed. This forces us to use the unsubscribe method, since we can't just unsubscribe by using LIST_DEL anymore. This patch is larger than it should be because it includes some renaming.
2018-10-10 12:25:41 -04:00
struct wait_event {
CLEANUP: connection: rename the wait_event.task field to .tasklet It's really confusing to call it a task because it's a tasklet and used in places where tasks and tasklets are used together. Let's rename it to tasklet to remove this confusion.
2019-06-14 08:42:29 -04:00
struct tasklet *tasklet;
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
int events; /* set of enum sub_event_type above */
MINOR: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 12:46:31 -04:00
};
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 08:31:19 -04:00
DOC: Fix a few typos these are mostly spelling mistakes, some of them might be candidate for backporting as well.
2018-10-13 11:06:18 -04:00
/* A connection handle is how we differentiate two connections on the lower
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 08:31:19 -04:00
* layers. It usually is a file descriptor but can be a connection id.
*/
union conn_handle {
int fd; /* file descriptor, for regular sockets */
};
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
/* conn_stream flags */
enum {
CS_FL_NONE = 0x00000000, /* Just for initialization purposes */
MINOR: conn_stream: new shutr/w status flags In order to support all shutdown modes on the CS, we introduce the following flags : CS_FL_SHRD : shut read, drain extra data CS_FL_SHRR : shut read, reset extra data CS_FL_SHWN : shut write, normal notification CS_FL_SHWS : shut write, silent mode (no notification) And the following modes for shutr/shutw : CS_SHR_DRAIN, CS_SHR_RESET, CS_SHW_NORMAL, CS_SHW_SILENT. Note: it's possible that we won't need to distinguish the two shutw above as they're only an action. For now they are not used.
2017-10-05 09:06:07 -04:00
CS_FL_SHRD = 0x00000010, /* read shut, draining extra data */
CS_FL_SHRR = 0x00000020, /* read shut, resetting extra data */
CS_FL_SHR = CS_FL_SHRD | CS_FL_SHRR, /* read shut status */
CS_FL_SHWN = 0x00000040, /* write shut, verbose mode */
CS_FL_SHWS = 0x00000080, /* write shut, silent mode */
CS_FL_SHW = CS_FL_SHWN | CS_FL_SHWS, /* write shut status */
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
CS_FL_ERROR = 0x00000100, /* a fatal error was reported */
BUG/MEDIUM: connections: Split CS_FL_RCV_MORE into 2 flags. CS_FL_RCV_MORE is used in two cases, to let the conn_stream know there may be more data available, and to let it know that it needs more room. We can't easily differentiate between the two, and that may leads to hangs, so split it into two flags, CS_FL_RCV_MORE, that means there may be more data, and CS_FL_WANT_ROOM, that means we need more room. This should not be backported.
2018-12-06 10:22:29 -05:00
CS_FL_RCV_MORE = 0x00000200, /* We may have more bytes to transfert */
CS_FL_WANT_ROOM = 0x00000400, /* More bytes to transfert, but not enough room */
BUG/MEDIUM: connection: Add a new CS_FL_ERR_PENDING flag to conn_streams. Add a new flag to conn_streams, CS_FL_ERR_PENDING. This is to be set instead of CS_FL_ERR in case there's still more data to be read, so that we read all the data before closing.
2018-12-17 08:16:46 -05:00
CS_FL_ERR_PENDING = 0x00000800, /* An error is pending, but there's still data to be read */
MINOR: conn_stream: add a new CS_FL_REOS flag This flag indicates that the mux layer has already detected an end of stream which will become CS_FL_EOS during a recv() once the rx buffer is empty.
2018-03-02 06:25:45 -05:00
CS_FL_EOS = 0x00001000, /* End of stream delivered to data layer */
CLEANUP: connection: remove the now unused CS_FL_REOS flag Let's remove it before it gets uesd again. It was mostly replaced with CS_FL_EOI and by mux-specific states or flags.
2019-06-03 08:23:33 -04:00
/* unused: 0x00002000 */
CLEANUP: muxes/stream-int: Remove flags CS_FL_READ_NULL and SI_FL_READ_NULL Since the flag CF_SHUTR is no more set to mark the end of the message, these flags become useless. This patch should be backported to 1.9.
2019-03-22 09:51:36 -04:00
CS_FL_EOI = 0x00004000, /* end-of-input reached */
BUG/MEDIUM: connection: add a mux flag to indicate splice usability Commit c640ef1a7d ("BUG/MINOR: stream-int: avoid calling rcv_buf() when splicing is still possible") fixed splicing in TCP and legacy mode but broke it badly in HTX mode. What happens in HTX mode is that the channel's to_forward value remains set to CHN_INFINITE_FORWARD during the whole transfer, and as such it is not a reliable signal anymore to indicate whether more data are expected or not. Thus, when data are spliced out of the mux using rcv_pipe(), even when the end is reached (that only the mux knows about), the call to rcv_buf() to get the final HTX blocks completing the message were skipped and there was often no new event to wake this up, resulting in transfer timeouts at the end of large objects. All this goes down to the fact that the channel has no more information about whether it can splice or not despite being the one having to take the decision to call rcv_pipe() or not. And we cannot afford to call rcv_buf() inconditionally because, as the commit above showed, this reduces the forwarding performance by 2 to 3 in TCP and legacy modes due to data lying in the buffer preventing splicing from being used later. The approach taken by this patch consists in offering the muxes the ability to report a bit more information to the upper layers via the conn_stream. This information could simply be to indicate that more data are awaited but the real need being to distinguish splicing and receiving, here instead we clearly report the mux's willingness to be called for splicing or not. Hence the flag's name, CS_FL_MAY_SPLICE. The mux sets this flag when it knows that its buffer is empty and that data waiting past what is currently known may be spliced, and clears it when it knows there's no more data or that the caller must fall back to rcv_buf() instead. The stream-int code now uses this to determine if splicing may be used or not instead of looking at the rcv_pipe() callbacks through the whole chain. And after the rcv_pipe() call, it checks the flag again to decide whether it may safely skip rcv_buf() or not. All this bitfield dance remains a bit complex and it starts to appear obvious that splicing vs reading should be a decision of the mux based on permission granted by the data layer. This would however increase the API's complexity but definitely need to be thought about, and should even significantly simplify the data processing layer. The way it was integrated in mux-h1 will also result in no more calls to rcv_pipe() on chunked encoded data, since these ones are currently disabled at the mux level. However once the issue with chunks+splice is fixed, it will be important to explicitly check for curr_len|CHNK to set MAY_SPLICE, so that we don't call rcv_buf() after each chunk. This fix must be backported to 2.1 and 2.0.
2020-01-17 10:19:34 -05:00
CS_FL_MAY_SPLICE = 0x00008000, /* caller may use rcv_pipe() only if this flag is set */
MINOR: early data: Don't rely on CO_FL_EARLY_DATA to wake up streams. Instead of looking for CO_FL_EARLY_DATA to know if we have to try to wake up a stream, because it is waiting for a SSL handshake, instead add a new conn_stream flag, CS_FL_WAIT_FOR_HS. This way we don't have to rely on CO_FL_EARLY_DATA, and we will only wake streams that are actually waiting.
2017-11-27 12:41:32 -05:00
CS_FL_WAIT_FOR_HS = 0x00010000, /* This stream is waiting for handhskae */
MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection This is the equivalent of SI_FL_KILL_CONN but for the connstreams. It will be set by the stream-interface during the various shutdown operations.
2019-01-31 13:09:59 -05:00
CS_FL_KILL_CONN = 0x00020000, /* must kill the connection when the CS closes */
MINOR: conn-stream: Add CL_FL_NOT_FIRST flag This flags will be used by multiplexers to warn a conn-stream (and, by transitivity, a stream) it is not the first one created by the mux. It will help mux H1 to handle keep-alive connections.
2018-10-01 06:10:13 -04:00
MINOR: conn_stream: Add a flag to notify the SI some data were received The flag CS_FL_READ_PARTIAL can be set by the mux on the conn_stream to notify the stream interface that some data were received. Is is used in si_cs_recv to re-arm read timeout on the channel.
2018-10-31 03:53:54 -04:00
/* following flags are supposed to be set by the mux and read/unset by
* the stream-interface :
*/
CS_FL_NOT_FIRST = 0x00100000, /* this stream is not the first one */
CLEANUP: Fix a typo in the connection subsystem Fixes a typo in the code comments of the connection subsystem.
2018-11-25 16:21:12 -05:00
CS_FL_READ_PARTIAL = 0x00200000, /* some data were received (not necessarily xferred) */
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
};
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 08:31:19 -04:00
MINOR: conn_stream: new shutr/w status flags In order to support all shutdown modes on the CS, we introduce the following flags : CS_FL_SHRD : shut read, drain extra data CS_FL_SHRR : shut read, reset extra data CS_FL_SHWN : shut write, normal notification CS_FL_SHWS : shut write, silent mode (no notification) And the following modes for shutr/shutw : CS_SHR_DRAIN, CS_SHR_RESET, CS_SHW_NORMAL, CS_SHW_SILENT. Note: it's possible that we won't need to distinguish the two shutw above as they're only an action. For now they are not used.
2017-10-05 09:06:07 -04:00
/* cs_shutr() modes */
enum cs_shr_mode {
CS_SHR_DRAIN = 0, /* read shutdown, drain any extra stuff */
CS_SHR_RESET = 1, /* read shutdown, reset any extra stuff */
};
/* cs_shutw() modes */
enum cs_shw_mode {
CS_SHW_NORMAL = 0, /* regular write shutdown */
CS_SHW_SILENT = 1, /* imminent close, don't notify peer */
};
MEDIUM: connection: get rid of CO_FL_CURR_* flags These ones used to serve as a set of switches between CO_FL_SOCK_* and CO_FL_XPRT_*, and now that the SOCK layer is gone, they're always a copy of the last know CO_FL_XPRT_* ones that is resynchronized before I/O events by calling conn_refresh_polling_flags(), and that are pushed back to FDs when detecting changes with conn_xprt_polling_changes(). While these functions are not particularly heavy, what they do is totally redundant by now because the fd_want_*/fd_stop_*() actions already perform test-and-set operations to decide to create an entry or not, so they do the exact same thing that is done by conn_xprt_polling_changes(). As such it is pointless to call that one, and given that the only reason to keep CO_FL_CURR_* is to detect changes there, we can now remove them. Even if this does only save very few cycles, this removes a significant complexity that has been responsible for many bugs in the past, including the last one affecting FreeBSD. All tests look good, and no performance regressions were observed.
2020-01-17 11:39:35 -05:00
/* For each direction, we have a CO_FL_XPRT_<DIR>_ENA flag, which
CLEANUP: connection: fix comments in connection.h to reflect new behaviour. The polling has substantially changed, better fix the comments.
2014-01-23 09:26:18 -05:00
* indicates if read or write is desired in that direction for the respective
* layers. The current status corresponding to the current layer being used is
MEDIUM: connection: get rid of CO_FL_CURR_* flags These ones used to serve as a set of switches between CO_FL_SOCK_* and CO_FL_XPRT_*, and now that the SOCK layer is gone, they're always a copy of the last know CO_FL_XPRT_* ones that is resynchronized before I/O events by calling conn_refresh_polling_flags(), and that are pushed back to FDs when detecting changes with conn_xprt_polling_changes(). While these functions are not particularly heavy, what they do is totally redundant by now because the fd_want_*/fd_stop_*() actions already perform test-and-set operations to decide to create an entry or not, so they do the exact same thing that is done by conn_xprt_polling_changes(). As such it is pointless to call that one, and given that the only reason to keep CO_FL_CURR_* is to detect changes there, we can now remove them. Even if this does only save very few cycles, this removes a significant complexity that has been responsible for many bugs in the past, including the last one affecting FreeBSD. All tests look good, and no performance regressions were observed.
2020-01-17 11:39:35 -05:00
* remembered in the CO_FL_XPRT_<DIR>_ENA flag. The need to poll (ie receipt of
CLEANUP: connection: fix comments in connection.h to reflect new behaviour. The polling has substantially changed, better fix the comments.
2014-01-23 09:26:18 -05:00
* EAGAIN) is remembered at the file descriptor level so that even when the
* activity is stopped and restarted, we still remember whether it was needed
* to poll before attempting the I/O.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
*
MEDIUM: connection: get rid of CO_FL_CURR_* flags These ones used to serve as a set of switches between CO_FL_SOCK_* and CO_FL_XPRT_*, and now that the SOCK layer is gone, they're always a copy of the last know CO_FL_XPRT_* ones that is resynchronized before I/O events by calling conn_refresh_polling_flags(), and that are pushed back to FDs when detecting changes with conn_xprt_polling_changes(). While these functions are not particularly heavy, what they do is totally redundant by now because the fd_want_*/fd_stop_*() actions already perform test-and-set operations to decide to create an entry or not, so they do the exact same thing that is done by conn_xprt_polling_changes(). As such it is pointless to call that one, and given that the only reason to keep CO_FL_CURR_* is to detect changes there, we can now remove them. Even if this does only save very few cycles, this removes a significant complexity that has been responsible for many bugs in the past, including the last one affecting FreeBSD. All tests look good, and no performance regressions were observed.
2020-01-17 11:39:35 -05:00
* The FD state is updated according to CO_FL_XPRT_<DIR>_ENA in
* conn_cond_update_polling().
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
*/
MINOR: connection: add flags to the connection struct We're doing this to take over fdtab[].state.
2012-07-06 03:52:14 -04:00
/* flags for use in connection->flags */
enum {
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
CO_FL_NONE = 0x00000000, /* Just for initialization purposes */
/* Do not change these values without updating conn_*_poll_changes() ! */
MINOR: connections: Add a flag to know if we're in the safe or idle list. Add flags to connections, CO_FL_SAFE_LIST and CO_FL_IDLE_LIST, to let one know we are in the safe list, or the idle list.
2020-03-10 13:04:37 -04:00
CO_FL_SAFE_LIST = 0x00000001, /* 0 = not in any list, 1 = in safe_list */
CO_FL_IDLE_LIST = 0x00000002, /* 2 = in idle_list, 3 = invalid */
CO_FL_LIST_MASK = 0x00000003, /* Is the connection in any server-managed list ? */
MEDIUM: connection: get rid of CO_FL_CURR_* flags These ones used to serve as a set of switches between CO_FL_SOCK_* and CO_FL_XPRT_*, and now that the SOCK layer is gone, they're always a copy of the last know CO_FL_XPRT_* ones that is resynchronized before I/O events by calling conn_refresh_polling_flags(), and that are pushed back to FDs when detecting changes with conn_xprt_polling_changes(). While these functions are not particularly heavy, what they do is totally redundant by now because the fd_want_*/fd_stop_*() actions already perform test-and-set operations to decide to create an entry or not, so they do the exact same thing that is done by conn_xprt_polling_changes(). As such it is pointless to call that one, and given that the only reason to keep CO_FL_CURR_* is to detect changes there, we can now remove them. Even if this does only save very few cycles, this removes a significant complexity that has been responsible for many bugs in the past, including the last one affecting FreeBSD. All tests look good, and no performance regressions were observed.
2020-01-17 11:39:35 -05:00
/* unused : 0x00000004, 0x00000008 */
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
MEDIUM: connections: Remove CONN_FL_SOCK* Now that the various handshakes come with their own XPRT, there's no need for the CONN_FL_SOCK* flags, and the conn_sock_want|stop functions, so garbage-collect them.
2019-05-28 04:12:02 -04:00
/* unused : 0x00000010 */
MEDIUM: connection: remove the intermediary polling state from the connection Historically we used to require that the connections held the desired polling states for the data layer and the socket layer. Then with muxes these were more or less merged into the transport layer, and now it happens that with all transport layers having their own state, the "transport layer state" as we have it in the connection (XPRT_RD_ENA, XPRT_WR_ENA) is only an exact copy of the undelying file descriptor state, but with a delay. All of this is causing some difficulties at many places in the code because there are still some locations which use the conn_want_* API to remain clean and only rely on connection, and count on a later collection call to conn_cond_update_polling(), while others need an immediate action and directly use the FD updates. Since our updates are now much cheaper, most of them being only an atomic test-and-set operation, and since our I/O callbacks are deferred, there's no benefit anymore in trying to "cache" the transient state change in the connection flags hoping to cancel them before they become an FD event. Better make such calls transparent indirections to the FD layer instead and get rid of the deferred operations which needlessly complicate the logic inside. This removes flags CO_FL_XPRT_{RD,WR}_ENA and CO_FL_WILL_UPDATE. A number of functions related to polling updates were either greatly simplified or removed. Two places were using CO_FL_XPRT_WR_ENA as a hint to know if more data were expected to be sent after a PROXY protocol or SOCKSv4 header. These ones were simply replaced with a check on the subscription which is where we ought to get the autoritative information from. Now the __conn_xprt_want_* and their conn_xprt_want_* counterparts are the same. conn_stop_polling() and conn_xprt_stop_both() are the same as well. conn_cond_update_polling() only causes errors to stop polling. It also becomes way more obvious that muxes should not at all employ conn_xprt_{want|stop}_{recv,send}(), and that the call to __conn_xprt_stop_recv() in case a mux failed to allocate a buffer is inappropriate, it ought to unsubscribe from reads instead. All of this definitely requires a serious cleanup.
2020-02-21 02:46:19 -05:00
/* unused : 0x00000020 */
MEDIUM: connection: get rid of CO_FL_CURR_* flags These ones used to serve as a set of switches between CO_FL_SOCK_* and CO_FL_XPRT_*, and now that the SOCK layer is gone, they're always a copy of the last know CO_FL_XPRT_* ones that is resynchronized before I/O events by calling conn_refresh_polling_flags(), and that are pushed back to FDs when detecting changes with conn_xprt_polling_changes(). While these functions are not particularly heavy, what they do is totally redundant by now because the fd_want_*/fd_stop_*() actions already perform test-and-set operations to decide to create an entry or not, so they do the exact same thing that is done by conn_xprt_polling_changes(). As such it is pointless to call that one, and given that the only reason to keep CO_FL_CURR_* is to detect changes there, we can now remove them. Even if this does only save very few cycles, this removes a significant complexity that has been responsible for many bugs in the past, including the last one affecting FreeBSD. All tests look good, and no performance regressions were observed.
2020-01-17 11:39:35 -05:00
/* unused : 0x00000040, 0x00000080 */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
/* These flags indicate whether the Control and Transport layers are initialized */
CO_FL_CTRL_READY = 0x00000100, /* FD was registered, fd_delete() needed */
CO_FL_XPRT_READY = 0x00000200, /* xprt_init() done, xprt_close() needed */
MEDIUM: connection: remove the intermediary polling state from the connection Historically we used to require that the connections held the desired polling states for the data layer and the socket layer. Then with muxes these were more or less merged into the transport layer, and now it happens that with all transport layers having their own state, the "transport layer state" as we have it in the connection (XPRT_RD_ENA, XPRT_WR_ENA) is only an exact copy of the undelying file descriptor state, but with a delay. All of this is causing some difficulties at many places in the code because there are still some locations which use the conn_want_* API to remain clean and only rely on connection, and count on a later collection call to conn_cond_update_polling(), while others need an immediate action and directly use the FD updates. Since our updates are now much cheaper, most of them being only an atomic test-and-set operation, and since our I/O callbacks are deferred, there's no benefit anymore in trying to "cache" the transient state change in the connection flags hoping to cancel them before they become an FD event. Better make such calls transparent indirections to the FD layer instead and get rid of the deferred operations which needlessly complicate the logic inside. This removes flags CO_FL_XPRT_{RD,WR}_ENA and CO_FL_WILL_UPDATE. A number of functions related to polling updates were either greatly simplified or removed. Two places were using CO_FL_XPRT_WR_ENA as a hint to know if more data were expected to be sent after a PROXY protocol or SOCKSv4 header. These ones were simply replaced with a check on the subscription which is where we ought to get the autoritative information from. Now the __conn_xprt_want_* and their conn_xprt_want_* counterparts are the same. conn_stop_polling() and conn_xprt_stop_both() are the same as well. conn_cond_update_polling() only causes errors to stop polling. It also becomes way more obvious that muxes should not at all employ conn_xprt_{want|stop}_{recv,send}(), and that the call to __conn_xprt_stop_recv() in case a mux failed to allocate a buffer is inappropriate, it ought to unsubscribe from reads instead. All of this definitely requires a serious cleanup.
2020-02-21 02:46:19 -05:00
/* unused : 0x00000400 */
CLEANUP: connection: remove unused CO_FL_WAIT_DATA Very early in the connection rework process leading to v1.5-dev12, commit 56a77e5 ("MEDIUM: connection: complete the polling cleanups") marked the end of use for this flag which since was never set anymore, but it continues to be tested. Let's kill it now.
2017-04-26 10:25:12 -04:00
/* This flag is used by data layers to indicate they had to stop
* receiving data because a buffer was full. The connection handler
* clears it before first calling the I/O and data callbacks.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
*/
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
CO_FL_WAIT_ROOM = 0x00000800, /* data sink is full */
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
MAJOR: connection: move the addr field from the stream_interface We need to have the source and destination addresses in the connection. They were lying in the stream interface so let's move them. The flags SI_FL_FROM_SET and SI_FL_TO_SET have been moved as well. It's worth noting that tcp_connect_server() almost does not use the stream interface anymore except for a few flags. It has been identified that once we detach the connection from the SI, it will probably be needed to keep a copy of the server-side addresses in the SI just for logging purposes. This has not been implemented right now though.
2012-08-30 15:11:38 -04:00
/* These flags are used to report whether the from/to addresses are set or not */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
CO_FL_ADDR_FROM_SET = 0x00001000, /* addr.from is set */
CO_FL_ADDR_TO_SET = 0x00002000, /* addr.to is set */
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 12:26:28 -04:00
CO_FL_EARLY_SSL_HS = 0x00004000, /* We have early data pending, don't start SSL handshake yet */
CO_FL_EARLY_DATA = 0x00008000, /* At least some of the data are early data */
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
CO_FL_SOCKS4_SEND = 0x00010000, /* handshaking with upstream SOCKS4 proxy, going to send the handshake */
CO_FL_SOCKS4_RECV = 0x00020000, /* handshaking with upstream SOCKS4 proxy, going to check if handshake succeed */
MAJOR: raw_sock: extract raw_sock_to_buf() from raw_sock_read() This is the start of the stream connection iterator which calls the data-layer reader. This still looks a bit tricky but is OK. Splicing is not handled at all at the moment.
2012-08-20 11:30:32 -04:00
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
/* flags used to remember what shutdown have been performed/reported */
CO_FL_SOCK_RD_SH = 0x00040000, /* SOCK layer was notified about shutr/read0 */
CO_FL_SOCK_WR_SH = 0x00080000, /* SOCK layer asked for shutw */
BUG/MEDIUM: connection: ensure to always report the end of handshakes Despite the previous commit working fine on all tests, it's still not sufficient to completely address the problem. If the connection handler is called with an event validating an L4 connection but some handshakes remain (eg: accept-proxy), it will still wake the function up, which will not report the activity, and will not detect a change once the handshake it complete so it will not notify the ->wake() handler. In fact the only reason why the ->wake() handler is still called here is because after dropping the last handshake, we try to call ->recv() and ->send() in turn and change the flags in order to detect a data activity. But if for any reason the data layer is not interested in reading nor writing, it will not get these events. A cleaner way to address this is to call the ->wake() handler only on definitive status changes (shut, error), on real data activity, and on a complete connection setup, measured as CONNECTED with no more handshake pending. It could be argued that the handshake flags have to be made part of the condition to set CO_FL_CONNECTED but that would currently break a part of the health checks. Also a handshake could appear at any moment even after a connection is established so we'd lose the ability to detect a second end of handshake. For now the situation around CO_FL_CONNECTED is not clean : - session_accept() only sets CO_FL_CONNECTED if there's no pending handshake ; - conn_fd_handler() will set it once L4 and L6 are complete, which will do what session_accept() above refrained from doing even if an accept_proxy handshake is still pending ; - ssl_sock_infocbk() and ssl_sock_handshake() consider that a handshake performed with CO_FL_CONNECTED set is a renegociation ; => they should instead filter on CO_FL_WAIT_L6_CONN - all ssl_fc_* sample fetch functions wait for CO_FL_CONNECTED before accepting to fetch information => they should also get rid of any pending handshake - smp_fetch_fc_rcvd_proxy() uses !CO_FL_CONNECTED instead of CO_FL_ACCEPT_PROXY - health checks (standard and tcp-checks) don't check for HANDSHAKE and may report a successful check based on CO_FL_CONNECTED while not yet done (eg: send buffer full on send_proxy). This patch aims at solving some of these side effects in a backportable way before this is reworked in depth : - we need to call ->wake() to report connection success, measure connection time, notify that the data layer is ready and update the data layer after activity ; this has to be done either if we switch from pending {L4,L6}_CONN to nothing with no handshakes left, or if we notice some handshakes were pending and are now done. - we document that CO_FL_CONNECTED exactly means "L4 connection setup confirmed at least once, L6 connection setup confirmed at least once or not necessary, all this regardless of any possibly remaining handshakes or future L6 negociations". This patch also renames CO_FL_CONN_STATUS to the more explicit CO_FL_NOTIFY_DATA, and works around the previous flags trick consiting in setting an impossible combination of flags to notify the data layer, by simply clearing the current flags. This fix should be backported to 1.7, 1.6 and 1.5.
2017-03-19 02:54:28 -04:00
/* flags used to report connection errors or other closing conditions */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
CO_FL_ERROR = 0x00100000, /* a fatal error was reported */
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 09:46:01 -04:00
CO_FL_NOTIFY_DONE = 0x001C0000, /* any xprt shut/error flags above needs to be reported */
BUG/MEDIUM: connection: ensure to always report the end of handshakes Despite the previous commit working fine on all tests, it's still not sufficient to completely address the problem. If the connection handler is called with an event validating an L4 connection but some handshakes remain (eg: accept-proxy), it will still wake the function up, which will not report the activity, and will not detect a change once the handshake it complete so it will not notify the ->wake() handler. In fact the only reason why the ->wake() handler is still called here is because after dropping the last handshake, we try to call ->recv() and ->send() in turn and change the flags in order to detect a data activity. But if for any reason the data layer is not interested in reading nor writing, it will not get these events. A cleaner way to address this is to call the ->wake() handler only on definitive status changes (shut, error), on real data activity, and on a complete connection setup, measured as CONNECTED with no more handshake pending. It could be argued that the handshake flags have to be made part of the condition to set CO_FL_CONNECTED but that would currently break a part of the health checks. Also a handshake could appear at any moment even after a connection is established so we'd lose the ability to detect a second end of handshake. For now the situation around CO_FL_CONNECTED is not clean : - session_accept() only sets CO_FL_CONNECTED if there's no pending handshake ; - conn_fd_handler() will set it once L4 and L6 are complete, which will do what session_accept() above refrained from doing even if an accept_proxy handshake is still pending ; - ssl_sock_infocbk() and ssl_sock_handshake() consider that a handshake performed with CO_FL_CONNECTED set is a renegociation ; => they should instead filter on CO_FL_WAIT_L6_CONN - all ssl_fc_* sample fetch functions wait for CO_FL_CONNECTED before accepting to fetch information => they should also get rid of any pending handshake - smp_fetch_fc_rcvd_proxy() uses !CO_FL_CONNECTED instead of CO_FL_ACCEPT_PROXY - health checks (standard and tcp-checks) don't check for HANDSHAKE and may report a successful check based on CO_FL_CONNECTED while not yet done (eg: send buffer full on send_proxy). This patch aims at solving some of these side effects in a backportable way before this is reworked in depth : - we need to call ->wake() to report connection success, measure connection time, notify that the data layer is ready and update the data layer after activity ; this has to be done either if we switch from pending {L4,L6}_CONN to nothing with no handshakes left, or if we notice some handshakes were pending and are now done. - we document that CO_FL_CONNECTED exactly means "L4 connection setup confirmed at least once, L6 connection setup confirmed at least once or not necessary, all this regardless of any possibly remaining handshakes or future L6 negociations". This patch also renames CO_FL_CONN_STATUS to the more explicit CO_FL_NOTIFY_DATA, and works around the previous flags trick consiting in setting an impossible combination of flags to notify the data layer, by simply clearing the current flags. This fix should be backported to 1.7, 1.6 and 1.5.
2017-03-19 02:54:28 -04:00
/* flags used to report connection status updates */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
CO_FL_WAIT_L4_CONN = 0x00400000, /* waiting for L4 to be connected */
CO_FL_WAIT_L6_CONN = 0x00800000, /* waiting for L6 to be connected (eg: SSL) */
MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_* Commit 477902bd2e ("MEDIUM: connections: Get ride of the xprt_done callback.") broke the master CLI for a very obscure reason. It happens that short requests immediately terminated by a shutdown are properly received, CS_FL_EOS is correctly set, but in si_cs_recv(), we refrain from setting CF_SHUTR on the channel because CO_FL_CONNECTED was not yet set on the connection since we've not passed again through conn_fd_handler() and it was not done in conn_complete_session(). While commit a8a415d31a ("BUG/MEDIUM: connections: Set CO_FL_CONNECTED in conn_complete_session()") fixed the issue, such accident may happen again as the root cause is deeper and actually comes down to the fact that CO_FL_CONNECTED is lazily set at various check points in the code but not every time we drop one wait bit. It is not the first time we face this situation. Originally this flag was used to detect the transition between WAIT_* and CONNECTED in order to call ->wake() from the FD handler. But since at least 1.8-dev1 with commit 7bf3fa3c23 ("BUG/MAJOR: connection: update CO_FL_CONNECTED before calling the data layer"), CO_FL_CONNECTED is always synchronized against the two others before being checked. Moreover, with the I/Os moved to tasklets, the decision to call the ->wake() function is performed after the I/Os in si_cs_process() and equivalent, which don't care about this transition either. So in essence, checking for CO_FL_CONNECTED has become a lazy wait to check for (CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN), but that always relies on someone else having synchronized it. This patch addresses it once for all by killing this flag and only checking the two others (for which a composite mask CO_FL_WAIT_L4L6 was added). This revealed a number of inconsistencies that were purposely not addressed here for the sake of bisectability: - while most places do check both L4+L6 and HANDSHAKE at the same time, some places like assign_server() or back_handle_st_con() and a few sample fetches looking for proxy protocol do check for L4+L6 but don't care about HANDSHAKE ; these ones will probably fail on TCP request session rules if the handshake is not complete. - some handshake handlers do validate that a connection is established at L4 but didn't clear CO_FL_WAIT_L4_CONN - the ->ctl method of mux_fcgi, mux_pt and mux_h1 only checks for L4+L6 before declaring the mux ready while the snd_buf function also checks for the handshake's completion. Likely the former should validate the handshake as well and we should get rid of these extra tests in snd_buf. - raw_sock_from_buf() would directly set CO_FL_CONNECTED and would only later clear CO_FL_WAIT_L4_CONN. - xprt_handshake would set CO_FL_CONNECTED itself without actually clearing CO_FL_WAIT_L4_CONN, which could apparently happen only if waiting for a pure Rx handshake. - most places in ssl_sock that were checking CO_FL_CONNECTED don't need to include the L4 check as an L6 check is enough to decide whether to wait for more info or not. It also becomes obvious when reading the test in si_cs_recv() that caused the failure mentioned above that once converted it doesn't make any sense anymore: having CS_FL_EOS set while still waiting for L4 and L6 to complete cannot happen since for CS_FL_EOS to be set, the other ones must have been validated. Some of these parts will still deserve further cleanup, and some of the observations above may induce some backports of potential bug fixes once totally analyzed in their context. The risk of breaking existing stuff is too high to blindly backport everything.
2020-01-23 03:11:58 -05:00
CO_FL_WAIT_L4L6 = 0x00C00000, /* waiting for L4 and/or L6 to be connected */
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
MINOR: connection: remove CO_FL_SSL_WAIT_HS from CO_FL_HANDSHAKE Most places continue to check CO_FL_HANDSHAKE while in fact they should check CO_FL_HANDSHAKE_NOSSL, which contains all handshakes but the one dedicated to SSL renegotiation. In fact the SSL layer should be the only one checking CO_FL_SSL_WAIT_HS, so as to avoid processing data when a renegotiation is in progress, but other ones randomly include it without knowing. And ideally it should even be an internal flag that's not exposed in the connection. This patch takes CO_FL_SSL_WAIT_HS out of CO_FL_HANDSHAKE, uses this flag consistently all over the code, and gets rid of CO_FL_HANDSHAKE_NOSSL. In order to limit the confusion that has accumulated over time, the CO_FL_SSL_WAIT_HS flag which indicates an ongoing SSL handshake, possibly used by a renegotiation was moved after the other ones.
2020-01-23 09:23:13 -05:00
/* All the flags below are used for connection handshakes. Any new
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
* handshake should be added after this point, and CO_FL_HANDSHAKE
* should be updated.
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
*/
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
CO_FL_SEND_PROXY = 0x01000000, /* send a valid PROXY protocol header */
MINOR: connection: remove CO_FL_SSL_WAIT_HS from CO_FL_HANDSHAKE Most places continue to check CO_FL_HANDSHAKE while in fact they should check CO_FL_HANDSHAKE_NOSSL, which contains all handshakes but the one dedicated to SSL renegotiation. In fact the SSL layer should be the only one checking CO_FL_SSL_WAIT_HS, so as to avoid processing data when a renegotiation is in progress, but other ones randomly include it without knowing. And ideally it should even be an internal flag that's not exposed in the connection. This patch takes CO_FL_SSL_WAIT_HS out of CO_FL_HANDSHAKE, uses this flag consistently all over the code, and gets rid of CO_FL_HANDSHAKE_NOSSL. In order to limit the confusion that has accumulated over time, the CO_FL_SSL_WAIT_HS flag which indicates an ongoing SSL handshake, possibly used by a renegotiation was moved after the other ones.
2020-01-23 09:23:13 -05:00
CO_FL_ACCEPT_PROXY = 0x02000000, /* receive a valid PROXY protocol header */
CO_FL_ACCEPT_CIP = 0x04000000, /* receive a valid NetScaler Client IP header */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
/* below we have all handshake flags grouped into one */
MINOR: connection: remove CO_FL_SSL_WAIT_HS from CO_FL_HANDSHAKE Most places continue to check CO_FL_HANDSHAKE while in fact they should check CO_FL_HANDSHAKE_NOSSL, which contains all handshakes but the one dedicated to SSL renegotiation. In fact the SSL layer should be the only one checking CO_FL_SSL_WAIT_HS, so as to avoid processing data when a renegotiation is in progress, but other ones randomly include it without knowing. And ideally it should even be an internal flag that's not exposed in the connection. This patch takes CO_FL_SSL_WAIT_HS out of CO_FL_HANDSHAKE, uses this flag consistently all over the code, and gets rid of CO_FL_HANDSHAKE_NOSSL. In order to limit the confusion that has accumulated over time, the CO_FL_SSL_WAIT_HS flag which indicates an ongoing SSL handshake, possibly used by a renegotiation was moved after the other ones.
2020-01-23 09:23:13 -05:00
CO_FL_HANDSHAKE = CO_FL_SEND_PROXY | CO_FL_ACCEPT_PROXY | CO_FL_ACCEPT_CIP | CO_FL_SOCKS4_SEND | CO_FL_SOCKS4_RECV,
MEDIUM: connection: use CO_FL_WAIT_XPRT more consistently than L4/L6/HANDSHAKE As mentioned in commit c192b0ab95 ("MEDIUM: connection: remove CO_FL_CONNECTED and only rely on CO_FL_WAIT_*"), there is a lack of consistency on which flags are checked among L4/L6/HANDSHAKE depending on the code areas. A number of sample fetch functions only check for L4L6 to report MAY_CHANGE, some places only check for HANDSHAKE and many check both L4L6 and HANDSHAKE. This patch starts to make all of this more consistent by introducing a new mask CO_FL_WAIT_XPRT which is the union of L4/L6/HANDSHAKE and reports whether the transport layer is ready or not. All inconsistent call places were updated to rely on this one each time the goal was to check for the readiness of the transport layer.
2020-01-23 10:27:54 -05:00
CO_FL_WAIT_XPRT = CO_FL_WAIT_L4_CONN | CO_FL_HANDSHAKE | CO_FL_WAIT_L6_CONN,
MINOR: connection: remove CO_FL_SSL_WAIT_HS from CO_FL_HANDSHAKE Most places continue to check CO_FL_HANDSHAKE while in fact they should check CO_FL_HANDSHAKE_NOSSL, which contains all handshakes but the one dedicated to SSL renegotiation. In fact the SSL layer should be the only one checking CO_FL_SSL_WAIT_HS, so as to avoid processing data when a renegotiation is in progress, but other ones randomly include it without knowing. And ideally it should even be an internal flag that's not exposed in the connection. This patch takes CO_FL_SSL_WAIT_HS out of CO_FL_HANDSHAKE, uses this flag consistently all over the code, and gets rid of CO_FL_HANDSHAKE_NOSSL. In order to limit the confusion that has accumulated over time, the CO_FL_SSL_WAIT_HS flag which indicates an ongoing SSL handshake, possibly used by a renegotiation was moved after the other ones.
2020-01-23 09:23:13 -05:00
CO_FL_SSL_WAIT_HS = 0x08000000, /* wait for an SSL handshake to complete */
MEDIUM: connection: reorganize connection flags The connection flags have progressively been added one after the other and were not very well organized. Some of them are often used together and a number of operations are performed on the DATA/SOCK ENA/POL flags. Thus, they have been reorganized so that flags that work together are close to each other (allows immediate operands on ARM) and that polling changes can be detected with fewer operations using a simple shift and xor. The handshakes are now the last ones so that it will be easier to add new ones after without risking a collision. All activity-related flags are also grouped together.
2012-10-03 14:00:18 -04:00
MINOR: connection: add a new flag CO_FL_PRIVATE This flag is set on an outgoing connection when this connection gets some properties that must not be shared with other connections, such as dynamic transparent source binding, SNI or a proxy protocol header, or an authentication challenge from the server. This will be needed later to implement connection reuse.
2015-08-04 13:24:13 -04:00
/* This connection may not be shared between clients */
CO_FL_PRIVATE = 0x10000000,
MINOR: connection: add sample fetch "fc_rcvd_proxy" fc_rcvd_proxy : boolean Returns true if the client initiated the connection with a PROXY protocol header. A flag is added on the struct connection if a PROXY header is successfully parsed.
2017-01-05 09:11:44 -05:00
/* This flag is used to know that a PROXY protocol header was sent by the client */
CO_FL_RCVD_PROXY = 0x20000000,
MEDIUM: sessions: Keep track of which connections are idle. Instead of keeping track of the number of connections we're responsible for, keep track of the number of connections we're responsible for that we are currently considering idling (ie that we are not using, they may be in use by other sessions), that way we can actually reuse connections when we have more connections than the max configured.
2018-12-28 12:50:57 -05:00
/* The connection is unused by its owner */
CO_FL_SESS_IDLE = 0x40000000,
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
MEDIUM: connection: add a flag to hold the transport layer When we start logging SSL information, we need the SSL struct to be present even past the conn_xprt_close() call. In order to achieve this, we should use refcounting on the connection and the transport layer. At the moment it's not worth using plain refcounting as only the logs require this, so instead of real refcounting we just use a flag which will be set by the log subsystem when SSL data need to be logged. What happens then is that the xprt->close() call is ignored and the transport layer is closed again during session_free(), after the log line is emitted.
2012-10-12 11:50:05 -04:00
/* This last flag indicates that the transport layer is used (for instance
* by logs) and must not be cleared yet. The last call to conn_xprt_close()
* must be done after clearing this flag.
*/
CO_FL_XPRT_TRACKED = 0x80000000,
MINOR: connection: add flags to the connection struct We're doing this to take over fdtab[].state.
2012-07-06 03:52:14 -04:00
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
/* below we have all SOCKS handshake flags grouped into one */
CO_FL_SOCKS4 = CO_FL_SOCKS4_SEND | CO_FL_SOCKS4_RECV,
};
MEDIUM: connection: add an error code in connections This will be needed to improve error reporting, especially for SSL.
2012-11-30 11:33:05 -05:00
/* possible connection error codes */
enum {
CO_ER_NONE, /* no error */
MINOR: connection: add more error codes to report connection errors It is quite often that an connection error only reports "socket error" with no more information. This is especially problematic with health checks where many causes are possible, including resource exhaustion which do not lead to a valid errno code. So let's add explicit codes to cover these cases.
2014-01-24 10:06:50 -05:00
CO_ER_CONF_FDLIM, /* reached process' configured FD limitation */
CO_ER_PROC_FDLIM, /* reached process' FD limitation */
CO_ER_SYS_FDLIM, /* reached system's FD limitation */
CO_ER_SYS_MEMLIM, /* reached system buffers limitation */
CO_ER_NOPROTO, /* protocol not supported */
CO_ER_SOCK_ERR, /* other socket error */
CO_ER_PORT_RANGE, /* source port range exhausted */
CO_ER_CANT_BIND, /* can't bind to source address */
CO_ER_FREE_PORTS, /* no more free ports on the system */
CO_ER_ADDR_INUSE, /* local address already in use */
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
CO_ER_PRX_EMPTY, /* nothing received in PROXY protocol header */
CO_ER_PRX_ABORT, /* client abort during PROXY protocol header */
MEDIUM: connection: add minimal error reporting in logs for incomplete connections Since the introduction of SSL, it became quite annoying not to get any useful info in logs about handshake failures. Let's improve reporting for embryonic sessions by checking a per-connection error code and reporting it into the logs if an error happens before the session is completely instanciated. The "dontlognull" option is supported in that if a connection does not talk before being aborted, nothing will be emitted. At the moment, only timeouts are considered for SSL and the PROXY protocol, but next patches will handle more errors.
2012-12-03 09:35:00 -05:00
CO_ER_PRX_TIMEOUT, /* timeout while waiting for a PROXY header */
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
CO_ER_PRX_TRUNCATED, /* truncated PROXY protocol header */
CO_ER_PRX_NOT_HDR, /* not a PROXY protocol header */
CO_ER_PRX_BAD_HDR, /* bad PROXY protocol header */
CO_ER_PRX_BAD_PROTO, /* unsupported protocol in PROXY header */
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
CO_ER_CIP_EMPTY, /* nothing received in NetScaler Client IP header */
CO_ER_CIP_ABORT, /* client abort during NetScaler Client IP header */
CO_ER_CIP_TIMEOUT, /* timeout while waiting for a NetScaler Client IP header */
CO_ER_CIP_TRUNCATED, /* truncated NetScaler Client IP header */
CO_ER_CIP_BAD_MAGIC, /* bad magic number in NetScaler Client IP header */
CO_ER_CIP_BAD_PROTO, /* unsupported protocol in NetScaler Client IP header */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
CO_ER_SSL_EMPTY, /* client closed during SSL handshake */
CO_ER_SSL_ABORT, /* client abort during SSL handshake */
MEDIUM: connection: add minimal error reporting in logs for incomplete connections Since the introduction of SSL, it became quite annoying not to get any useful info in logs about handshake failures. Let's improve reporting for embryonic sessions by checking a per-connection error code and reporting it into the logs if an error happens before the session is completely instanciated. The "dontlognull" option is supported in that if a connection does not talk before being aborted, nothing will be emitted. At the moment, only timeouts are considered for SSL and the PROXY protocol, but next patches will handle more errors.
2012-12-03 09:35:00 -05:00
CO_ER_SSL_TIMEOUT, /* timeout during SSL handshake */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
CO_ER_SSL_TOO_MANY, /* too many SSL connections */
CO_ER_SSL_NO_MEM, /* no more memory to allocate an SSL connection */
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
CO_ER_SSL_RENEG, /* forbidden client renegotiation */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
CO_ER_SSL_CA_FAIL, /* client cert verification failed in the CA chain */
CO_ER_SSL_CRT_FAIL, /* client cert verification failed on the certificate */
MINOR: ssl: add a new error codes for wrong server certificates If a server presents an unexpected certificate to haproxy, that is, a certificate that doesn't match the expected name as configured in verifyhost or as requested using SNI, we want to store that precious information. Fortunately we have access to the connection in the verification callback so it's possible to store an error code there. For this purpose we use CO_ER_SSL_MISMATCH_SNI (for when the cert name didn't match the one requested using SNI) and CO_ER_SSL_MISMATCH for when it doesn't match verifyhost.
2017-07-26 14:09:56 -04:00
CO_ER_SSL_MISMATCH, /* Server presented an SSL certificate different from the configured one */
CO_ER_SSL_MISMATCH_SNI, /* Server presented an SSL certificate different from the expected one */
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 10:32:10 -05:00
CO_ER_SSL_HANDSHAKE, /* SSL error during handshake */
MINOR: connection: add a new error code for SSL with heartbeat Users have seen a huge increase in the rate of SSL handshake failures starting from 2014/04/08 with the release of the Heartbleed OpenSSL vulnerability (CVE-2014-0160). Haproxy can detect that a heartbeat was received in the incoming handshake, and such heartbeats are not supposed to be common, so let's log a different message when a handshake error happens after a heartbeat is detected. This patch only adds the new message and the new code.
2014-04-25 12:54:29 -04:00
CO_ER_SSL_HANDSHAKE_HB, /* SSL error during handshake with heartbeat present */
MEDIUM: ssl: implement a workaround for the OpenSSL heartbleed attack Using the previous callback, it's trivial to block the heartbeat attack, first we control the message length, then we emit an SSL error if it is out of bounds. A special log is emitted, indicating that a heartbleed attack was stopped so that they are not confused with other failures. That way, haproxy can protect itself even when running on an unpatched SSL stack. Tests performed with openssl-1.0.1c indicate a total success.
2014-04-25 14:02:39 -04:00
CO_ER_SSL_KILLED_HB, /* Stopped a TLSv1 heartbeat attack (CVE-2014-0160) */
CO_ER_SSL_NO_TARGET, /* unknown target (not client nor server) */
MINOR: ssl: Handle sending early data to server. This adds a new keyword on the "server" line, "allow-0rtt", if set, we'll try to send early data to the server, as long as the client sent early data, as in case the server rejects the early data, we no longer have them, and can't resend them, so the only option we have is to send back a 425, and we need to be sure the client knows how to interpret it correctly.
2017-11-03 11:27:47 -04:00
CO_ER_SSL_EARLY_FAILED, /* Server refused early data */
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
CO_ER_SOCKS4_SEND, /* SOCKS4 Proxy write error during handshake */
CO_ER_SOCKS4_RECV, /* SOCKS4 Proxy read error during handshake */
CO_ER_SOCKS4_DENY, /* SOCKS4 Proxy deny the request */
CO_ER_SOCKS4_ABORT, /* SOCKS4 Proxy handshake aborted by server */
MEDIUM: connection: add an error code in connections This will be needed to improve error reporting, especially for SSL.
2012-11-30 11:33:05 -05:00
};
MEDIUM: connection: introduce "struct conn_src" for servers and proxies Both servers and proxies share a common set of parameters for outgoing connections, and since they're not stored in a similar structure, a lot of code is duplicated in the connection setup, which is one sensible area. Let's first define a common struct for these settings and make use of it. Next patches will de-duplicate code. This change also fixes a build breakage that happens when USE_LINUX_TPROXY is not set but USE_CTTPROXY is set, which seem to be very unlikely considering that the issue was introduced almost 2 years ago an never reported.
2012-12-08 16:29:20 -05:00
/* source address settings for outgoing connections */
enum {
/* Tproxy exclusive values from 0 to 7 */
CO_SRC_TPROXY_ADDR = 0x0001, /* bind to this non-local address when connecting */
CO_SRC_TPROXY_CIP = 0x0002, /* bind to the client's IP address when connecting */
CO_SRC_TPROXY_CLI = 0x0003, /* bind to the client's IP+port when connecting */
CO_SRC_TPROXY_DYN = 0x0004, /* bind to a dynamically computed non-local address */
CO_SRC_TPROXY_MASK = 0x0007, /* bind to a non-local address when connecting */
CO_SRC_BIND = 0x0008, /* bind to a specific source address when connecting */
};
MINOR: connection: add a new receive flag : CO_RFL_BUF_WET With this flag we introduce the notion of "dry" vs "wet" buffers : some demultiplexers like the H2 mux require as much room as possible for some operations that are not retryable like decoding a headers frame. For this they need to know if the buffer is congested with data scheduled for leaving soon or not. Since the new API will not provide this information in the buffer itself, the caller must indicate it. We never need to know the amount of such data, just the fact that the buffer is not in its optimal condition to be used for receipt. This "CO_RFL_BUF_WET" flag is used to mention that such outgoing data are still pending in the buffer and that a sensitive receiver should better let it "dry" before using it.
2018-06-19 00:23:38 -04:00
/* flags that can be passed to xprt->rcv_buf() and mux->rcv_buf() */
enum {
CO_RFL_BUF_WET = 0x0001, /* Buffer still has some output data present */
MINOR: conn_stream: Add a flag to notify the mux it should flush its buffers By setting the flag CO_RFL_BUF_FLUSH when calling mux->rcv_buf, the stream-interface notifies the mux it should flush its buffers without reading more data. This flag is set when the SI want to use the kernel TCP splicing to forward data. Of course, the mux can respect it or not, depending on its state. It's just an information.
2018-10-11 09:56:04 -04:00
CO_RFL_BUF_FLUSH = 0x0002, /* Flush mux's buffers but don't read more data */
MINOR: connection: introduce a new receive flag: CO_RFL_READ_ONCE This flag is currently supported by raw_sock to perform a single recv() attempt and avoid subscribing. Typically on the request and response paths with keep-alive, with short messages we know that it's very likely that the first message is enough.
2020-02-20 05:04:40 -05:00
CO_RFL_READ_ONCE = 0x0004, /* don't loop even if the request/response is small */
MINOR: connection: add a new receive flag : CO_RFL_BUF_WET With this flag we introduce the notion of "dry" vs "wet" buffers : some demultiplexers like the H2 mux require as much room as possible for some operations that are not retryable like decoding a headers frame. For this they need to know if the buffer is congested with data scheduled for leaving soon or not. Since the new API will not provide this information in the buffer itself, the caller must indicate it. We never need to know the amount of such data, just the fact that the buffer is not in its optimal condition to be used for receipt. This "CO_RFL_BUF_WET" flag is used to mention that such outgoing data are still pending in the buffer and that a sensitive receiver should better let it "dry" before using it.
2018-06-19 00:23:38 -04:00
};
/* flags that can be passed to xprt->snd_buf() and mux->snd_buf() */
MEDIUM: connection: don't use real send() flags in snd_buf() This prevents us from passing other useful info and requires the upper levels to know these flags. Let's use a new flags category instead : CO_SFL_*. For now, only MSG_MORE has been remapped.
2014-02-01 19:51:17 -05:00
enum {
CO_SFL_MSG_MORE = 0x0001, /* More data to come afterwards */
OPTIM: ssl: implement dynamic record size adjustment By having the stream interface pass the CF_STREAMER flag to the snd_buf() primitive, we're able to tell the send layer whether we're sending large chunks or small ones. We use this information in SSL to adjust the max record dynamically. This results in small chunks respecting tune.ssl.maxrecord at the beginning of a transfer or for small transfers, with an automatic switch to full records if the exchanges last long. This allows the receiver to parse HTML contents on the fly without having to retrieve 16kB of data, which is even more important with small initcwnd since the receiver does not need to wait for round trips to start fetching new objects. However, sending large files still produces large chunks. For example, with tune.ssl.maxrecord = 2859, we see 5 write(2885) sent in two segments each and 6 write(16421). This idea was first proposed on the haproxy mailing list by Ilya Grigorik.
2014-02-01 20:00:24 -05:00
CO_SFL_STREAMER = 0x0002, /* Producer is continuously streaming data */
MEDIUM: connection: don't use real send() flags in snd_buf() This prevents us from passing other useful info and requires the upper levels to know these flags. Let's use a new flags category instead : CO_SFL_*. For now, only MSG_MORE has been remapped.
2014-02-01 19:51:17 -05:00
};
MEDIUM: connection: introduce "struct conn_src" for servers and proxies Both servers and proxies share a common set of parameters for outgoing connections, and since they're not stored in a similar structure, a lot of code is duplicated in the connection setup, which is one sensible area. Let's first define a common struct for these settings and make use of it. Next patches will de-duplicate code. This change also fixes a build breakage that happens when USE_LINUX_TPROXY is not set but USE_CTTPROXY is set, which seem to be very unlikely considering that the issue was introduced almost 2 years ago an never reported.
2012-12-08 16:29:20 -05:00
MINOR: connection: add a minimal transport layer registration system There are still a lot of #ifdef USE_OPENSSL in the code (still 43 occurences) because we never know if we can directly access ssl_sock or not. This patch attacks the problem differently by providing a way for transport layers to register themselves and for users to retrieve the pointer. Unregistered transport layers will point to NULL so it will be easy to check if SSL is registered or not. The mechanism is very inexpensive as it relies on a two-entries array of pointers, so the performance will not be affected.
2016-12-22 14:25:26 -05:00
/* known transport layers (for ease of lookup) */
enum {
XPRT_RAW = 0,
XPRT_SSL = 1,
MEDIUM: connections: Introduce a handshake pseudo-XPRT. Add a new XPRT that is used when using non-SSL handshakes, such as proxy protocol or Netscaler, instead of taking care of it in conn_fd_handler(). This XPRT is installed when any of those is used, and it removes itself once the handshake is done. This should allow us to remove the distinction between CO_FL_SOCK* and CO_FL_XPRT*.
2019-05-27 06:09:19 -04:00
XPRT_HANDSHAKE = 2,
MINOR: connection: add a minimal transport layer registration system There are still a lot of #ifdef USE_OPENSSL in the code (still 43 occurences) because we never know if we can directly access ssl_sock or not. This patch attacks the problem differently by providing a way for transport layers to register themselves and for users to retrieve the pointer. Unregistered transport layers will point to NULL so it will be easy to check if SSL is registered or not. The mechanism is very inexpensive as it relies on a two-entries array of pointers, so the performance will not be affected.
2016-12-22 14:25:26 -05:00
XPRT_ENTRIES /* must be last one */
};
MINOR: mux: add flags to describe a mux's capabilities This new field will be used to describe certain properties of some muxes. For now we only add MX_FL_CLEAN_ABRT to indicate that a mux is able to unambiguously report aborts using CS_FL_ERROR contrary to others who may only report it via a read0. This will be used to improve handling of the abortonclose option with H2. Other flags may come later to report multiplexing capabilities or not, support of client/server sides etc.
2017-12-20 10:14:44 -05:00
/* MUX-specific flags */
enum {
MX_FL_NONE = 0x00000000,
MX_FL_CLEAN_ABRT = 0x00000001, /* abort is clearly reported as an error */
MINOR: muxes: Add a flag to specify a multiplexer uses the HTX A multiplexer must now set the flag MX_FL_HTX when it uses the HTX to structured the data exchanged with channels. the muxes h1 and h2 set this flag. Of course, for the mux h2, it is set on h2_htx_ops only.
2019-04-03 03:53:32 -04:00
MX_FL_HTX = 0x00000002, /* set if it is an HTX multiplexer */
MINOR: mux: add flags to describe a mux's capabilities This new field will be used to describe certain properties of some muxes. For now we only add MX_FL_CLEAN_ABRT to indicate that a mux is able to unambiguously report aborts using CS_FL_ERROR contrary to others who may only report it via a read0. This will be used to improve handling of the abortonclose option with H2. Other flags may come later to report multiplexing capabilities or not, support of client/server sides etc.
2017-12-20 10:14:44 -05:00
};
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
/* xprt_ops describes transport-layer operations for a connection. They
* generally run over a socket-based control layer, but not always. Some
* of them are used for data transfer with the upper layer (rcv_*, snd_*)
* and the other ones are used to setup and release the transport layer.
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
*/
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
struct xprt_ops {
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
size_t (*rcv_buf)(struct connection *conn, void *xprt_ctx, struct buffer *buf, size_t count, int flags); /* recv callback */
size_t (*snd_buf)(struct connection *conn, void *xprt_ctx, const struct buffer *buf, size_t count, int flags); /* send callback */
int (*rcv_pipe)(struct connection *conn, void *xprt_ctx, struct pipe *pipe, unsigned int count); /* recv-to-pipe callback */
int (*snd_pipe)(struct connection *conn, void *xprt_ctx, struct pipe *pipe); /* send-to-pipe callback */
void (*shutr)(struct connection *conn, void *xprt_ctx, int); /* shutr function */
void (*shutw)(struct connection *conn, void *xprt_ctx, int); /* shutw function */
void (*close)(struct connection *conn, void *xprt_ctx); /* close the transport layer */
int (*init)(struct connection *conn, void **ctx); /* initialize the transport layer */
MINOR: connection: add a new prepare_bind_conf() entry to xprt_ops This one will be set by the transport layers which want to initialize a bind_conf. It will typically be used by SSL to load certificates, CAs and so on.
2016-12-22 11:19:24 -05:00
int (*prepare_bind_conf)(struct bind_conf *conf); /* prepare a whole bind_conf */
MINOR: connection: add a new destroy_bind_conf() entry to xprt_ops This one will be set by the transport layers which want to destroy a bind_conf. It will typically be used by SSL to release certificates, CAs and so on.
2016-12-22 11:30:20 -05:00
void (*destroy_bind_conf)(struct bind_conf *conf); /* destroy a whole bind_conf */
MINOR: connection: add new prepare_srv()/destroy_srv() entries to xprt_ops These one will be used by the SSL layer to prepare and destroy a server-side SSL context.
2016-12-22 15:13:18 -05:00
int (*prepare_srv)(struct server *srv); /* prepare a server context */
void (*destroy_srv)(struct server *srv); /* destroy a server context */
MEDIUM: connections: Provide a xprt_ctx for each xprt method. For most of the xprt methods, provide a xprt_ctx. This will be useful later when we'll want to be able to stack xprts. The init() method now has to create and provide the said xprt_ctx if needed.
2019-03-21 13:27:17 -04:00
int (*get_alpn)(const struct connection *conn, void *xprt_ctx, const char **str, int *len); /* get application layer name */
MINOR: connection: add names for transport and data layers This makes debugging easier and avoids having to put ugly checks against certain well-known internal struct pointers.
2016-11-24 10:58:12 -05:00
char name[8]; /* transport layer name, zero-terminated */
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
int (*subscribe)(struct connection *conn, void *xprt_ctx, int event_type, struct wait_event *es); /* Subscribe <es> to events, such as "being able to send" */
int (*unsubscribe)(struct connection *conn, void *xprt_ctx, int event_type, struct wait_event *es); /* Unsubscribe <es> from events */
MINOR: connections: Add a new xprt method, remove_xprt. Add a new method to xprt_ops, remove_xprt. When called, if the provided xprt_ctx is the same as the xprt's underlying xprt_ctx, it then uses the new xprt provided, otherwise it calls the remove_xprt method of the next xprt. The goal is to be able to add a temporary xprt, that removes itself from the chain when it did what it had to do. This will be used to implement a pseudo-xprt for anything that just requires a handshake (such as the proxy protocol).
2019-05-23 11:47:36 -04:00
int (*remove_xprt)(struct connection *conn, void *xprt_ctx, void *toremove_ctx, const struct xprt_ops *newops, void *newctx); /* Remove an xprt from the connection, used by temporary xprt such as the handshake one */
MINOR: connections: Add a new xprt method, add_xprt(). Add a new method to xprt_ops, add_xprt(), that changes the underlying xprt to the one provided, and optionally provide the old one.
2019-05-27 13:50:12 -04:00
int (*add_xprt)(struct connection *conn, void *xprt_ctx, void *toadd_ctx, const struct xprt_ops *toadd_ops, void **oldxprt_ctx, const struct xprt_ops **oldxprt_ops); /* Add a new XPRT as the new xprt, and return the old one */
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
};
MINOR: mux: Add a new method to get informations about a mux. Add a new method, ctl(), to muxes. It uses a "enum mux_ctl_type" to let it know which information we're asking for, and can output it either directly by returning the expected value, or by using an optional argument. "output" argument. Right now, the only known mux_ctl_type is MUX_STATUS, that will return 0 if the mux is not ready, or MUX_STATUS_READY if the mux is ready. We probably want to backport this to 1.9 and 2.0.
2019-10-25 10:19:26 -04:00
enum mux_ctl_type {
MUX_STATUS, /* Expects an int as output, sets it to a combinaison of MUX_STATUS flags */
};
#define MUX_STATUS_READY (1 << 0)
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 04:53:00 -04:00
/* mux_ops describes the mux operations, which are to be performed at the
* connection level after data are exchanged with the transport layer in order
* to propagate them to streams. The <init> function will automatically be
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
* called once the mux is instantiated by the connection's owner at the end
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 04:53:00 -04:00
* of a transport handshake, when it is about to transfer data and the data
* layer is not ready yet.
*/
struct mux_ops {
MEDIUM: muxes: Add an optional input buffer during mux initialization The mux's callback init() now take a pointer to a buffer as extra argument. It must be used by the multiplexer as its input buffer. This buffer is always NULL when a multiplexer is initialized with a fresh connection. But if a mux upgrade is performed, it may be filled with existing data. Note that, for now, mux upgrades are not supported. But this commit is mandatory to do so.
2019-04-08 05:22:47 -04:00
int (*init)(struct connection *conn, struct proxy *prx, struct session *sess, struct buffer *input); /* early initialization */
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 04:53:00 -04:00
int (*wake)(struct connection *conn); /* mux-layer callback to report activity, mandatory */
MINOR: connection: add a flags argument to rcv_buf() The mux and transport rcv_buf() now takes a "flags" argument, just like the snd_buf() one or like the equivalent syscall lower part. The upper layers will use this to pass some information such as indicating whether the buffer is free from outgoing data or if the lower layer may allocate the buffer itself.
2018-06-19 00:15:17 -04:00
size_t (*rcv_buf)(struct conn_stream *cs, struct buffer *buf, size_t count, int flags); /* Called from the upper layer to get data */
MEDIUM: mux: Remove const on the buffer in mux->snd_buf() This is a partial revert of the commit deccd1116 ("MEDIUM: mux: make mux->snd_buf() take the byte count in argument"). It is a requirement to do zero-copy transfers. This will be mandatory when the TX buffer of the conn_stream will be used. So, now, data are consumed by mux->snd_buf() and not only sent. So it needs to update the buffer state. On its side, the caller must be aware the buffer can be replaced y an empty or unallocated one. As a side effet of this change, the function co_set_data() is now only responsible to update the channel set, by update ->output field.
2018-07-27 05:59:41 -04:00
size_t (*snd_buf)(struct conn_stream *cs, struct buffer *buf, size_t count, int flags); /* Called from the upper layer to send data */
MINOR: mux: add more methods to mux_ops We'll need to support reading/writing from both sides, with buffers and pipes, as well as retrieving/updating flags.
2017-09-13 12:30:23 -04:00
int (*rcv_pipe)(struct conn_stream *cs, struct pipe *pipe, unsigned int count); /* recv-to-pipe callback */
int (*snd_pipe)(struct conn_stream *cs, struct pipe *pipe); /* send-to-pipe callback */
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 09:25:48 -04:00
void (*shutr)(struct conn_stream *cs, enum cs_shr_mode); /* shutr function */
void (*shutw)(struct conn_stream *cs, enum cs_shw_mode); /* shutw function */
MINOR: mux: add more methods to mux_ops We'll need to support reading/writing from both sides, with buffers and pipes, as well as retrieving/updating flags.
2017-09-13 12:30:23 -04:00
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 13:42:40 -05:00
struct conn_stream *(*attach)(struct connection *, struct session *sess); /* Create and attach a conn_stream to an outgoing connection */
MINOR: mux: implement a get_first_cs() method This method is used to retrieve the first known good conn_stream from the mux. It will be used to find the other end of a connection when dealing with the proxy protocol for example.
2018-11-18 15:29:20 -05:00
const struct conn_stream *(*get_first_cs)(const struct connection *); /* retrieves any valid conn_stream from this connection */
MINOR: mux: add more methods to mux_ops We'll need to support reading/writing from both sides, with buffers and pipes, as well as retrieving/updating flags.
2017-09-13 12:30:23 -04:00
void (*detach)(struct conn_stream *); /* Detach a conn_stream from an outgoing connection, when the request is done */
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
void (*show_fd)(struct buffer *, struct connection *); /* append some data about connection into chunk for "show fd" */
MINOR: connection: make the last arg of subscribe() a struct wait_event* The subscriber used to be passed as a "void *param" that was systematically cast to a struct wait_event*. By now it appears clear that the subscribe() call at every layer is well defined and always takes a pointer to an event subscriber of type wait_event, so let's enforce this in the functions' prototypes, remove the intermediary variables used to cast it and clean up the comments to clarify what all these functions do in their context.
2020-01-17 01:52:13 -05:00
int (*subscribe)(struct conn_stream *cs, int event_type, struct wait_event *es); /* Subscribe <es> to events, such as "being able to send" */
int (*unsubscribe)(struct conn_stream *cs, int event_type, struct wait_event *es); /* Unsubscribe <es> from events */
MINOR: mux: Add a new "avail_streams" method. Add a new method for mux, avail_streams, that returns the number of streams still available for a mux. For the mux_pt, it'll return 1 if the connection is in idle, or 0. For the H2 mux, it'll return the max number of streams allowed, minus the number of streams currently in use.
2018-11-05 12:37:53 -05:00
int (*avail_streams)(struct connection *conn); /* Returns the number of streams still available for a connection */
BUG/MINOR: server: fix logic flaw in idle connection list management With variable connection limits, it's not possible to accurately determine whether the mux is still in use by comparing usage and max to be equal due to the fact that one determines the capacity and the other one takes care of the context. This can cause some connections to be dropped before they reach their stream ID limit. It seems it could also cause some connections to be terminated with streams still alive if the limit was reduced to match the newly computed avail_streams() value, though this cannot yet happen with existing muxes. Instead let's switch to usage reports and simply check whether connections are both unused and available before adding them to the idle list. This should be backported to 1.9.
2019-01-26 06:19:01 -05:00
int (*used_streams)(struct connection *conn); /* Returns the number of streams in use on a connection. */
MINOR: muxes: Pass the context of the mux to destroy() instead of the connection It is mandatory to handle mux upgrades, because during a mux upgrade, the connection will be reassigned to another multiplexer. So when the old one is destroyed, it does not own the connection anymore. Or in other words, conn->ctx does not point to the old mux's context when its destroy() callback is called. So we now rely on the multiplexer context do destroy it instead of the connection. In addition, h1_release() and h2_release() have also been updated in the same way.
2019-04-08 05:23:22 -04:00
void (*destroy)(void *ctx); /* Let the mux know one of its users left, so it may have to disappear */
MEDIUM: mux: Add an optional "reset" method. Add a new method to mux, "reset", that is used to let the mux know the connection attempt failed, and we're about to retry, so it just have to reinit itself. Currently only the H1 mux needs it.
2018-12-11 10:47:14 -05:00
void (*reset)(struct connection *conn); /* Reset the mux, because we're re-trying to connect */
MEDIUM: conn_stream: Add a way to get mux's info on a CS from the upper layer Time to time, the need arises to get some info owned by the multiplexer about a connection stream from the upper layer. Today we really need to get some dates and durations specific to the conn_stream. It is only true for the mux H1 and H2. Otherwise it will be impossible to have correct times reported in the logs. To do so, the structure cs_info has been defined to provide all info we ever need on a conn_stream from the upper layer. Of course, it is the first step. So this structure will certainly envloved. But for now, only the bare minimum is referenced. On the mux side, the callback get_cs_info() has been added in the structure mux_ops. Multiplexers can now implement it, if necessary, to return a pointer on a structure cs_info. And finally, the function si_get_cs_info() should be used from the upper layer. If the stream interface is not attached to a connection stream, this function returns NULL, likewise if the callback get_cs_info() is not defined for the corresponding mux.
2018-11-29 05:29:26 -05:00
const struct cs_info *(*get_cs_info)(struct conn_stream *cs); /* Return info on the specified conn_stream or NULL if not defined */
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
int (*ctl)(struct connection *conn, enum mux_ctl_type mux_ctl, void *arg); /* Provides information about the mux */
MINOR: connections: Add a new mux method, "takeover". Add a new mux method, "takeover", that will attempt to make the current thread responsible for the connection. It should return 0 on success, and non-zero on failure.
2020-02-19 11:18:57 -05:00
int (*takeover)(struct connection *conn); /* Attempts to migrate the connection to the current thread */
MINOR: mux: add flags to describe a mux's capabilities This new field will be used to describe certain properties of some muxes. For now we only add MX_FL_CLEAN_ABRT to indicate that a mux is able to unambiguously report aborts using CS_FL_ERROR contrary to others who may only report it via a read0. This will be used to improve handling of the abortonclose option with H2. Other flags may come later to report multiplexing capabilities or not, support of client/server sides etc.
2017-12-20 10:14:44 -05:00
unsigned int flags; /* some flags characterizing the mux's capabilities (MX_FL_*) */
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 04:53:00 -04:00
char name[8]; /* mux layer name, zero-terminated */
};
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 18:41:04 -04:00
/* data_cb describes the data layer's recv and send callbacks which are called
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
* when I/O activity was detected after the transport layer is ready. These
* callbacks are supposed to make use of the xprt_ops above to exchange data
MINOR: connection: provide a generic data layer wakeup callback Instead of calling conn_notify_si() from the connection handler, we now call data->wake(), which will allow us to use a different callback with health checks. Note that we still rely on a flag in order to decide whether or not to call this function. The reason is that with embryonic sessions, the callback is already initialized to si_conn_cb without the flag, and we can't call the SI notify function in the leave path before the stream interface is initialized. This issue should be addressed by involving a different data_cb for embryonic sessions and for stream interfaces, that would be changed during session_complete() for the final data_cb.
2012-10-02 14:07:22 -04:00
* from/to buffers and pipes. The <wake> callback is used to report activity
* at the transport layer, which can be a connection opening/close, or any
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 09:46:01 -04:00
* data movement. It may abort a connection by returning < 0.
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
*/
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 18:41:04 -04:00
struct data_cb {
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
int (*wake)(struct conn_stream *cs); /* data-layer callback to report activity */
MINOR: connection: add names for transport and data layers This makes debugging easier and avoids having to put ugly checks against certain well-known internal struct pointers.
2016-11-24 10:58:12 -05:00
char name[8]; /* data layer name, zero-terminated */
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
};
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
struct my_tcphdr {
BUILD: fix build on Solaris 10/11 uint16_t instead of u_int16_t None ISO fields of struct tm are not present, but by zeroyfing it, on GNU and BSD systems tm_gmtoff field will be set. [wt: moved the memset into each of the date functions]
2016-11-20 05:42:38 -05:00
uint16_t source;
uint16_t dest;
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
};
MEDIUM: connection: introduce "struct conn_src" for servers and proxies Both servers and proxies share a common set of parameters for outgoing connections, and since they're not stored in a similar structure, a lot of code is duplicated in the connection setup, which is one sensible area. Let's first define a common struct for these settings and make use of it. Next patches will de-duplicate code. This change also fixes a build breakage that happens when USE_LINUX_TPROXY is not set but USE_CTTPROXY is set, which seem to be very unlikely considering that the issue was introduced almost 2 years ago an never reported.
2012-12-08 16:29:20 -05:00
/* a connection source profile defines all the parameters needed to properly
* bind an outgoing connection for a server or proxy.
*/
struct conn_src {
unsigned int opts; /* CO_SRC_* */
int iface_len; /* bind interface name length */
char *iface_name; /* bind interface name or NULL */
struct port_range *sport_range; /* optional per-server TCP source ports */
struct sockaddr_storage source_addr; /* the address to which we want to bind for connect() */
MAJOR: tproxy: remove support for cttproxy This was the first transparent proxy technology supported by haproxy circa 2005 but it was obsoleted in 2007 by Tproxy 4.0 which removed a lot of the earlier versions' shortcomings and was finally merged into the kernel. Since nobody has been using cttproxy for many years now and nobody has even just tried to compile the files, it's time to remove it. The doc was updated as well.
2015-08-20 13:35:14 -04:00
#if defined(CONFIG_HAP_TRANSPARENT)
MEDIUM: connection: introduce "struct conn_src" for servers and proxies Both servers and proxies share a common set of parameters for outgoing connections, and since they're not stored in a similar structure, a lot of code is duplicated in the connection setup, which is one sensible area. Let's first define a common struct for these settings and make use of it. Next patches will de-duplicate code. This change also fixes a build breakage that happens when USE_LINUX_TPROXY is not set but USE_CTTPROXY is set, which seem to be very unlikely considering that the issue was introduced almost 2 years ago an never reported.
2012-12-08 16:29:20 -05:00
struct sockaddr_storage tproxy_addr; /* non-local address we want to bind to for connect() */
char *bind_hdr_name; /* bind to this header name if defined */
int bind_hdr_len; /* length of the name of the header above */
int bind_hdr_occ; /* occurrence number of header above: >0 = from first, <0 = from end, 0=disabled */
#endif
};
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
/*
* This structure describes the elements of a connection relevant to a stream
*/
struct conn_stream {
enum obj_type obj_type; /* differentiates connection from applet context */
MINOR: conn_stream: add an rx buffer to the conn_stream In order to reorganize the connection layers, recv() operations will need to be retryable and to support partial transfers. This requires an intermediary buffer to hold the data coming from the mux. After a few attempts, it turns out that this buffer is best placed inside the conn_stream itself. For now it's only set to buf_empty and it will be up to the caller to allocate it if required.
2018-03-02 04:43:58 -05:00
/* 3 bytes hole here */
MINOR: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 12:46:31 -04:00
unsigned int flags; /* CS_FL_* */
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 12:30:23 -04:00
struct connection *conn; /* xprt-level connection */
void *data; /* pointer to upper layer's entity (eg: stream interface) */
const struct data_cb *data_cb; /* data layer callbacks. Must be set before xprt->init() */
void *ctx; /* mux-specific context */
};
MEDIUM: conn_stream: Add a way to get mux's info on a CS from the upper layer Time to time, the need arises to get some info owned by the multiplexer about a connection stream from the upper layer. Today we really need to get some dates and durations specific to the conn_stream. It is only true for the mux H1 and H2. Otherwise it will be impossible to have correct times reported in the logs. To do so, the structure cs_info has been defined to provide all info we ever need on a conn_stream from the upper layer. Of course, it is the first step. So this structure will certainly envloved. But for now, only the bare minimum is referenced. On the mux side, the callback get_cs_info() has been added in the structure mux_ops. Multiplexers can now implement it, if necessary, to return a pointer on a structure cs_info. And finally, the function si_get_cs_info() should be used from the upper layer. If the stream interface is not attached to a connection stream, this function returns NULL, likewise if the callback get_cs_info() is not defined for the corresponding mux.
2018-11-29 05:29:26 -05:00
/*
* This structure describes the info related to a conn_stream known by the mux
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
* only but useful for the upper layer.
MEDIUM: conn_stream: Add a way to get mux's info on a CS from the upper layer Time to time, the need arises to get some info owned by the multiplexer about a connection stream from the upper layer. Today we really need to get some dates and durations specific to the conn_stream. It is only true for the mux H1 and H2. Otherwise it will be impossible to have correct times reported in the logs. To do so, the structure cs_info has been defined to provide all info we ever need on a conn_stream from the upper layer. Of course, it is the first step. So this structure will certainly envloved. But for now, only the bare minimum is referenced. On the mux side, the callback get_cs_info() has been added in the structure mux_ops. Multiplexers can now implement it, if necessary, to return a pointer on a structure cs_info. And finally, the function si_get_cs_info() should be used from the upper layer. If the stream interface is not attached to a connection stream, this function returns NULL, likewise if the callback get_cs_info() is not defined for the corresponding mux.
2018-11-29 05:29:26 -05:00
* For now, only some dates and durations are reported. This structure will
* envolved. But for now, only the bare minimum is referenced.
*/
struct cs_info {
struct timeval create_date; /* Creation date of the conn_stream in user date */
struct timeval tv_create; /* Creation date of the conn_stream in internal date (monotonic) */
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
long t_handshake; /* handshake duration, -1 if never occurs */
MEDIUM: conn_stream: Add a way to get mux's info on a CS from the upper layer Time to time, the need arises to get some info owned by the multiplexer about a connection stream from the upper layer. Today we really need to get some dates and durations specific to the conn_stream. It is only true for the mux H1 and H2. Otherwise it will be impossible to have correct times reported in the logs. To do so, the structure cs_info has been defined to provide all info we ever need on a conn_stream from the upper layer. Of course, it is the first step. So this structure will certainly envloved. But for now, only the bare minimum is referenced. On the mux side, the callback get_cs_info() has been added in the structure mux_ops. Multiplexers can now implement it, if necessary, to return a pointer on a structure cs_info. And finally, the function si_get_cs_info() should be used from the upper layer. If the stream interface is not attached to a connection stream, this function returns NULL, likewise if the callback get_cs_info() is not defined for the corresponding mux.
2018-11-29 05:29:26 -05:00
long t_idle; /* idle duration, -1 if never occurs */
};
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
/* This structure describes a connection with its methods and data.
* A connection may be performed to proxy or server via a local or remote
* socket, and can also be made to an internal applet. It can support
MINOR: connection: add a field to store an object type This will soon be used to differenciate connections from applet contexts. Object type "connection" has also been added.
2013-09-29 03:06:42 -04:00
* several transport schemes (raw, ssl, ...). It can support several
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
* connection control schemes, generally a protocol for socket-oriented
MEDIUM: connections: Get ride of the xprt_done callback. The xprt_done_cb callback was used to defer some connection initialization until we're connected and the handshake are done. As it mostly consists of creating the mux, instead of using the callback, introduce a conn_create_mux() function, that will just call conn_complete_session() for frontend, and create the mux for backend. In h2_wake(), make sure we call the wake method of the stream_interface, as we no longer wakeup the stream task.
2020-01-22 12:08:48 -05:00
* connections, but other methods for applets.
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
*/
struct connection {
MINOR: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 12:46:31 -04:00
/* first cache line */
MINOR: connection: add a field to store an object type This will soon be used to differenciate connections from applet contexts. Object type "connection" has also been added.
2013-09-29 03:06:42 -04:00
enum obj_type obj_type; /* differentiates connection from applet context */
DIET/MINOR: connection: rearrange a few fields to save 8 bytes in the struct By moving the error code to 8 bits the send_proxy_ofs to 16 bits, and moving them just after the obj_type, we can save 8 bytes in the struct connection, down from 328 to 320.
2013-12-06 15:09:57 -05:00
unsigned char err_code; /* CO_ER_* */
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
signed short send_proxy_ofs; /* <0 = offset to (re)send from the end, >0 = send all (reused for SOCKS4) */
MEDIUM: connection: move the send_proxy offset to the connection Till now the send_proxy_ofs field remained in the stream interface, but since the dynamic allocation of the connection, it makes a lot of sense to move that into the connection instead of the stream interface, since it will not be statically allocated for each session. Also, it turns out that moving it to the connection fils an alignment hole on 64 bit architectures so it does not consume more memory, and removing it from the stream interface was an opportunity to correctly reorder fields and reduce the stream interface's size from 160 to 144 bytes (-10%). This is 32 bytes saved per session.
2013-10-24 15:10:08 -04:00
unsigned int flags; /* CO_FL_* */
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
const struct protocol *ctrl; /* operations at the socket layer */
OPTIM: connection: pack the struct target The struct target contains one int and one pointer, causing it to be 64-bit aligned on 64-bit platforms. By marking it "packed", we can save 8 bytes in struct connection and as many in struct session on such platforms.
2012-10-13 08:33:58 -04:00
const struct xprt_ops *xprt; /* operations at the transport layer */
CLEANUP: assorted typo fixes in the code and comments This is 8th iteration of typo fixes
2020-04-16 14:51:34 -04:00
const struct mux_ops *mux; /* mux layer operations. Must be set before xprt->init() */
OPTIM: connection: pack the struct target The struct target contains one int and one pointer, causing it to be 64-bit aligned on 64-bit platforms. By marking it "packed", we can save 8 bytes in struct connection and as many in struct session on such platforms.
2012-10-13 08:33:58 -04:00
void *xprt_ctx; /* general purpose pointer, initialized to NULL */
CLEANUP: connection: rename conn->mux_ctx to conn->ctx We most often store the mux context there but it can also be something else while setting up the connection. Better call it "ctx" and know that it's the owner's context than misleadingly call it mux_ctx and get caught doing suspicious tricks.
2018-12-19 08:12:10 -05:00
void *ctx; /* highest level context (usually the mux), initialized to NULL */
MINOR: connection: Fix a comment. Connections can now have an owner for outgoing connections, so update the comment tu reflect that.
2018-12-01 18:35:08 -05:00
void *owner; /* pointer to the owner session, or NULL */
MINOR: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 12:46:31 -04:00
enum obj_type *target; /* the target to connect to (server, proxy, applet, ...) */
/* second cache line */
MEDIUM: connection: merge the send_wait and recv_wait entries In practice all callers use the same wait_event notification for any I/O so instead of keeping specific code to handle them separately, let's merge them and it will allow us to create new events later.
2020-01-10 01:06:05 -05:00
struct wait_event *subs; /* Task to wake when awaited events are ready */
MINOR: connections: Make the "list" element a struct mt_list instead of list. Make the "list" element a struct mt_list, and explicitely use list_from_mt_list to get a struct list * where it is used as such, so that mt_list_for_each_entry will be usable with it.
2020-03-06 12:12:03 -05:00
struct mt_list list; /* attach point to various connection lists (idle, ...) */
MAJOR: sessions: Store multiple outgoing connections in the session. Instead of just storing the last connection in the session, store all of the connections, for at most MAX_SRV_LIST (currently 5) targets. That way we can do keepalive on more than 1 outgoing connection when the client uses HTTP/2.
2018-11-30 11:24:55 -05:00
struct list session_list; /* List of attached connections to a session */
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 08:31:19 -04:00
union conn_handle handle; /* connection handle at the socket layer */
MINOR: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 12:46:31 -04:00
const struct netns_entry *proxy_netns;
/* third cache line and beyond */
MEDIUM: connection: add a destroy callback This callback will be used to release upper layers when a mux is in use. Given that the mux can be asynchronously deleted, we need a way to release the extra information such as the session. This callback will be called directly by the mux upon releasing everything and before the connection itself is released, so that the callee can find its information inside the connection if needed. The way it currently works is not perfect, and most likely this should instead become a mux release callback, but for now we have no easy way to add mux-specific stuff, and since there's one mux per connection, it works fine this way.
2017-10-08 05:16:46 -04:00
void (*destroy_cb)(struct connection *conn); /* callback to notify of imminent death of the connection */
MINOR: connection: add new src and dst fields At the moment we're facing difficulties with connection reuse based on the fact that connections may be allocated very early only to set a target address in transparent mode. With the imminent removal of the legacy mode, the connection reuse by a same stream will not exist anymore and all this awful complexity is not justified anymore. However we still need to be able to assign addresses somewhere. Thus instead of allocating a connection, we'll only place addresses where needed in the stream during operations. But this takes quite some room (typically 128 bytes). This is a nice opportunity for cleaning all this up and dynamically allocatating the addresses fields, which will result in actually saving memory from connection structs since most of the time the client's "to" address is not used and the server's "from" is not used either, thus saving ~256 bytes per end-to-end connection. For now these new "src" and "dst" pointers point to addr.from and addr.to. This will allow us to smoothly update the whole code to use these pointers prior to going further and switching them to pools.
2019-07-17 08:33:15 -04:00
struct sockaddr_storage *src; /* source address (pool), when known, otherwise NULL */
struct sockaddr_storage *dst; /* destination address (pool), when known, otherwise NULL */
MINOR: connection: add the fc_pp_authority fetch -- authority TLV, from PROXYv2 Save the authority TLV in a PROXYv2 header from the client connection, if present, and make it available as fc_pp_authority. The fetch can be used, for example, to set the SNI for a backend TLS connection.
2019-08-27 12:31:16 -04:00
char *proxy_authority; /* Value of authority TLV received via PROXYv2 */
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 12:30:32 -05:00
unsigned int idle_time; /* Time the connection was added to the idle list, or 0 if not in the idle list */
MINOR: connection: add the fc_pp_authority fetch -- authority TLV, from PROXYv2 Save the authority TLV in a PROXYv2 header from the client connection, if present, and make it available as fc_pp_authority. The fetch can be used, for example, to set the SNI for a backend TLS connection.
2019-08-27 12:31:16 -04:00
uint8_t proxy_authority_len; /* Length of authority TLV received via PROXYv2 */
MINOR: proxy_protocol: Ingest PP2_TYPE_UNIQUE_ID on incoming connections This patch reads a proxy protocol v2 provided unique ID and makes it available using the `fc_pp_unique_id` fetch.
2020-03-13 07:34:23 -04:00
struct ist proxy_unique_id; /* Value of the unique ID TLV received via PROXYv2 */
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
};
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 08:33:41 -04:00
/* PROTO token registration */
enum proto_proxy_mode {
PROTO_MODE_NONE = 0,
PROTO_MODE_TCP = 1 << 0, // must not be changed!
PROTO_MODE_HTTP = 1 << 1, // must not be changed!
MINOR: connection: Remove the multiplexer protocol PROTO_MODE_HTX Since the legacy HTTP mode is disabled and no multiplexer relies on it anymore, there is no reason to have 2 multiplexer protocols for the HTTP. So the protocol PROTO_MODE_HTX was removed and all HTTP multiplexers use now PROTO_MODE_HTTP.
2019-07-15 05:42:52 -04:00
PROTO_MODE_ANY = PROTO_MODE_TCP | PROTO_MODE_HTTP,
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 13:40:52 -04:00
};
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 08:33:41 -04:00
enum proto_proxy_side {
PROTO_SIDE_NONE = 0,
PROTO_SIDE_FE = 1, // same as PR_CAP_FE
PROTO_SIDE_BE = 2, // same as PR_CAP_BE
PROTO_SIDE_BOTH = PROTO_SIDE_FE | PROTO_SIDE_BE,
MINOR: mux: Add info about the supported side in alpn_mux_list structure Now, a multiplexer can specify if it can be install on incoming connections (ALPN_SIDE_FE), on outgoing connections (ALPN_SIDE_BE) or both (ALPN_SIDE_BOTH). These flags are compatible with proxies' ones.
2018-03-06 08:43:47 -05:00
};
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 08:33:41 -04:00
struct mux_proto_list {
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 13:40:52 -04:00
const struct ist token; /* token name and length. Empty is catch-all */
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 08:33:41 -04:00
enum proto_proxy_mode mode;
enum proto_proxy_side side;
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 13:40:52 -04:00
const struct mux_ops *mux;
struct list list;
};
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
/* proxy protocol v2 definitions */
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
#define PP2_SIGNATURE "\x0D\x0A\x0D\x0A\x00\x0D\x0A\x51\x55\x49\x54\x0A"
#define PP2_SIGNATURE_LEN 12
#define PP2_HEADER_LEN 16
/* ver_cmd byte */
#define PP2_CMD_LOCAL 0x00
#define PP2_CMD_PROXY 0x01
#define PP2_CMD_MASK 0x0F
#define PP2_VERSION 0x20
#define PP2_VERSION_MASK 0xF0
/* fam byte */
#define PP2_TRANS_UNSPEC 0x00
#define PP2_TRANS_STREAM 0x01
#define PP2_TRANS_DGRAM 0x02
#define PP2_TRANS_MASK 0x0F
#define PP2_FAM_UNSPEC 0x00
#define PP2_FAM_INET 0x10
#define PP2_FAM_INET6 0x20
#define PP2_FAM_UNIX 0x30
#define PP2_FAM_MASK 0xF0
#define PP2_ADDR_LEN_UNSPEC (0)
#define PP2_ADDR_LEN_INET (4 + 4 + 2 + 2)
#define PP2_ADDR_LEN_INET6 (16 + 16 + 2 + 2)
#define PP2_ADDR_LEN_UNIX (108 + 108)
#define PP2_HDR_LEN_UNSPEC (PP2_HEADER_LEN + PP2_ADDR_LEN_UNSPEC)
#define PP2_HDR_LEN_INET (PP2_HEADER_LEN + PP2_ADDR_LEN_INET)
#define PP2_HDR_LEN_INET6 (PP2_HEADER_LEN + PP2_ADDR_LEN_INET6)
#define PP2_HDR_LEN_UNIX (PP2_HEADER_LEN + PP2_ADDR_LEN_UNIX)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
struct proxy_hdr_v2 {
uint8_t sig[12]; /* hex 0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A */
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
uint8_t ver_cmd; /* protocol version and command */
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
uint8_t fam; /* protocol family and transport */
uint16_t len; /* number of following bytes part of the header */
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
union {
struct { /* for TCP/UDP over IPv4, len = 12 */
uint32_t src_addr;
uint32_t dst_addr;
uint16_t src_port;
uint16_t dst_port;
} ip4;
struct { /* for TCP/UDP over IPv6, len = 36 */
uint8_t src_addr[16];
uint8_t dst_addr[16];
uint16_t src_port;
uint16_t dst_port;
} ip6;
struct { /* for AF_UNIX sockets, len = 216 */
uint8_t src_addr[108];
uint8_t dst_addr[108];
} unx;
} addr;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
};
MINOR: update proxy-protocol-v2 #define Report #define from doc/proxy-protocol.txt.
2017-10-13 06:15:28 -04:00
#define PP2_TYPE_ALPN 0x01
#define PP2_TYPE_AUTHORITY 0x02
#define PP2_TYPE_CRC32C 0x03
#define PP2_TYPE_NOOP 0x04
DOC: proxy_protocol: Reserve TLV type 0x05 as PP2_TYPE_UNIQUE_ID This reserves and defines TLV type 0x05.
2020-03-13 07:34:22 -04:00
#define PP2_TYPE_UNIQUE_ID 0x05
MINOR: update proxy-protocol-v2 #define Report #define from doc/proxy-protocol.txt.
2017-10-13 06:15:28 -04:00
#define PP2_TYPE_SSL 0x20
#define PP2_SUBTYPE_SSL_VERSION 0x21
#define PP2_SUBTYPE_SSL_CN 0x22
#define PP2_SUBTYPE_SSL_CIPHER 0x23
#define PP2_SUBTYPE_SSL_SIG_ALG 0x24
#define PP2_SUBTYPE_SSL_KEY_ALG 0x25
#define PP2_TYPE_NETNS 0x30
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
#define TLV_HEADER_SIZE 3
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
struct tlv {
uint8_t type;
uint8_t length_hi;
uint8_t length_lo;
uint8_t value[0];
}__attribute__((packed));
struct tlv_ssl {
struct tlv tlv;
uint8_t client;
uint32_t verify;
uint8_t sub_tlv[0];
}__attribute__((packed));
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
#define PP2_CLIENT_SSL 0x01
#define PP2_CLIENT_CERT_CONN 0x02
#define PP2_CLIENT_CERT_SESS 0x04
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
MINOR: connection: add the fc_pp_authority fetch -- authority TLV, from PROXYv2 Save the authority TLV in a PROXYv2 header from the client connection, if present, and make it available as fc_pp_authority. The fetch can be used, for example, to set the SNI for a backend TLS connection.
2019-08-27 12:31:16 -04:00
/* Max length of the authority TLV */
#define PP2_AUTHORITY_MAX 255
MINOR: cli: Add a command to send listening sockets. Add a new command that will send all the listening sockets, via the stats socket, and their properties. This is a first step to workaround the linux problem when reloading haproxy.
2017-04-05 16:24:59 -04:00
/*
* Linux seems to be able to send 253 fds per sendmsg(), not sure
* about the other OSes.
*/
/* Max number of file descriptors we send in one sendmsg() */
#define MAX_SEND_FD 253
MEDIUM: connection: Upstream SOCKS4 proxy support Have "socks4" and "check-via-socks4" server keyword added. Implement handshake with SOCKS4 proxy server for tcp stream connection. See issue #82. I have the "SOCKS: A protocol for TCP proxy across firewalls" doc found at "https://www.openssh.com/txt/socks4.protocol". Please reference to it. [wt: for now connecting to the SOCKS4 proxy over unix sockets is not supported, and mixing IPv4/IPv6 is discouraged; indeed, the control layer is unique for a connection and will be used both for connecting and for target address manipulation. As such it may for example report incorrect destination addresses in logs if the proxy is reached over IPv6]
2019-05-22 07:44:48 -04:00
#define SOCKS4_HS_RSP_LEN 8
REORG/MINOR: connection: move declaration to its own include file This way we don't depend on stream_interface anymore.
2012-07-06 03:47:57 -04:00
#endif /* _TYPES_CONNECTION_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in a new issue Copy permalink