RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-13 15:04:42 +00:00
Code Issues Packages Projects Releases Wiki Activity
b1900d55df
haproxy/include/proto/connection.h

602 lines
20 KiB
C
Raw Normal View History

MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
/*
* include/proto/connection.h
* This file contains connection function prototypes
*
* 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 _PROTO_CONNECTION_H
#define _PROTO_CONNECTION_H
#include <common/config.h>
MAJOR: session: detach the connections from the stream interfaces We will need to be able to switch server connections on a session and to keep idle connections. In order to achieve this, the preliminary requirement is that the connections can survive the session and be detached from them. Right now they're still allocated at exactly the same place, so when there is a session, there are always 2 connections. We could soon improve on this by allocating the outgoing connection only during a connect(). This current patch touches a lot of code and intentionally does not change any functionnality. Performance tests show no regression (even a very minor improvement). The doc has not yet been updated.
2012-10-26 18:10:28 +00:00
#include <common/memory.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
#include <types/connection.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 20:58:11 +00:00
#include <types/listener.h>
MEDIUM: connection: provide a common conn_full_close() function Several places got the connection close sequence wrong because it was not obvious. In practice we always need the same sequence when aborting, so let's have a common function for this.
2012-11-23 16:32:21 +00:00
#include <proto/fd.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 23:42:33 +00:00
#include <proto/obj_type.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
MAJOR: session: detach the connections from the stream interfaces We will need to be able to switch server connections on a session and to keep idle connections. In order to achieve this, the preliminary requirement is that the connections can survive the session and be detached from them. Right now they're still allocated at exactly the same place, so when there is a session, there are always 2 connections. We could soon improve on this by allocating the outgoing connection only during a connect(). This current patch touches a lot of code and intentionally does not change any functionnality. Performance tests show no regression (even a very minor improvement). The doc has not yet been updated.
2012-10-26 18:10:28 +00:00
extern struct pool_head *pool2_connection;
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
int init_connection();
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
/* I/O callback for fd-based connections. It calls the read/write handlers
MAJOR: make use of conn_{data|sock}_{poll|stop|want}* in connection handlers This is a second attempt at getting rid of FD_WAIT_*. Now the situation is much better since native I/O handlers can directly manipulate the FD using fd_{poll|want|stop}_* and the connection handlers manipulate connection-level flags using the conn_{data|sock}_* equivalent. Proceeding this way ensures that the connection flags always reflect the reality even after data<->handshake switches.
2012-08-09 12:45:22 +00:00
* provided by the connection's sock_ops. Returns 0.
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
*/
int conn_fd_handler(int fd);
MAJOR: connection: make the PROXY decoder a handshake handler The PROXY protocol is now decoded in the connection before other handshakes. This means that it may be extracted from a TCP stream before SSL is decoded from this stream.
2012-08-31 15:43:29 +00:00
/* receive a PROXY protocol header over a connection */
int conn_recv_proxy(struct connection *conn, int flag);
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-09 03:42:08 +00:00
int make_proxy_line(char *buf, int buf_len, struct server *srv, struct connection *remote);
int make_proxy_line_v1(char *buf, int buf_len, struct sockaddr_storage *src, struct sockaddr_storage *dst);
int make_proxy_line_v2(char *buf, int buf_len, struct server *srv, struct connection *remote);
MAJOR: connection: make the PROXY decoder a handshake handler The PROXY protocol is now decoded in the connection before other handshakes. This means that it may be extracted from a TCP stream before SSL is decoded from this stream.
2012-08-31 15:43:29 +00:00
MINOR: connection: add simple functions to report connection readiness conn_xprt_ready() reports if the transport layer is ready. conn_ctrl_ready() reports if the control layer is ready. The stream interface uses si_conn_ready() to report that the underlying connection is ready. This will be used for connection reuse in keep-alive mode.
2013-12-15 09:23:20 +00:00
/* returns true is the transport layer is ready */
CLEANUP: connection: use conn_xprt_ready() instead of checking the flag It's easier and safer to rely on conn_xprt_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !xprt have been removed, as the XPRT_READY flag itself guarantees xprt is set.
2014-01-23 13:21:42 +00:00
static inline int conn_xprt_ready(const struct connection *conn)
MINOR: connection: add simple functions to report connection readiness conn_xprt_ready() reports if the transport layer is ready. conn_ctrl_ready() reports if the control layer is ready. The stream interface uses si_conn_ready() to report that the underlying connection is ready. This will be used for connection reuse in keep-alive mode.
2013-12-15 09:23:20 +00:00
{
CLEANUP: connection: use conn_xprt_ready() instead of checking the flag It's easier and safer to rely on conn_xprt_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !xprt have been removed, as the XPRT_READY flag itself guarantees xprt is set.
2014-01-23 13:21:42 +00:00
return (conn->flags & CO_FL_XPRT_READY);
MINOR: connection: add simple functions to report connection readiness conn_xprt_ready() reports if the transport layer is ready. conn_ctrl_ready() reports if the control layer is ready. The stream interface uses si_conn_ready() to report that the underlying connection is ready. This will be used for connection reuse in keep-alive mode.
2013-12-15 09:23:20 +00:00
}
/* returns true is the control layer is ready */
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
static inline int conn_ctrl_ready(const struct connection *conn)
MINOR: connection: add simple functions to report connection readiness conn_xprt_ready() reports if the transport layer is ready. conn_ctrl_ready() reports if the control layer is ready. The stream interface uses si_conn_ready() to report that the underlying connection is ready. This will be used for connection reuse in keep-alive mode.
2013-12-15 09:23:20 +00:00
{
return (conn->flags & CO_FL_CTRL_READY);
}
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 14:30:56 +00:00
/* Calls the init() function of the transport layer if any and if not done yet,
* and sets the CO_FL_XPRT_READY flag to indicate it was properly initialized.
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 22:19:48 +00:00
* Returns <0 in case of error.
MEDIUM: connection: add an ->init function to data layer SSL need to initialize the data layer before proceeding with data. At the moment, this data layer is automatically initialized from itself, which will not be possible once we extract connection from sessions since we'll only create the data layer once the handshake is finished. So let's have the application layer initialize the data layer before using it.
2012-08-31 11:54:11 +00: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 22:19:48 +00:00
static inline int conn_xprt_init(struct connection *conn)
MEDIUM: connection: add an ->init function to data layer SSL need to initialize the data layer before proceeding with data. At the moment, this data layer is automatically initialized from itself, which will not be possible once we extract connection from sessions since we'll only create the data layer once the handshake is finished. So let's have the application layer initialize the data layer before using it.
2012-08-31 11:54:11 +00: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 14:30:56 +00:00
int ret = 0;
CLEANUP: connection: use conn_xprt_ready() instead of checking the flag It's easier and safer to rely on conn_xprt_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !xprt have been removed, as the XPRT_READY flag itself guarantees xprt is set.
2014-01-23 13:21:42 +00:00
if (!conn_xprt_ready(conn) && conn->xprt && conn->xprt->init)
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 14:30:56 +00:00
ret = conn->xprt->init(conn);
if (ret >= 0)
conn->flags |= CO_FL_XPRT_READY;
return ret;
MEDIUM: connection: add an ->init function to data layer SSL need to initialize the data layer before proceeding with data. At the moment, this data layer is automatically initialized from itself, which will not be possible once we extract connection from sessions since we'll only create the data layer once the handshake is finished. So let's have the application layer initialize the data layer before using it.
2012-08-31 11:54:11 +00: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 14:30:56 +00:00
/* Calls the close() function of the transport layer if any and if not done
* yet, and clears the CO_FL_XPRT_READY flag. However this is not done if the
* CO_FL_XPRT_TRACKED flag is set, which allows logs to take data from the
* transport layer very late if needed.
MEDIUM: connection: always unset the transport layer upon close When calling conn_xprt_close(), we always clear the transport pointer so that all transport layers leave the connection in the same state after a close. This will also make it safer and cheaper to call conn_xprt_close() multiple times if needed.
2012-10-12 15:00:05 +00: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 22:19:48 +00:00
static inline void conn_xprt_close(struct connection *conn)
REORG: connection: replace si_data_close() with conn_data_close() This close function only applies to connection-specific parts and the stream-interface entry may soon disappear. Move this to the connection instead.
2012-08-06 13:06:49 +00: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 14:30:56 +00:00
if ((conn->flags & (CO_FL_XPRT_READY|CO_FL_XPRT_TRACKED)) == CO_FL_XPRT_READY) {
CLEANUP: connection: use conn_xprt_ready() instead of checking the flag It's easier and safer to rely on conn_xprt_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !xprt have been removed, as the XPRT_READY flag itself guarantees xprt is set.
2014-01-23 13:21:42 +00:00
if (conn->xprt->close)
MEDIUM: connection: always unset the transport layer upon close When calling conn_xprt_close(), we always clear the transport pointer so that all transport layers leave the connection in the same state after a close. This will also make it safer and cheaper to call conn_xprt_close() multiple times if needed.
2012-10-12 15:00:05 +00:00
conn->xprt->close(conn);
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 14:30:56 +00:00
conn->flags &= ~CO_FL_XPRT_READY;
}
}
/* Initializes the connection's control layer which essentially consists in
* registering the file descriptor for polling and setting the CO_FL_CTRL_READY
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
* flag. The caller is responsible for ensuring that the control layer is
* already assigned to the connection prior to the call.
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 14:30:56 +00:00
*/
static inline void conn_ctrl_init(struct connection *conn)
{
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (!conn_ctrl_ready(conn)) {
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 14:30:56 +00:00
int fd = conn->t.sock.fd;
fd_insert(fd);
MAJOR: polling: rework the whole polling system This commit heavily changes the polling system in order to definitely fix the frequent breakage of SSL which needs to remember the last EAGAIN before deciding whether to poll or not. Now we have a state per direction for each FD, as opposed to a previous and current state previously. An FD can have up to 8 different states for each direction, each of which being the result of a 3-bit combination. These 3 bits indicate a wish to access the FD, the readiness of the FD and the subscription of the FD to the polling system. This means that it will now be possible to remember the state of a file descriptor across disable/enable sequences that generally happen during forwarding, where enabling reading on a previously disabled FD would result in forgetting the EAGAIN flag it met last time. Several new state manipulation functions have been introduced or adapted : - fd_want_{recv,send} : enable receiving/sending on the FD regardless of its state (sets the ACTIVE flag) ; - fd_stop_{recv,send} : stop receiving/sending on the FD regardless of its state (clears the ACTIVE flag) ; - fd_cant_{recv,send} : report a failure to receive/send on the FD corresponding to EAGAIN (clears the READY flag) ; - fd_may_{recv,send} : report the ability to receive/send on the FD as reported by poll() (sets the READY flag) ; Some functions are used to report the current FD status : - fd_{recv,send}_active - fd_{recv,send}_ready - fd_{recv,send}_polled Some functions were removed : - fd_ev_clr(), fd_ev_set(), fd_ev_rem(), fd_ev_wai() The POLLHUP/POLLERR flags are now reported as ready so that the I/O layers knows it can try to access the file descriptor to get this information. In order to simplify the conditions to add/remove cache entries, a new function fd_alloc_or_release_cache_entry() was created to be used from pollers while scanning for updates. The following pollers have been updated : ev_select() : done, built, tested on Linux 3.10 ev_poll() : done, built, tested on Linux 3.10 ev_epoll() : done, built, tested on Linux 3.10 & 3.13 ev_kqueue() : done, built, tested on OpenBSD 5.2
2014-01-10 15:58:45 +00:00
/* mark the fd as ready so as not to needlessly poll at the beginning */
fd_may_recv(fd);
fd_may_send(fd);
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 14:30:56 +00:00
fdtab[fd].owner = conn;
fdtab[fd].iocb = conn_fd_handler;
conn->flags |= CO_FL_CTRL_READY;
}
}
/* Deletes the FD if the transport layer is already gone. Once done,
* it then removes the CO_FL_CTRL_READY flag.
*/
static inline void conn_ctrl_close(struct connection *conn)
{
if ((conn->flags & (CO_FL_XPRT_READY|CO_FL_CTRL_READY)) == CO_FL_CTRL_READY) {
fd_delete(conn->t.sock.fd);
conn->flags &= ~CO_FL_CTRL_READY;
MEDIUM: connection: always unset the transport layer upon close When calling conn_xprt_close(), we always clear the transport pointer so that all transport layers leave the connection in the same state after a close. This will also make it safer and cheaper to call conn_xprt_close() multiple times if needed.
2012-10-12 15:00:05 +00:00
}
REORG: connection: replace si_data_close() with conn_data_close() This close function only applies to connection-specific parts and the stream-interface entry may soon disappear. Move this to the connection instead.
2012-08-06 13:06:49 +00:00
}
MEDIUM: connection: provide a common conn_full_close() function Several places got the connection close sequence wrong because it was not obvious. In practice we always need the same sequence when aborting, so let's have a common function for this.
2012-11-23 16:32:21 +00:00
/* If the connection still has a transport layer, then call its close() function
* if any, and delete the file descriptor if a control layer is set. This is
* used to close everything at once and atomically. However this is not done if
* the CO_FL_XPRT_TRACKED flag is set, which allows logs to take data from the
* transport layer very late if needed.
*/
static inline void conn_full_close(struct connection *conn)
{
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 14:30:56 +00:00
conn_xprt_close(conn);
conn_ctrl_close(conn);
}
/* Force to close the connection whatever the tracking state. This is mainly
MEDIUM: connection: inform si_alloc_conn() whether existing conn is OK or not When allocating a new connection, only the caller knows whether it's acceptable to reuse the previous one or not. Let's pass this information to si_alloc_conn() which will do the cleanup if the connection is not acceptable.
2013-12-15 12:31:35 +00:00
* used on the error path where the tracking does not make sense, or to kill
* an idle connection we want to abort immediately.
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 14:30:56 +00:00
*/
static inline void conn_force_close(struct connection *conn)
{
CLEANUP: connection: use conn_xprt_ready() instead of checking the flag It's easier and safer to rely on conn_xprt_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !xprt have been removed, as the XPRT_READY flag itself guarantees xprt is set.
2014-01-23 13:21:42 +00:00
if (conn_xprt_ready(conn) && conn->xprt->close)
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 14:30:56 +00:00
conn->xprt->close(conn);
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (conn_ctrl_ready(conn))
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 14:30:56 +00:00
fd_delete(conn->t.sock.fd);
conn->flags &= ~(CO_FL_XPRT_READY|CO_FL_CTRL_READY);
MEDIUM: connection: provide a common conn_full_close() function Several places got the connection close sequence wrong because it was not obvious. In practice we always need the same sequence when aborting, so let's have a common function for this.
2012-11-23 16:32:21 +00:00
}
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 15:26:16 +00:00
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the sock layer expectations indicated by CO_FL_SOCK_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 20:21:15 +00:00
* operation. Polling is totally disabled if an error was reported.
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 09:55:04 +00:00
*/
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 15:26:16 +00:00
void conn_update_sock_polling(struct connection *c);
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 09:55:04 +00:00
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 15:26:16 +00:00
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the data layer expectations indicated by CO_FL_DATA_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 20:21:15 +00:00
* operation. Polling is totally disabled if an error was reported.
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 09:55:04 +00:00
*/
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 15:26:16 +00:00
void conn_update_data_polling(struct connection *c);
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 09:55:04 +00:00
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 18:19:13 +00:00
/* Refresh the connection's polling flags from its file descriptor status.
* This should be called at the beginning of a connection handler.
*/
static inline void conn_refresh_polling_flags(struct connection *conn)
{
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
conn->flags &= ~(CO_FL_WAIT_ROOM | CO_FL_WAIT_DATA);
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 18:19:13 +00:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (conn_ctrl_ready(conn)) {
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 18:19:13 +00:00
unsigned int flags = conn->flags & ~(CO_FL_CURR_RD_ENA | CO_FL_CURR_WR_ENA);
MAJOR: polling: rework the whole polling system This commit heavily changes the polling system in order to definitely fix the frequent breakage of SSL which needs to remember the last EAGAIN before deciding whether to poll or not. Now we have a state per direction for each FD, as opposed to a previous and current state previously. An FD can have up to 8 different states for each direction, each of which being the result of a 3-bit combination. These 3 bits indicate a wish to access the FD, the readiness of the FD and the subscription of the FD to the polling system. This means that it will now be possible to remember the state of a file descriptor across disable/enable sequences that generally happen during forwarding, where enabling reading on a previously disabled FD would result in forgetting the EAGAIN flag it met last time. Several new state manipulation functions have been introduced or adapted : - fd_want_{recv,send} : enable receiving/sending on the FD regardless of its state (sets the ACTIVE flag) ; - fd_stop_{recv,send} : stop receiving/sending on the FD regardless of its state (clears the ACTIVE flag) ; - fd_cant_{recv,send} : report a failure to receive/send on the FD corresponding to EAGAIN (clears the READY flag) ; - fd_may_{recv,send} : report the ability to receive/send on the FD as reported by poll() (sets the READY flag) ; Some functions are used to report the current FD status : - fd_{recv,send}_active - fd_{recv,send}_ready - fd_{recv,send}_polled Some functions were removed : - fd_ev_clr(), fd_ev_set(), fd_ev_rem(), fd_ev_wai() The POLLHUP/POLLERR flags are now reported as ready so that the I/O layers knows it can try to access the file descriptor to get this information. In order to simplify the conditions to add/remove cache entries, a new function fd_alloc_or_release_cache_entry() was created to be used from pollers while scanning for updates. The following pollers have been updated : ev_select() : done, built, tested on Linux 3.10 ev_poll() : done, built, tested on Linux 3.10 ev_epoll() : done, built, tested on Linux 3.10 & 3.13 ev_kqueue() : done, built, tested on OpenBSD 5.2
2014-01-10 15:58:45 +00:00
if (fd_recv_active(conn->t.sock.fd))
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 18:19:13 +00:00
flags |= CO_FL_CURR_RD_ENA;
MAJOR: polling: rework the whole polling system This commit heavily changes the polling system in order to definitely fix the frequent breakage of SSL which needs to remember the last EAGAIN before deciding whether to poll or not. Now we have a state per direction for each FD, as opposed to a previous and current state previously. An FD can have up to 8 different states for each direction, each of which being the result of a 3-bit combination. These 3 bits indicate a wish to access the FD, the readiness of the FD and the subscription of the FD to the polling system. This means that it will now be possible to remember the state of a file descriptor across disable/enable sequences that generally happen during forwarding, where enabling reading on a previously disabled FD would result in forgetting the EAGAIN flag it met last time. Several new state manipulation functions have been introduced or adapted : - fd_want_{recv,send} : enable receiving/sending on the FD regardless of its state (sets the ACTIVE flag) ; - fd_stop_{recv,send} : stop receiving/sending on the FD regardless of its state (clears the ACTIVE flag) ; - fd_cant_{recv,send} : report a failure to receive/send on the FD corresponding to EAGAIN (clears the READY flag) ; - fd_may_{recv,send} : report the ability to receive/send on the FD as reported by poll() (sets the READY flag) ; Some functions are used to report the current FD status : - fd_{recv,send}_active - fd_{recv,send}_ready - fd_{recv,send}_polled Some functions were removed : - fd_ev_clr(), fd_ev_set(), fd_ev_rem(), fd_ev_wai() The POLLHUP/POLLERR flags are now reported as ready so that the I/O layers knows it can try to access the file descriptor to get this information. In order to simplify the conditions to add/remove cache entries, a new function fd_alloc_or_release_cache_entry() was created to be used from pollers while scanning for updates. The following pollers have been updated : ev_select() : done, built, tested on Linux 3.10 ev_poll() : done, built, tested on Linux 3.10 ev_epoll() : done, built, tested on Linux 3.10 & 3.13 ev_kqueue() : done, built, tested on OpenBSD 5.2
2014-01-10 15:58:45 +00:00
if (fd_send_active(conn->t.sock.fd))
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 18:19:13 +00:00
flags |= CO_FL_CURR_WR_ENA;
conn->flags = flags;
}
}
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 15:26:16 +00:00
/* inspects c->flags and returns non-zero if DATA ENA changes from the CURR ENA
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 16:52:26 +00:00
* or if the WAIT flags are set with their respective ENA flags. Additionally,
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 20:21:15 +00:00
* non-zero is also returned if an error was reported on the connection. This
* function is used quite often and is inlined. In order to proceed optimally
* with very little code and CPU cycles, the bits are arranged so that a change
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 16:52:26 +00:00
* can be detected by a few left shifts, a xor, and a mask. These operations
* detect when W&D are both enabled for either direction, when C&D differ for
* either direction and when Error is set. The trick consists in first keeping
* only the bits we're interested in, since they don't collide when shifted,
* and to perform the AND at the end. In practice, the compiler is able to
* replace the last AND with a TEST in boolean conditions. This results in
* checks that are done in 4-6 cycles and less than 30 bytes.
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 09:55:04 +00:00
*/
static inline unsigned int conn_data_polling_changes(const struct connection *c)
{
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 16:52:26 +00:00
unsigned int f = c->flags;
f &= CO_FL_DATA_WR_ENA | CO_FL_DATA_RD_ENA | CO_FL_CURR_WR_ENA |
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
CO_FL_CURR_RD_ENA | CO_FL_ERROR;
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 16:52:26 +00:00
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
f = (f ^ (f << 1)) & (CO_FL_CURR_WR_ENA|CO_FL_CURR_RD_ENA); /* test C ^ D */
return f & (CO_FL_CURR_WR_ENA | CO_FL_CURR_RD_ENA | CO_FL_ERROR);
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 09:55:04 +00:00
}
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 15:26:16 +00:00
/* inspects c->flags and returns non-zero if SOCK ENA changes from the CURR ENA
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 16:52:26 +00:00
* or if the WAIT flags are set with their respective ENA flags. Additionally,
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 20:21:15 +00:00
* non-zero is also returned if an error was reported on the connection. This
* function is used quite often and is inlined. In order to proceed optimally
* with very little code and CPU cycles, the bits are arranged so that a change
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 16:52:26 +00:00
* can be detected by a few left shifts, a xor, and a mask. These operations
* detect when W&S are both enabled for either direction, when C&S differ for
* either direction and when Error is set. The trick consists in first keeping
* only the bits we're interested in, since they don't collide when shifted,
* and to perform the AND at the end. In practice, the compiler is able to
* replace the last AND with a TEST in boolean conditions. This results in
* checks that are done in 4-6 cycles and less than 30 bytes.
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 09:55:04 +00:00
*/
static inline unsigned int conn_sock_polling_changes(const struct connection *c)
{
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 16:52:26 +00:00
unsigned int f = c->flags;
f &= CO_FL_SOCK_WR_ENA | CO_FL_SOCK_RD_ENA | CO_FL_CURR_WR_ENA |
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
CO_FL_CURR_RD_ENA | CO_FL_ERROR;
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 16:52:26 +00:00
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
f = (f ^ (f << 2)) & (CO_FL_CURR_WR_ENA|CO_FL_CURR_RD_ENA); /* test C ^ S */
return f & (CO_FL_CURR_WR_ENA | CO_FL_CURR_RD_ENA | CO_FL_ERROR);
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 09:55:04 +00:00
}
/* Automatically updates polling on connection <c> depending on the DATA flags
* if no handshake is in progress.
*/
static inline void conn_cond_update_data_polling(struct connection *c)
{
if (!(c->flags & CO_FL_POLL_SOCK) && conn_data_polling_changes(c))
conn_update_data_polling(c);
}
/* Automatically updates polling on connection <c> depending on the SOCK flags
* if a handshake is in progress.
*/
static inline void conn_cond_update_sock_polling(struct connection *c)
{
if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(c);
}
BUG/MEDIUM: connection: always disable polling upon error Commit 0ffde2cc in 1.5-dev13 tried to always disable polling on file descriptors when errors were encountered. Unfortunately it did not always succeed in doing so because it relied on detecting polling changes to disable it. Let's use a dedicated conn_stop_polling() function that is inconditionally called upon error instead. This managed to stop a busy loop observed when a health check makes use of the send-proxy protocol and fails before the connection can be established.
2012-11-24 10:09:07 +00:00
/* Stop all polling on the fd. This might be used when an error is encountered
* for example.
*/
static inline void conn_stop_polling(struct connection *c)
{
c->flags &= ~(CO_FL_CURR_RD_ENA | CO_FL_CURR_WR_ENA |
CO_FL_SOCK_RD_ENA | CO_FL_SOCK_WR_ENA |
CO_FL_DATA_RD_ENA | CO_FL_DATA_WR_ENA);
fd_stop_both(c->t.sock.fd);
}
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 09:55:04 +00:00
/* Automatically update polling on connection <c> depending on the DATA and
* SOCK flags, and on whether a handshake is in progress or not. This may be
* called at any moment when there is a doubt about the effectiveness of the
* polling state, for instance when entering or leaving the handshake state.
*/
static inline void conn_cond_update_polling(struct connection *c)
{
BUG/MEDIUM: connection: always disable polling upon error Commit 0ffde2cc in 1.5-dev13 tried to always disable polling on file descriptors when errors were encountered. Unfortunately it did not always succeed in doing so because it relied on detecting polling changes to disable it. Let's use a dedicated conn_stop_polling() function that is inconditionally called upon error instead. This managed to stop a busy loop observed when a health check makes use of the send-proxy protocol and fails before the connection can be established.
2012-11-24 10:09:07 +00:00
if (unlikely(c->flags & CO_FL_ERROR))
conn_stop_polling(c);
else if (!(c->flags & CO_FL_POLL_SOCK) && conn_data_polling_changes(c))
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 09:55:04 +00:00
conn_update_data_polling(c);
else if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(c);
}
/***** Event manipulation primitives for use by DATA I/O callbacks *****/
/* The __conn_* versions do not propagate to lower layers and are only meant
* to be used by handlers called by the connection handler. The other ones
* may be used anywhere.
*/
static inline void __conn_data_want_recv(struct connection *c)
{
c->flags |= CO_FL_DATA_RD_ENA;
}
static inline void __conn_data_stop_recv(struct connection *c)
{
c->flags &= ~CO_FL_DATA_RD_ENA;
}
static inline void __conn_data_want_send(struct connection *c)
{
c->flags |= CO_FL_DATA_WR_ENA;
}
static inline void __conn_data_stop_send(struct connection *c)
{
c->flags &= ~CO_FL_DATA_WR_ENA;
}
static inline void __conn_data_stop_both(struct connection *c)
{
c->flags &= ~(CO_FL_DATA_WR_ENA | CO_FL_DATA_RD_ENA);
}
static inline void conn_data_want_recv(struct connection *c)
{
__conn_data_want_recv(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_recv(struct connection *c)
{
__conn_data_stop_recv(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_want_send(struct connection *c)
{
__conn_data_want_send(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_send(struct connection *c)
{
__conn_data_stop_send(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_both(struct connection *c)
{
__conn_data_stop_both(c);
conn_cond_update_data_polling(c);
}
/***** Event manipulation primitives for use by handshake I/O callbacks *****/
/* The __conn_* versions do not propagate to lower layers and are only meant
* to be used by handlers called by the connection handler. The other ones
* may be used anywhere.
*/
static inline void __conn_sock_want_recv(struct connection *c)
{
c->flags |= CO_FL_SOCK_RD_ENA;
}
static inline void __conn_sock_stop_recv(struct connection *c)
{
c->flags &= ~CO_FL_SOCK_RD_ENA;
}
static inline void __conn_sock_want_send(struct connection *c)
{
c->flags |= CO_FL_SOCK_WR_ENA;
}
static inline void __conn_sock_stop_send(struct connection *c)
{
c->flags &= ~CO_FL_SOCK_WR_ENA;
}
static inline void __conn_sock_stop_both(struct connection *c)
{
c->flags &= ~(CO_FL_SOCK_WR_ENA | CO_FL_SOCK_RD_ENA);
}
static inline void conn_sock_want_recv(struct connection *c)
{
__conn_sock_want_recv(c);
conn_cond_update_sock_polling(c);
}
static inline void conn_sock_stop_recv(struct connection *c)
{
__conn_sock_stop_recv(c);
conn_cond_update_sock_polling(c);
}
static inline void conn_sock_want_send(struct connection *c)
{
__conn_sock_want_send(c);
conn_cond_update_sock_polling(c);
}
static inline void conn_sock_stop_send(struct connection *c)
{
__conn_sock_stop_send(c);
conn_cond_update_sock_polling(c);
}
static inline void conn_sock_stop_both(struct connection *c)
{
__conn_sock_stop_both(c);
conn_cond_update_sock_polling(c);
}
REORG: connection: replace si_data_close() with conn_data_close() This close function only applies to connection-specific parts and the stream-interface entry may soon disappear. Move this to the connection instead.
2012-08-06 13:06:49 +00:00
MINOR: connection: provide conn_{data|sock}_{read0|shutw} functions These functions are used to report unidirectional shutdown and to disable polling in the related direction.
2012-08-20 14:55:48 +00:00
/* shutdown management */
static inline void conn_sock_read0(struct connection *c)
{
c->flags |= CO_FL_SOCK_RD_SH;
__conn_sock_stop_recv(c);
MEDIUM: connection: centralize handling of nolinger in fd management Right now we see many places doing their own setsockopt(SO_LINGER). Better only do it just before the close() in fd_delete(). For this we add a new flag on the file descriptor, indicating if it's safe or not to linger. If not (eg: after a connect()), then the setsockopt() call is automatically performed before a close(). The flag automatically turns to safe when receiving a read0.
2013-12-15 13:19:38 +00:00
/* we don't risk keeping ports unusable if we found the
* zero from the other side.
*/
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (conn_ctrl_ready(c))
MEDIUM: connection: centralize handling of nolinger in fd management Right now we see many places doing their own setsockopt(SO_LINGER). Better only do it just before the close() in fd_delete(). For this we add a new flag on the file descriptor, indicating if it's safe or not to linger. If not (eg: after a connect()), then the setsockopt() call is automatically performed before a close(). The flag automatically turns to safe when receiving a read0.
2013-12-15 13:19:38 +00:00
fdtab[c->t.sock.fd].linger_risk = 0;
MINOR: connection: provide conn_{data|sock}_{read0|shutw} functions These functions are used to report unidirectional shutdown and to disable polling in the related direction.
2012-08-20 14:55:48 +00:00
}
static inline void conn_data_read0(struct connection *c)
{
c->flags |= CO_FL_DATA_RD_SH;
__conn_data_stop_recv(c);
}
static inline void conn_sock_shutw(struct connection *c)
{
c->flags |= CO_FL_SOCK_WR_SH;
__conn_sock_stop_send(c);
}
static inline void conn_data_shutw(struct connection *c)
{
c->flags |= CO_FL_DATA_WR_SH;
__conn_data_stop_send(c);
}
/* detect sock->data read0 transition */
static inline int conn_data_read0_pending(struct connection *c)
{
return (c->flags & (CO_FL_DATA_RD_SH | CO_FL_SOCK_RD_SH)) == CO_FL_SOCK_RD_SH;
}
/* detect data->sock shutw transition */
static inline int conn_sock_shutw_pending(struct connection *c)
{
return (c->flags & (CO_FL_DATA_WR_SH | CO_FL_SOCK_WR_SH)) == CO_FL_DATA_WR_SH;
}
MINOR: connection: reintroduce conn_prepare to set the protocol and transport Now that we can assign conn->xprt regardless of the initialization state, we can reintroduce conn_prepare() to set only the protocol, the transport layer and initialize the transport layer's state.
2013-10-24 13:08:37 +00:00
/* prepares a connection to work with protocol <proto> and transport <xprt>.
* The transport's context is initialized as well.
*/
static inline void conn_prepare(struct connection *conn, const struct protocol *proto, const struct xprt_ops *xprt)
{
conn->ctrl = proto;
conn->xprt = xprt;
conn->xprt_st = 0;
conn->xprt_ctx = NULL;
}
MINOR: connection: add conn_init() to (re)initialize a connection This function will ease the initialization of new connections as well as their reuse. It initializes the obj_type and a few fields so that the connection is fresh again. It leaves the addresses and target untouched so it is suitable for use across connection retries.
2013-10-14 15:10:08 +00:00
/* Initializes all required fields for a new connection. Note that it does the
* minimum acceptable initialization for a connection that already exists and
* is about to be reused. It also leaves the addresses untouched, which makes
* it usable across connection retries to reset a connection to a known state.
*/
static inline void conn_init(struct connection *conn)
{
conn->obj_type = OBJ_TYPE_CONN;
conn->flags = CO_FL_NONE;
conn->data = NULL;
conn->owner = NULL;
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 19:10:08 +00:00
conn->send_proxy_ofs = 0;
MINOR: connection: add conn_init() to (re)initialize a connection This function will ease the initialization of new connections as well as their reuse. It initializes the obj_type and a few fields so that the connection is fresh again. It leaves the addresses and target untouched so it is suitable for use across connection retries.
2013-10-14 15:10:08 +00:00
conn->t.sock.fd = -1; /* just to help with debugging */
conn->err_code = CO_ER_NONE;
conn->target = NULL;
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 14:11:45 +00:00
conn->proxy_netns = NULL;
MINOR: connection: add conn_init() to (re)initialize a connection This function will ease the initialization of new connections as well as their reuse. It initializes the obj_type and a few fields so that the connection is fresh again. It leaves the addresses and target untouched so it is suitable for use across connection retries.
2013-10-14 15:10:08 +00:00
}
MINOR: connection: add conn_new() / conn_free() conn_new() will be a more convenient way of allocating and initializing a connection. It calls pool_alloc2() and conn_init() upon success. conn_free() is just a pool_free2() but is provided for symmetry with conn_new().
2013-10-20 20:56:45 +00:00
/* Tries to allocate a new connection and initialized its main fields. The
* connection is returned on success, NULL on failure. The connection must
* be released using pool_free2() or conn_free().
*/
static inline struct connection *conn_new()
{
struct connection *conn;
conn = pool_alloc2(pool2_connection);
if (likely(conn != NULL))
conn_init(conn);
return conn;
}
/* Releases a connection previously allocated by conn_new() */
static inline void conn_free(struct connection *conn)
{
pool_free2(pool2_connection, conn);
}
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 19:11:38 +00:00
/* Retrieves the connection's source address */
static inline void conn_get_from_addr(struct connection *conn)
{
if (conn->flags & CO_FL_ADDR_FROM_SET)
return;
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (!conn_ctrl_ready(conn) || !conn->ctrl->get_src)
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 19:11:38 +00:00
return;
if (conn->ctrl->get_src(conn->t.sock.fd, (struct sockaddr *)&conn->addr.from,
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 23:42:33 +00:00
sizeof(conn->addr.from),
obj_type(conn->target) != OBJ_TYPE_LISTENER) == -1)
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 19:11:38 +00:00
return;
conn->flags |= CO_FL_ADDR_FROM_SET;
}
/* Retrieves the connection's original destination address */
static inline void conn_get_to_addr(struct connection *conn)
{
if (conn->flags & CO_FL_ADDR_TO_SET)
return;
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 12:50:42 +00:00
if (!conn_ctrl_ready(conn) || !conn->ctrl->get_dst)
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 19:11:38 +00:00
return;
if (conn->ctrl->get_dst(conn->t.sock.fd, (struct sockaddr *)&conn->addr.to,
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 23:42:33 +00:00
sizeof(conn->addr.to),
obj_type(conn->target) != OBJ_TYPE_LISTENER) == -1)
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 19:11:38 +00:00
return;
conn->flags |= CO_FL_ADDR_TO_SET;
}
MINOR: connection: replace conn_assign with conn_attach We don't want to assign the control nor transport layers anymore at the same time as the data layer, because it prevents one from keeping existing settings when reattaching a connection to an existing stream interface. Let's have conn_attach() replace conn_assign() for this purpose. Thus, conn_prepare() + conn_attach() do exactly the same as the previous conn_assign().
2013-10-24 13:31:04 +00:00
/* Attaches a connection to an owner and assigns a data layer */
static inline void conn_attach(struct connection *conn, void *owner, const struct data_cb *data)
CLEANUP: connection: offer conn_prepare() to set up a connection This will be used by checks as well as stream interfaces.
2012-09-24 15:15:42 +00: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 22:41:04 +00:00
conn->data = data;
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 20:14:33 +00:00
conn->owner = owner;
MINOR: connection: split conn_prepare() in two functions We'll also need a function to takeover an existing connection without reinitializing it. The same will be needed at the stream interface level.
2012-10-02 18:57:19 +00:00
}
MINOR: connection: add a new conn_drain() function Till now there was no way to know from a connection if a previous call to drain() had done any change. This function is used to drain incoming data and to update the connection's flags at the same time. It also correctly sets the polling flags on the connection if the drain function indicates inability to receive. This function will be used preferably over ctrl->drain() when a connection is used.
2014-01-20 10:41:52 +00:00
/* Drains possibly pending incoming data on the file descriptor attached to the
* connection and update the connection's flags accordingly. This is used to
* know whether we need to disable lingering on close. Returns non-zero if it
* is safe to close without disabling lingering, otherwise zero. The SOCK_RD_SH
* flag may also be updated if the incoming shutdown was reported by the drain()
* function.
*/
static inline int conn_drain(struct connection *conn)
{
if (!conn_ctrl_ready(conn))
return 1;
if (conn->flags & CO_FL_SOCK_RD_SH)
return 1;
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 18:46:33 +00:00
if (!fd_recv_ready(conn->t.sock.fd))
MINOR: connection: add a new conn_drain() function Till now there was no way to know from a connection if a previous call to drain() had done any change. This function is used to drain incoming data and to update the connection's flags at the same time. It also correctly sets the polling flags on the connection if the drain function indicates inability to receive. This function will be used preferably over ctrl->drain() when a connection is used.
2014-01-20 10:41:52 +00:00
return 0;
if (!conn->ctrl->drain)
return 0;
MEDIUM: connection: remove conn_{data,sock}_poll_{recv,send} We simply remove these functions and replace their calls with the appropriate ones : - if we're in the data phase, we can simply report wait on the FD - if we're in the socket phase, we may also have to signal the desire to read/write on the socket because it might not be active yet.
2014-01-22 19:02:06 +00:00
if (conn->ctrl->drain(conn->t.sock.fd) <= 0)
MINOR: connection: add a new conn_drain() function Till now there was no way to know from a connection if a previous call to drain() had done any change. This function is used to drain incoming data and to update the connection's flags at the same time. It also correctly sets the polling flags on the connection if the drain function indicates inability to receive. This function will be used preferably over ctrl->drain() when a connection is used.
2014-01-20 10:41:52 +00:00
return 0;
conn->flags |= CO_FL_SOCK_RD_SH;
return 1;
}
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 14:35:00 +00:00
/* returns a human-readable error code for conn->err_code, or NULL if the code
* is unknown.
*/
static inline const char *conn_err_code_str(struct connection *c)
{
switch (c->err_code) {
case CO_ER_NONE: return "Success";
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 15:06:50 +00:00
case CO_ER_CONF_FDLIM: return "Reached configured maxconn value";
case CO_ER_PROC_FDLIM: return "Too many sockets on the process";
case CO_ER_SYS_FDLIM: return "Too many sockets on the system";
case CO_ER_SYS_MEMLIM: return "Out of system buffers";
case CO_ER_NOPROTO: return "Protocol or address family not supported";
case CO_ER_SOCK_ERR: return "General socket error";
case CO_ER_PORT_RANGE: return "Source port range exhausted";
case CO_ER_CANT_BIND: return "Can't bind to source address";
case CO_ER_FREE_PORTS: return "Out of local source ports on the system";
case CO_ER_ADDR_INUSE: return "Local source 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 14:41:18 +00:00
case CO_ER_PRX_EMPTY: return "Connection closed while waiting for PROXY protocol header";
case CO_ER_PRX_ABORT: return "Connection error while waiting for 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 14:35:00 +00:00
case CO_ER_PRX_TIMEOUT: return "Timeout while waiting for PROXY protocol 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 14:41:18 +00:00
case CO_ER_PRX_TRUNCATED: return "Truncated PROXY protocol header received";
case CO_ER_PRX_NOT_HDR: return "Received something which does not look like a PROXY protocol header";
case CO_ER_PRX_BAD_HDR: return "Received an invalid PROXY protocol header";
case CO_ER_PRX_BAD_PROTO: return "Received an unhandled protocol in the PROXY protocol 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 15:32:10 +00:00
case CO_ER_SSL_EMPTY: return "Connection closed during SSL handshake";
case CO_ER_SSL_ABORT: return "Connection error 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 14:35:00 +00:00
case CO_ER_SSL_TIMEOUT: return "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 15:32:10 +00:00
case CO_ER_SSL_TOO_MANY: return "Too many SSL connections";
case CO_ER_SSL_NO_MEM: return "Out of memory when initializing an SSL connection";
case CO_ER_SSL_RENEG: return "Rejected a client-initiated SSL renegociation attempt";
case CO_ER_SSL_CA_FAIL: return "SSL client CA chain cannot be verified";
case CO_ER_SSL_CRT_FAIL: return "SSL client certificate not trusted";
case CO_ER_SSL_HANDSHAKE: return "SSL handshake failure";
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 16:54:29 +00:00
case CO_ER_SSL_HANDSHAKE_HB: return "SSL handshake failure after heartbeat";
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 18:02:39 +00:00
case CO_ER_SSL_KILLED_HB: return "Stopped a TLSv1 heartbeat attack (CVE-2014-0160)";
BUG/MINOR: connection: fix typo in error message report "unknownn" -> "unknown"
2013-12-01 19:29:58 +00:00
case CO_ER_SSL_NO_TARGET: return "Attempt to use SSL on an unknown target (internal error)";
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 14:35:00 +00:00
}
return NULL;
}
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
#endif /* _PROTO_CONNECTION_H */
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in New Issue Copy Permalink