upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-03-28 13:24:28 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/include/types/connection.h

266 lines
13 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.
*
* Copyright (C) 2000-2012 Willy Tarreau - w@1wt.eu
*
* 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>
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>
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;
struct buffer;
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: 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
/* Polling flags that are manipulated by I/O callbacks and handshake callbacks
* indicate what they expect from a file descriptor at each layer. For each
* direction, we have 2 bits, one stating whether any suspected activity on the
* FD induce a call to the iocb, and another one indicating that the FD has
* already returned EAGAIN and that polling on it is essential before calling
* the iocb again :
* POL ENA state
* 0 0 STOPPED : any activity on this FD is ignored
* 0 1 ENABLED : any (suspected) activity may call the iocb
* 1 0 STOPPED : as above
* 1 1 POLLED : the FD is being polled for activity
*
* - Enabling an I/O event consists in ORing with 1.
* - Stopping an I/O event consists in ANDing with ~1.
* - Polling for an I/O event consists in ORing with ~3.
*
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
* The last ENA state is remembered in CO_FL_CURR_* so that differential
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
* changes can be applied. After bits are applied, the POLL status bits are
* cleared so that it is possible to detect when an EAGAIN was encountered. For
* pollers that do not support speculative I/O, POLLED is the same as ENABLED
* and the POL flag can safely be ignored. However it makes a difference for
* the connection handler.
*
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
* The ENA flags are per-layer (one pair for SOCK, another one for DATA). The
* POL flags are irrelevant to these layers and only reflect the fact that
* EAGAIN was encountered, they're materialised by the CO_FL_WAIT_* connection
* flags. POL flags always indicate a polling change because it is assumed that
* the poller uses a cache and does not always poll.
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() ! */
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
CO_FL_SOCK_RD_ENA = 0x00000001, /* receiving handshakes is allowed */
CO_FL_DATA_RD_ENA = 0x00000002, /* receiving data is allowed */
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_CURR_RD_ENA = 0x00000004, /* receiving is currently allowed */
CO_FL_WAIT_RD = 0x00000008, /* receiving needs to poll first */
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
CO_FL_SOCK_WR_ENA = 0x00000010, /* sending handshakes is desired */
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_DATA_WR_ENA = 0x00000020, /* sending data is desired */
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
CO_FL_CURR_WR_ENA = 0x00000040, /* sending is currently desired */
CO_FL_WAIT_WR = 0x00000080, /* sending needs to poll first */
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
/* These flags are used by data layers to indicate they had to stop
* sending data because a buffer was empty (WAIT_DATA) or stop receiving
* data because a buffer was full (WAIT_ROOM). The connection handler
* clears them 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_DATA = 0x00000400, /* data source is empty */
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 */
/* flags indicating what event type the data layer is interested in */
CO_FL_INIT_DATA = 0x00004000, /* initialize the data layer before using it */
CO_FL_WAKE_DATA = 0x00008000, /* wake-up data layer upon activity at the transport layer */
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_DATA_RD_SH = 0x00010000, /* DATA layer was notified about shutr/read0 */
CO_FL_DATA_WR_SH = 0x00020000, /* DATA layer asked for shutw */
CO_FL_SOCK_RD_SH = 0x00040000, /* SOCK layer was notified about shutr/read0 */
CO_FL_SOCK_WR_SH = 0x00080000, /* SOCK layer asked for shutw */
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
/* flags used to report connection status and errors */
CO_FL_ERROR = 0x00100000, /* a fatal error was reported */
CO_FL_CONNECTED = 0x00200000, /* the connection is now established */
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) */
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: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
/* synthesis of the flags above */
CO_FL_CONN_STATE = 0x00FF0000, /* all shut/connected flags */
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
/*** All the flags below are used for connection handshakes. Any new
* 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: 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_SI_SEND_PROXY = 0x01000000, /* send a valid PROXY protocol header */
CO_FL_SSL_WAIT_HS = 0x02000000, /* wait for an SSL handshake to complete */
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
CO_FL_ACCEPT_PROXY = 0x04000000, /* receive a valid PROXY protocol header */
CO_FL_LOCAL_SPROXY = 0x08000000, /* send a valid local PROXY protocol 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 */
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
CO_FL_HANDSHAKE = CO_FL_SI_SEND_PROXY | CO_FL_SSL_WAIT_HS | CO_FL_ACCEPT_PROXY | CO_FL_LOCAL_SPROXY,
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
/* when any of these flags is set, polling is defined by socket-layer
* operations, as opposed to data-layer. Transport is explicitly not
* mentionned here to avoid any confusion, since it can be the same
* as DATA or SOCK on some implementations.
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: 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_POLL_SOCK = CO_FL_HANDSHAKE | CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN,
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: 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 */
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 */
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 */
CO_ER_SSL_RENEG, /* forbidden client renegociation */
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 */
CO_ER_SSL_HANDSHAKE, /* SSL error during handshake */
CO_ER_SSL_NO_TARGET, /* unkonwn target (not client nor 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 */
};
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 {
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
int (*rcv_buf)(struct connection *conn, struct buffer *buf, int count); /* recv callback */
int (*snd_buf)(struct connection *conn, struct buffer *buf, int flags); /* send callback */
int (*rcv_pipe)(struct connection *conn, struct pipe *pipe, unsigned int count); /* recv-to-pipe callback */
int (*snd_pipe)(struct connection *conn, struct pipe *pipe); /* send-to-pipe callback */
void (*shutr)(struct connection *, int); /* shutr function */
void (*shutw)(struct connection *, int); /* shutw function */
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
void (*close)(struct connection *); /* close the transport layer */
int (*init)(struct connection *conn); /* initialize 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 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
MINOR: connection: add an init callback to the data_cb struct This callback is used to initialize the data layer.
2012-10-02 19:12:30 -04:00
* data movement. The <init> callback may be called by the connection handler
* at the end of a transport handshake, when it is about to transfer data and
MEDIUM: connection: make it possible for data->wake to return an error Just like ->init(), ->wake() may now be used to return an error and abort the connection. Currently this is not used but will be with embryonic sessions.
2012-10-03 15:12:16 -04:00
* the data layer is not ready yet. Both <wake> and <init> 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 {
void (*recv)(struct connection *conn); /* data-layer recv callback */
void (*send)(struct connection *conn); /* data-layer send callback */
MEDIUM: connection: make it possible for data->wake to return an error Just like ->init(), ->wake() may now be used to return an error and abort the connection. Currently this is not used but will be with embryonic sessions.
2012-10-03 15:12:16 -04:00
int (*wake)(struct connection *conn); /* data-layer callback to report activity */
MINOR: connection: add an init callback to the data_cb struct This callback is used to initialize the data layer.
2012-10-02 19:12:30 -04:00
int (*init)(struct connection *conn); /* data-layer initialization */
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
};
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() */
#if defined(CONFIG_HAP_CTTPROXY) || defined(CONFIG_HAP_LINUX_TPROXY)
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
};
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
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
* several transport schemes (applet, 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
* connections, but other methods for applets.
*/
struct connection {
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 */
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
const struct data_cb *data; /* data layer callbacks */
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
unsigned int flags; /* CO_FL_* */
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
int xprt_st; /* transport layer state, initialized to zero */
void *xprt_ctx; /* general purpose pointer, initialized to NULL */
MINOR: connection: add a pointer to the connection owner This will be needed to find the stream interface from the connection once they're detached, but in the more immediate term, we'll need this for health checks since they don't use a stream interface.
2012-09-27 16:14:33 -04:00
void *owner; /* pointer to upper layer's entity (eg: stream interface) */
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
union { /* definitions which depend on connection type */
struct { /*** information used by socket-based connections ***/
int fd; /* file descriptor for a stream driver when known */
} sock;
} t;
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
unsigned int err_code; /* CO_ER_* */
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
enum obj_type *target; /* the target to connect to (server, proxy, applet, ...) */
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
struct {
struct sockaddr_storage from; /* client address, or address to spoof when connecting to the server */
MINOR: connection: add a pointer to the connection owner This will be needed to find the stream interface from the connection once they're detached, but in the more immediate term, we'll need this for health checks since they don't use a stream interface.
2012-09-27 16:14:33 -04:00
struct sockaddr_storage to; /* address reached by the client, or address to connect to */
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
} addr; /* addresses of the remote side, client for producer and server for consumer */
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