RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-27 07:02:11 +00:00
Code Issues Packages Projects Releases Wiki Activity
94031d30d7
haproxy/include/proto/connection.h

1151 lines
37 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>
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
#include <common/ist.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: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 16:46:31 +00:00
#include <proto/task.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
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
extern struct pool_head *pool_head_connection;
extern struct pool_head *pool_head_connstream;
MINOR: connection: add a minimal transport layer registration system There are still a lot of #ifdef USE_OPENSSL in the code (still 43 occurences) because we never know if we can directly access ssl_sock or not. This patch attacks the problem differently by providing a way for transport layers to register themselves and for users to retrieve the pointer. Unregistered transport layers will point to NULL so it will be easy to check if SSL is registered or not. The mechanism is very inexpensive as it relies on a two-entries array of pointers, so the performance will not be affected.
2016-12-22 19:25:26 +00:00
extern struct xprt_ops *registered_xprt[XPRT_ENTRIES];
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
extern struct mux_proto_list mux_proto_list;
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
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
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 09:13:20 +00:00
* provided by the connection's sock_ops.
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
*/
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 09:13:20 +00:00
void conn_fd_handler(int fd);
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: 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: connections/mux: Add a new "subscribe" method. Add a new "subscribe" method for connection, conn_stream and mux, so that upper layer can subscribe to them, to be called when the event happens. Right now, the only event implemented is "SUB_CAN_SEND", where the upper layer can register to be called back when it is possible to send data. The connection and conn_stream got a new "send_wait_list" entry, which required to move a few struct members around to maintain an efficient cache alignment (and actually this slightly improved performance).
2018-07-17 16:46:31 +00:00
int conn_subscribe(struct connection *conn, int event_type, void *param);
MINOR: connections: Introduce an unsubscribe method. As we don't know how subscriptions are handled, we can't just assume we can use LIST_DEL() to unsubscribe, so introduce a new method to mux and connections to do so.
2018-09-28 15:57:58 +00:00
int conn_unsubscribe(struct connection *conn, int event_type, void *param);
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 14:11:10 +00:00
/* receive a NetScaler Client IP insertion header over a connection */
int conn_recv_netscaler_cip(struct connection *conn, int flag);
MINOR: connection: implement conn_sock_send() This function is an equivalent to send() which operates over a connection instead of a file descriptor. It checks that the control layer is ready and that it's allowed to send. If automatically enables polling if it cannot send. It simplifies the return checks by returning zero in all cases where it cannot send so that the caller only has to care about negative values indicating errors.
2015-03-12 22:56:52 +00:00
/* raw send() directly on the socket */
int conn_sock_send(struct connection *conn, const void *buf, int len, int flags);
REORG: connection: move conn_drain() to connection.c and rename it It's now called conn_sock_drain() to make it clear that it only reads at the sock layer and not at the data layer. The function was too big to remain inlined and it's used at a few places where size counts.
2015-03-12 23:40:28 +00:00
/* drains any pending bytes from the socket */
int conn_sock_drain(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
/* 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)) {
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
int fd = conn->handle.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
MINOR: fd: pass the iocb and owner to fd_insert() fd_insert() is currently called just after setting the owner and iocb, but proceeding like this prevents the operation from being atomic and requires a lock to protect the maxfd computation in another thread from meeting an incompletely initialized FD and computing a wrong maxfd. Fortunately for now all fdtab[].owner are set before calling fd_insert(), and the first lock in fd_insert() enforces a memory barrier so the code is safe. This patch moves the initialization of the owner and iocb to fd_insert() so that the function will be able to properly arrange its operations and remain safe even when modified to become lockless. There's no other change beyond the internal API.
2018-01-25 06:22:13 +00:00
fd_insert(fd, conn, conn_fd_handler, tid_bit);
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
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) {
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
fd_delete(conn->handle.fd);
MINOR: connection: ensure conn_ctrl_close() also resets the fd The connection's fd was reset to DEAD_FD_MAGIC on conn_force_close() but not on conn_full_close(), which is a bit strange. Let's do it on both.
2017-10-05 15:43:39 +00:00
conn->handle.fd = DEAD_FD_MAGIC;
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_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);
}
MINOR: connection: add conn_stop_tracking() to disable tracking This will be used before conn_full_close() instead of using conn_force_close(), resulting in a clearer exit path in various situations.
2017-10-05 16:09:20 +00:00
/* stop tracking a connection, allowing conn_full_close() to always
* succeed.
*/
static inline void conn_stop_tracking(struct connection *conn)
{
conn->flags &= ~CO_FL_XPRT_TRACKED;
}
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
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
* in CO_FL_WAIT_*, and the upper layer expectations indicated by CO_FL_XPRT_*.
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
* 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
*/
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
void conn_update_xprt_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.
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
* This should be called at the beginning of a connection handler. It does
* nothing if CO_FL_WILL_UPDATE is present, indicating that an upper caller
* has already done it.
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
*/
static inline void conn_refresh_polling_flags(struct connection *conn)
{
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
if (conn_ctrl_ready(conn) && !(conn->flags & CO_FL_WILL_UPDATE)) {
MINOR: connection: move the cleanup of flag CO_FL_WAIT_ROOM This flag is only used when reading using splicing for now, and is only set when a pipe full condition is met, so we can simplify its reset condition in conn_refresh_polling_flags so that it's cleared at the same time as the other ones, only when the control layer is ready. This flag could be used more, to mark that a buffer full condition was met with any receive method in order to simplify polling management. This should probably be revisited after 1.8.
2017-10-25 08:28:45 +00:00
unsigned int flags = conn->flags;
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
MINOR: connection: move the cleanup of flag CO_FL_WAIT_ROOM This flag is only used when reading using splicing for now, and is only set when a pipe full condition is met, so we can simplify its reset condition in conn_refresh_polling_flags so that it's cleared at the same time as the other ones, only when the control layer is ready. This flag could be used more, to mark that a buffer full condition was met with any receive method in order to simplify polling management. This should probably be revisited after 1.8.
2017-10-25 08:28:45 +00:00
flags &= ~(CO_FL_CURR_RD_ENA | CO_FL_CURR_WR_ENA | CO_FL_WAIT_ROOM);
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
if (fd_recv_active(conn->handle.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;
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
if (fd_send_active(conn->handle.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;
}
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
/* inspects c->flags and returns non-zero if XPRT 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
*/
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline unsigned int conn_xprt_polling_changes(const 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: 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;
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
f &= CO_FL_XPRT_WR_ENA | CO_FL_XPRT_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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
/* Automatically updates polling on connection <c> depending on the XPRT flags
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
* if no handshake is in progress. It does nothing if CO_FL_WILL_UPDATE is
* present, indicating that an upper caller is going to do it again later.
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
*/
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_cond_update_xprt_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
{
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
if (!(c->flags & CO_FL_WILL_UPDATE))
if (!(c->flags & CO_FL_POLL_SOCK) && conn_xprt_polling_changes(c))
conn_update_xprt_polling(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
}
/* Automatically updates polling on connection <c> depending on the SOCK flags
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
* if a handshake is in progress. It does nothing if CO_FL_WILL_UPDATE is
* present, indicating that an upper caller is going to do it again later.
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 void conn_cond_update_sock_polling(struct connection *c)
{
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
if (!(c->flags & CO_FL_WILL_UPDATE))
if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(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 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
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
* for example. It does not propage the change to the fd layer if
* CO_FL_WILL_UPDATE is present, indicating that an upper caller is going to do
* it later.
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
*/
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 |
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
CO_FL_XPRT_RD_ENA | CO_FL_XPRT_WR_ENA);
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
if (!(c->flags & CO_FL_WILL_UPDATE) && conn_ctrl_ready(c))
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
fd_stop_both(c->handle.fd);
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
/* Automatically update polling on connection <c> depending on the XPRT and
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
* 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.
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
* It does nothing if CO_FL_WILL_UPDATE is present, indicating that an upper
* caller is going to do it again later.
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 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);
MINOR: connection: add flag CO_FL_WILL_UPDATE to indicate when updates are granted In transport-layer functions (snd_buf/rcv_buf), it's very problematic never to know if polling changes made to the connection will be propagated or not. This has led to some conn_cond_update_polling() calls being placed at a few places to cover both the cases where the function is called from the upper layer and when it's called from the lower layer. With the arrival of the MUX, this becomes even more complicated, as the upper layer will not have to manipulate anything from the connection layer directly and will not have to push such updates directly either. But the snd_buf functions will need to see their updates committed when called from upper layers. The solution here is to introduce a connection flag set by the connection handler (and possibly any other similar place) indicating that the caller is committed to applying such changes on return. This way, the called functions will be able to apply such changes by themselves before leaving when the flag is not set, and the upper layer will not have to care about that anymore.
2017-10-25 07:22:43 +00:00
else if (!(c->flags & CO_FL_WILL_UPDATE)) {
if (!(c->flags & CO_FL_POLL_SOCK) && conn_xprt_polling_changes(c))
conn_update_xprt_polling(c);
else if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(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
}
/***** 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.
*/
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void __conn_xprt_want_recv(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags |= CO_FL_XPRT_RD_ENA;
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void __conn_xprt_stop_recv(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags &= ~CO_FL_XPRT_RD_ENA;
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
}
OPTIM: stream-int: don't disable polling anymore on DONT_READ Commit 5fddab0 ("OPTIM: stream_interface: disable reading when CF_READ_DONTWAIT is set") improved the connection layer's efficiency back in 1.5-dev13 by avoiding successive read attempts on an active FD. But by disabling this on a polled FD, it causes an unpleasant side effect which is that the FD that was subscribed to polling is suddenly stopped and may need to be re-enabled once the kernel starts to slow down on data eviction (eg: saturated server at the other end, bursty traffic caused by too large maxpollevents). This behaviour is observable with persistent connections when there is a large enough connection count so that there's no data in the early connection and polling is required, because there are then up to 4 epoll_ctl() calls per request. It's important that the server is slower than haproxy to cause some delays when reading response. The current connection layer as designed in 1.6 with the FD cache doesn't require this trick anymore, though it still benefits from it when it saves an FD from being uselessly polled. But compared to the increased cost of enabling and disabling poll all the time, it's still better to disable it. In some cases it's possible to observe a performance increase as high as 30% by avoiding this epoll_ctl() dance. In the end we only want to disable it when the FD is speculatively read and not when it's polled. For this we introduce a new function __conn_data_done_recv() which is used to indicate that we're done with recv() and not interested in new attempts. If/when we later support event-triggered epoll, this function will have to change a bit to do the same even in the polled case. A quick test with keep-alive requests run on a dual-core / dual- thread Atom shows a significant improvement : single process, 0 bytes : before: Requests per second: 12243.20 [#/sec] (mean) after: Requests per second: 13354.54 [#/sec] (mean) single process, 4k : before: Requests per second: 9639.81 [#/sec] (mean) after: Requests per second: 10991.89 [#/sec] (mean) dual process, 0 bytes (unstable) : before: Requests per second: 16900-19800 ~ 17600 [#/sec] (mean) after: Requests per second: 18600-21400 ~ 20500 [#/sec] (mean)
2016-11-29 20:47:02 +00:00
/* this one is used only to stop speculative recv(). It doesn't stop it if the
* fd is already polled in order to avoid expensive polling status changes.
* Since it might require the upper layer to re-enable reading, we'll return 1
* if we've really stopped something otherwise zero.
*/
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline int __conn_xprt_done_recv(struct connection *c)
OPTIM: stream-int: don't disable polling anymore on DONT_READ Commit 5fddab0 ("OPTIM: stream_interface: disable reading when CF_READ_DONTWAIT is set") improved the connection layer's efficiency back in 1.5-dev13 by avoiding successive read attempts on an active FD. But by disabling this on a polled FD, it causes an unpleasant side effect which is that the FD that was subscribed to polling is suddenly stopped and may need to be re-enabled once the kernel starts to slow down on data eviction (eg: saturated server at the other end, bursty traffic caused by too large maxpollevents). This behaviour is observable with persistent connections when there is a large enough connection count so that there's no data in the early connection and polling is required, because there are then up to 4 epoll_ctl() calls per request. It's important that the server is slower than haproxy to cause some delays when reading response. The current connection layer as designed in 1.6 with the FD cache doesn't require this trick anymore, though it still benefits from it when it saves an FD from being uselessly polled. But compared to the increased cost of enabling and disabling poll all the time, it's still better to disable it. In some cases it's possible to observe a performance increase as high as 30% by avoiding this epoll_ctl() dance. In the end we only want to disable it when the FD is speculatively read and not when it's polled. For this we introduce a new function __conn_data_done_recv() which is used to indicate that we're done with recv() and not interested in new attempts. If/when we later support event-triggered epoll, this function will have to change a bit to do the same even in the polled case. A quick test with keep-alive requests run on a dual-core / dual- thread Atom shows a significant improvement : single process, 0 bytes : before: Requests per second: 12243.20 [#/sec] (mean) after: Requests per second: 13354.54 [#/sec] (mean) single process, 4k : before: Requests per second: 9639.81 [#/sec] (mean) after: Requests per second: 10991.89 [#/sec] (mean) dual process, 0 bytes (unstable) : before: Requests per second: 16900-19800 ~ 17600 [#/sec] (mean) after: Requests per second: 18600-21400 ~ 20500 [#/sec] (mean)
2016-11-29 20:47:02 +00:00
{
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
if (!conn_ctrl_ready(c) || !fd_recv_polled(c->handle.fd)) {
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags &= ~CO_FL_XPRT_RD_ENA;
OPTIM: stream-int: don't disable polling anymore on DONT_READ Commit 5fddab0 ("OPTIM: stream_interface: disable reading when CF_READ_DONTWAIT is set") improved the connection layer's efficiency back in 1.5-dev13 by avoiding successive read attempts on an active FD. But by disabling this on a polled FD, it causes an unpleasant side effect which is that the FD that was subscribed to polling is suddenly stopped and may need to be re-enabled once the kernel starts to slow down on data eviction (eg: saturated server at the other end, bursty traffic caused by too large maxpollevents). This behaviour is observable with persistent connections when there is a large enough connection count so that there's no data in the early connection and polling is required, because there are then up to 4 epoll_ctl() calls per request. It's important that the server is slower than haproxy to cause some delays when reading response. The current connection layer as designed in 1.6 with the FD cache doesn't require this trick anymore, though it still benefits from it when it saves an FD from being uselessly polled. But compared to the increased cost of enabling and disabling poll all the time, it's still better to disable it. In some cases it's possible to observe a performance increase as high as 30% by avoiding this epoll_ctl() dance. In the end we only want to disable it when the FD is speculatively read and not when it's polled. For this we introduce a new function __conn_data_done_recv() which is used to indicate that we're done with recv() and not interested in new attempts. If/when we later support event-triggered epoll, this function will have to change a bit to do the same even in the polled case. A quick test with keep-alive requests run on a dual-core / dual- thread Atom shows a significant improvement : single process, 0 bytes : before: Requests per second: 12243.20 [#/sec] (mean) after: Requests per second: 13354.54 [#/sec] (mean) single process, 4k : before: Requests per second: 9639.81 [#/sec] (mean) after: Requests per second: 10991.89 [#/sec] (mean) dual process, 0 bytes (unstable) : before: Requests per second: 16900-19800 ~ 17600 [#/sec] (mean) after: Requests per second: 18600-21400 ~ 20500 [#/sec] (mean)
2016-11-29 20:47:02 +00:00
return 1;
}
return 0;
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void __conn_xprt_want_send(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags |= CO_FL_XPRT_WR_ENA;
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void __conn_xprt_stop_send(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags &= ~CO_FL_XPRT_WR_ENA;
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void __conn_xprt_stop_both(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
c->flags &= ~(CO_FL_XPRT_WR_ENA | CO_FL_XPRT_RD_ENA);
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_want_recv(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_want_recv(c);
conn_cond_update_xprt_polling(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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_stop_recv(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_stop_recv(c);
conn_cond_update_xprt_polling(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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_want_send(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_want_send(c);
conn_cond_update_xprt_polling(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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_stop_send(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_stop_send(c);
conn_cond_update_xprt_polling(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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_stop_both(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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_stop_both(c);
conn_cond_update_xprt_polling(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
}
/***** 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
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw() This one may be called by upper layers (eg: si_shutw()) or lower layers (si_shutw() as well during stream_int_notify()) so we want it to take care of updating the connection's flags if it's not going to be done by the caller.
2017-10-25 07:59:22 +00:00
/* read shutdown, called from the rcv_buf/rcv_pipe handlers when
* detecting an end of connection.
*/
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_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))
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
fdtab[c->handle.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
}
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw() This one may be called by upper layers (eg: si_shutw()) or lower layers (si_shutw() as well during stream_int_notify()) so we want it to take care of updating the connection's flags if it's not going to be done by the caller.
2017-10-25 07:59:22 +00:00
/* write shutdown, indication that the upper layer is not willing to send
BUG/MAJOR: connection: refine the situations where we don't send shutw() Since commit f9ce57e ("MEDIUM: connection: make conn_sock_shutw() aware of lingering"), we refrain from performing the shutw() on the socket if there is no lingering risk. But there is a problem with this in tunnel and in TCP modes where a client is explicitly allowed to send a shutw to the server, eventhough it it risky. Not doing it creates this situation reported by Ricardo Fraile and diagnosed by Christopher : a typical HTTP client (eg: curl) connecting via the config below to an HTTP server would receive its response, immediately close while the server remains in keep-alive mode. The shutr() received by haproxy from the client is "propagated" to the server side but not acted upon because fdtab[fd].linger_risk is set, so we expect that the next close will immediately complete this operation. listen proxy-tcp bind 127.0.0.1:8888 mode tcp timeout connect 5s timeout server 10s timeout client 10s server server1 127.0.0.1:8000 But since the whole stream will not end until the server closes in turn, the server doesn't close and haproxy expires on server timeout. This problem has already struck by waking up an older bug and was partially fixed with commit 8059351 ("BUG/MEDIUM: http: don't disable lingering on requests with tunnelled responses") though it was not enough. The problem is that linger_risk is not suited here. In fact we need to know whether or not it is desired to close normally or silently, and whether or not a shutr() has already been received on this connection. This is the approach this patch takes, and it solves the problem for the various difficult modes (tcp, http-server-close, pretend-keepalive). This fix needs to be backported to 1.8. Many thanks to Ricardo for providing very detailed traces and configurations.
2017-12-22 17:46:33 +00:00
* anything anymore and wants to close after pending data are sent. The
* <clean> argument will allow not to perform the socket layer shutdown if
* equal to 0.
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw() This one may be called by upper layers (eg: si_shutw()) or lower layers (si_shutw() as well during stream_int_notify()) so we want it to take care of updating the connection's flags if it's not going to be done by the caller.
2017-10-25 07:59:22 +00:00
*/
BUG/MAJOR: connection: refine the situations where we don't send shutw() Since commit f9ce57e ("MEDIUM: connection: make conn_sock_shutw() aware of lingering"), we refrain from performing the shutw() on the socket if there is no lingering risk. But there is a problem with this in tunnel and in TCP modes where a client is explicitly allowed to send a shutw to the server, eventhough it it risky. Not doing it creates this situation reported by Ricardo Fraile and diagnosed by Christopher : a typical HTTP client (eg: curl) connecting via the config below to an HTTP server would receive its response, immediately close while the server remains in keep-alive mode. The shutr() received by haproxy from the client is "propagated" to the server side but not acted upon because fdtab[fd].linger_risk is set, so we expect that the next close will immediately complete this operation. listen proxy-tcp bind 127.0.0.1:8888 mode tcp timeout connect 5s timeout server 10s timeout client 10s server server1 127.0.0.1:8000 But since the whole stream will not end until the server closes in turn, the server doesn't close and haproxy expires on server timeout. This problem has already struck by waking up an older bug and was partially fixed with commit 8059351 ("BUG/MEDIUM: http: don't disable lingering on requests with tunnelled responses") though it was not enough. The problem is that linger_risk is not suited here. In fact we need to know whether or not it is desired to close normally or silently, and whether or not a shutr() has already been received on this connection. This is the approach this patch takes, and it solves the problem for the various difficult modes (tcp, http-server-close, pretend-keepalive). This fix needs to be backported to 1.8. Many thanks to Ricardo for providing very detailed traces and configurations.
2017-12-22 17:46:33 +00:00
static inline void conn_sock_shutw(struct connection *c, int clean)
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
{
c->flags |= CO_FL_SOCK_WR_SH;
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw() This one may be called by upper layers (eg: si_shutw()) or lower layers (si_shutw() as well during stream_int_notify()) so we want it to take care of updating the connection's flags if it's not going to be done by the caller.
2017-10-25 07:59:22 +00:00
conn_refresh_polling_flags(c);
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
__conn_sock_stop_send(c);
MEDIUM: connection: make use of CO_FL_WILL_UPDATE in conn_sock_shutw() This one may be called by upper layers (eg: si_shutw()) or lower layers (si_shutw() as well during stream_int_notify()) so we want it to take care of updating the connection's flags if it's not going to be done by the caller.
2017-10-25 07:59:22 +00:00
conn_cond_update_sock_polling(c);
BUG/MAJOR: connection: refine the situations where we don't send shutw() Since commit f9ce57e ("MEDIUM: connection: make conn_sock_shutw() aware of lingering"), we refrain from performing the shutw() on the socket if there is no lingering risk. But there is a problem with this in tunnel and in TCP modes where a client is explicitly allowed to send a shutw to the server, eventhough it it risky. Not doing it creates this situation reported by Ricardo Fraile and diagnosed by Christopher : a typical HTTP client (eg: curl) connecting via the config below to an HTTP server would receive its response, immediately close while the server remains in keep-alive mode. The shutr() received by haproxy from the client is "propagated" to the server side but not acted upon because fdtab[fd].linger_risk is set, so we expect that the next close will immediately complete this operation. listen proxy-tcp bind 127.0.0.1:8888 mode tcp timeout connect 5s timeout server 10s timeout client 10s server server1 127.0.0.1:8000 But since the whole stream will not end until the server closes in turn, the server doesn't close and haproxy expires on server timeout. This problem has already struck by waking up an older bug and was partially fixed with commit 8059351 ("BUG/MEDIUM: http: don't disable lingering on requests with tunnelled responses") though it was not enough. The problem is that linger_risk is not suited here. In fact we need to know whether or not it is desired to close normally or silently, and whether or not a shutr() has already been received on this connection. This is the approach this patch takes, and it solves the problem for the various difficult modes (tcp, http-server-close, pretend-keepalive). This fix needs to be backported to 1.8. Many thanks to Ricardo for providing very detailed traces and configurations.
2017-12-22 17:46:33 +00:00
/* don't perform a clean shutdown if we're going to reset or
* if the shutr was already received.
*/
if (conn_ctrl_ready(c) && !(c->flags & CO_FL_SOCK_RD_SH) && clean)
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
shutdown(c->handle.fd, SHUT_WR);
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
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_shutw(struct connection *c)
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
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_stop_send(c);
MINOR: connection: perform the call to xprt->shutw() in conn_data_shutw() This will save callers from having to care about conn->xprt and xprt->shutw. Note that shutw() takes a second argument indicating whether it's a clean or a hard shutw. This is used by SSL which tries to close cleanly in most cases. Here we provide two versions, conn_data_shutw() which performs the clean close, and conn_data_shutw_hard() which does the unclean one.
2015-03-12 21:51:10 +00:00
/* clean data-layer shutdown */
if (c->xprt && c->xprt->shutw)
c->xprt->shutw(c, 1);
}
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline void conn_xprt_shutw_hard(struct connection *c)
MINOR: connection: perform the call to xprt->shutw() in conn_data_shutw() This will save callers from having to care about conn->xprt and xprt->shutw. Note that shutw() takes a second argument indicating whether it's a clean or a hard shutw. This is used by SSL which tries to close cleanly in most cases. Here we provide two versions, conn_data_shutw() which performs the clean close, and conn_data_shutw_hard() which does the unclean one.
2015-03-12 21:51:10 +00:00
{
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
__conn_xprt_stop_send(c);
MINOR: connection: perform the call to xprt->shutw() in conn_data_shutw() This will save callers from having to care about conn->xprt and xprt->shutw. Note that shutw() takes a second argument indicating whether it's a clean or a hard shutw. This is used by SSL which tries to close cleanly in most cases. Here we provide two versions, conn_data_shutw() which performs the clean close, and conn_data_shutw_hard() which does the unclean one.
2015-03-12 21:51:10 +00:00
/* unclean data-layer shutdown */
if (c->xprt && c->xprt->shutw)
c->xprt->shutw(c, 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
}
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 13:25:48 +00:00
/* shut read */
static inline void cs_shutr(struct conn_stream *cs, enum cs_shr_mode mode)
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
{
/* clean data-layer shutdown */
if (cs->conn->mux && cs->conn->mux->shutr)
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 13:25:48 +00:00
cs->conn->mux->shutr(cs, mode);
cs->flags |= (mode == CS_SHR_DRAIN) ? CS_FL_SHRD : CS_FL_SHRR;
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
}
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 13:25:48 +00:00
/* shut write */
static inline void cs_shutw(struct conn_stream *cs, enum cs_shw_mode mode)
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
{
/* clean data-layer shutdown */
if (cs->conn->mux && cs->conn->mux->shutw)
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 13:25:48 +00:00
cs->conn->mux->shutw(cs, mode);
cs->flags |= (mode == CS_SHW_NORMAL) ? CS_FL_SHWN : CS_FL_SHWS;
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
}
MINOR: connection: add cs_close() to close a conn_stream This basically calls cs_shutw() followed by cs_shutr(). Both of them are called in the most conservative mode so that any previous call is still respected. The CS flags are cleared so that it can be reused (this is important for connection retries when conn and CS are reused without being reallocated).
2017-10-05 16:19:43 +00:00
/* completely close a conn_stream (but do not detach it) */
static inline void cs_close(struct conn_stream *cs)
{
cs_shutw(cs, CS_SHW_SILENT);
cs_shutr(cs, CS_SHR_RESET);
cs->flags = CS_FL_NONE;
}
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
/* detect sock->data read0 transition */
REORG: connection: rename CO_FL_DATA_* -> CO_FL_XPRT_* These flags are not exactly for the data layer, they instead indicate what is expected from the transport layer. Since we're going to split the connection between the transport and the data layers to insert a mux layer, it's important to have a clear idea of what each layer does. All function conn_data_* used to manipulate these flags were renamed to conn_xprt_*.
2017-09-13 16:30:23 +00:00
static inline int conn_xprt_read0_pending(struct connection *c)
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
{
MEDIUM: connection: remove useless flag CO_FL_DATA_RD_SH This flag is both confusing and wrong. It is supposed to report the fact that the data layer has received a shutdown, but in fact this is reported by CO_FL_SOCK_RD_SH which is set by the transport layer after this condition is detected. The only case where the flag above is set is in the stream interface where CF_SHUTR is also set on the receiving channel. In addition, it was checked in the health checks code (while never set) and was always test jointly with CO_FL_SOCK_RD_SH everywhere, except in conn_data_read0_pending() which incorrectly doesn't match the second time it's called and is fortunately protected by an extra check on (ic->flags & CF_SHUTR). This patch gets rid of the flag completely. Now conn_data_read0_pending() accurately reports the fact that the transport layer has detected the end of the stream, regardless of the fact that this state was already consumed, and the stream interface watches ic->flags&CF_SHUTR to know if the channel was already closed by the upper layer (which it already used to do). The now unused conn_data_read0() function was removed.
2017-08-30 05:35:35 +00:00
return (c->flags & CO_FL_SOCK_RD_SH) != 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
}
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>.
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
* The transport's is initialized as well, and the mux and its context are
MINOR: connection: make the initialization more consistent Sometimes a connection is prepared before the target is set, sometimes after. There's no real rule since the few functions involved operate on different and independent fields. Soon we'll benefit from knowing the target at the connection layer, in order to figure the associated proxy and retrieve the various parameters (timeouts etc). This patch slightly reorders a few calls to conn_prepare() so that we can make sure that the target is always known to the mux.
2018-09-06 09:45:30 +00:00
* cleared. The target is not reinitialized and it is recommended that it is
* set prior to calling this function so that the function may make use of it
* in the future to refine the mux choice if needed.
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
*/
static inline void conn_prepare(struct connection *conn, const struct protocol *proto, const struct xprt_ops *xprt)
{
conn->ctrl = proto;
conn->xprt = xprt;
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
conn->mux = NULL;
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
conn->xprt_st = 0;
conn->xprt_ctx = NULL;
CLEANUP: connection: rename conn->mux_ctx to conn->ctx We most often store the mux context there but it can also be something else while setting up the connection. Better call it "ctx" and know that it's the owner's context than misleadingly call it mux_ctx and get caught doing suspicious tricks.
2018-12-19 13:12:10 +00:00
conn->ctx = NULL;
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
}
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
/*
* Initializes all required fields for a new conn_strema.
*/
static inline void cs_init(struct conn_stream *cs, struct connection *conn)
{
cs->obj_type = OBJ_TYPE_CS;
cs->flags = CS_FL_NONE;
cs->conn = conn;
}
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;
MEDIUM: ssl: Handle early data with OpenSSL 1.1.1 When compiled with Openssl >= 1.1.1, before attempting to do the handshake, try to read any early data. If any early data is present, then we'll create the session, read the data, and handle the request before we're doing the handshake. For this, we add a new connection flag, CO_FL_EARLY_SSL_HS, which is not part of the CO_FL_HANDSHAKE set, allowing to proceed with a session even before an SSL handshake is completed. As early data do have security implication, we let the origin server know the request comes from early data by adding the "Early-Data" header, as specified in this draft from the HTTP working group : https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-replay
2017-09-22 16:26:28 +00:00
conn->tmp_early_data = -1;
MINOR: ssl: Handle reading early data after writing better. It can happen that we want to read early data, write some, and then continue reading them. To do so, we can't reuse tmp_early_data to store the amount of data sent, so introduce a new member. If we read early data, then ssl_sock_to_buf() is now the only responsible for getting back to the handshake, to make sure we don't miss any early data.
2017-11-23 17:21:29 +00:00
conn->sent_early_data = 0;
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
conn->mux = NULL;
CLEANUP: connection: rename conn->mux_ctx to conn->ctx We most often store the mux context there but it can also be something else while setting up the connection. Better call it "ctx" and know that it's the owner's context than misleadingly call it mux_ctx and get caught doing suspicious tricks.
2018-12-19 13:12:10 +00:00
conn->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
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;
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
conn->handle.fd = DEAD_FD_MAGIC;
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->err_code = CO_ER_NONE;
conn->target = NULL;
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 13:46:01 +00:00
conn->xprt_done_cb = NULL;
MEDIUM: connection: add a destroy callback This callback will be used to release upper layers when a mux is in use. Given that the mux can be asynchronously deleted, we need a way to release the extra information such as the session. This callback will be called directly by the mux upon releasing everything and before the connection itself is released, so that the callee can find its information inside the connection if needed. The way it currently works is not perfect, and most likely this should instead become a mux release callback, but for now we have no easy way to add mux-specific stuff, and since there's one mux per connection, it works fine this way.
2017-10-08 09:16:46 +00:00
conn->destroy_cb = 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 a new list member in the connection struct This list member will be used to attach a connection to a list of idle, reusable or queued connections. It's unused for now. Given that it's not expected to be used more than a few times per session, the member was put after the target, in the area starting at the second cache line of the structure.
2015-08-04 15:25:58 +00:00
LIST_INIT(&conn->list);
MINOR: sessions: Start to store the outgoing connection in sessions. Introduce a new field in session, "srv_conn", and a linked list of sessions in the connection. It will be used later when we'll switch connections from being managed by the stream, to being managed by the session.
2018-11-13 15:44:31 +00:00
LIST_INIT(&conn->session_list);
MEDIUM: connections: Change struct wait_list to wait_event. When subscribing, we don't need to provide a list element, only the h2 mux needs it. So instead, Add a list element to struct h2s, and use it when a list is needed. This forces us to use the unsubscribe method, since we can't just unsubscribe by using LIST_DEL anymore. This patch is larger than it should be because it includes some renaming.
2018-10-10 16:25:41 +00:00
conn->send_wait = NULL;
conn->recv_wait = NULL;
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 17:30:32 +00:00
conn->idle_time = 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
}
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 13:46:01 +00:00
/* sets <owner> as the connection's owner */
MEDIUM: connection: add a destroy callback This callback will be used to release upper layers when a mux is in use. Given that the mux can be asynchronously deleted, we need a way to release the extra information such as the session. This callback will be called directly by the mux upon releasing everything and before the connection itself is released, so that the callee can find its information inside the connection if needed. The way it currently works is not perfect, and most likely this should instead become a mux release callback, but for now we have no easy way to add mux-specific stuff, and since there's one mux per connection, it works fine this way.
2017-10-08 09:16:46 +00:00
static inline void conn_set_owner(struct connection *conn, void *owner, void (*cb)(struct connection *))
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 13:46:01 +00:00
{
conn->owner = owner;
MEDIUM: connection: add a destroy callback This callback will be used to release upper layers when a mux is in use. Given that the mux can be asynchronously deleted, we need a way to release the extra information such as the session. This callback will be called directly by the mux upon releasing everything and before the connection itself is released, so that the callee can find its information inside the connection if needed. The way it currently works is not perfect, and most likely this should instead become a mux release callback, but for now we have no easy way to add mux-specific stuff, and since there's one mux per connection, it works fine this way.
2017-10-08 09:16:46 +00:00
conn->destroy_cb = cb;
MEDIUM: connection: get rid of data->init() which was not for data The ->init() callback of the connection's data layer was only used to complete the session's initialisation since sessions and streams were split apart in 1.6. The problem is that it creates a big confusion in the layers' roles as the session has to register a dummy data layer when waiting for a handshake to complete, then hand it off to the stream which will replace it. The real need is to notify that the transport has finished initializing. This should enable a better splitting between these layers. This patch thus introduces a connection-specific callback called xprt_done_cb() which informs about handshake successes or failures. With this, data->init() can disappear, CO_FL_INIT_DATA as well, and we don't need to register a dummy data->wake() callback to be notified of errors.
2017-08-28 13:46:01 +00:00
}
/* registers <cb> as a callback to notify for transport's readiness or failure */
static inline void conn_set_xprt_done_cb(struct connection *conn, int (*cb)(struct connection *))
{
conn->xprt_done_cb = cb;
}
/* unregisters the callback to notify for transport's readiness or failure */
static inline void conn_clear_xprt_done_cb(struct connection *conn)
{
conn->xprt_done_cb = NULL;
}
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
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
* be released using pool_free() or conn_free().
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
*/
static inline struct connection *conn_new()
{
struct connection *conn;
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
conn = pool_alloc(pool_head_connection);
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
if (likely(conn != NULL))
conn_init(conn);
return conn;
}
MINOR: conn_stream: add an rx buffer to the conn_stream In order to reorganize the connection layers, recv() operations will need to be retryable and to support partial transfers. This requires an intermediary buffer to hold the data coming from the mux. After a few attempts, it turns out that this buffer is best placed inside the conn_stream itself. For now it's only set to buf_empty and it will be up to the caller to allocate it if required.
2018-03-02 09:43:58 +00:00
/* Releases a conn_stream previously allocated by cs_new(), as well as any
* buffer it would still hold.
*/
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
static inline void cs_free(struct conn_stream *cs)
{
MINOR: conn_stream: add an rx buffer to the conn_stream In order to reorganize the connection layers, recv() operations will need to be retryable and to support partial transfers. This requires an intermediary buffer to hold the data coming from the mux. After a few attempts, it turns out that this buffer is best placed inside the conn_stream itself. For now it's only set to buf_empty and it will be up to the caller to allocate it if required.
2018-03-02 09:43:58 +00:00
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
pool_free(pool_head_connstream, cs);
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
}
/* Tries to allocate a new conn_stream and initialize its main fields. If
* <conn> is NULL, then a new connection is allocated on the fly, initialized,
* and assigned to cs->conn ; this connection will then have to be released
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
* using pool_free() or conn_free(). The conn_stream is initialized and added
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
* to the mux's stream list on success, then returned. On failure, nothing is
* allocated and NULL is returned.
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
*/
static inline struct conn_stream *cs_new(struct connection *conn)
{
struct conn_stream *cs;
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
cs = pool_alloc(pool_head_connstream);
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
if (!likely(cs))
return NULL;
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
if (!conn) {
conn = conn_new();
if (!likely(conn)) {
cs_free(cs);
return NULL;
}
conn_init(conn);
}
cs_init(cs, conn);
return cs;
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
}
MINOR: mux: implement a get_first_cs() method This method is used to retrieve the first known good conn_stream from the mux. It will be used to find the other end of a connection when dealing with the proxy protocol for example.
2018-11-18 20:29:20 +00:00
/* Retrieves any valid conn_stream from this connection, preferably the first
* valid one. The purpose is to be able to figure one other end of a private
* connection for purposes like source binding or proxy protocol header
* emission. In such cases, any conn_stream is expected to be valid so the
* mux is encouraged to return the first one it finds. If the connection has
* no mux or the mux has no get_first_cs() method or the mux has no valid
* conn_stream, NULL is returned. The output pointer is purposely marked
* const to discourage the caller from modifying anything there.
*/
static inline const struct conn_stream *cs_get_first(const struct connection *conn)
{
if (!conn || !conn->mux || !conn->mux->get_first_cs)
return NULL;
return conn->mux->get_first_cs(conn);
}
BUG/MEDIUM: connections: Remove subscription if going in idle mode. Make sure we don't have any subscription when the connection is going in idle mode, otherwise there's a race condition when the connection is reused, if there are still old subscriptions, new ones won't be done. No backport is needed.
2018-10-20 22:32:01 +00:00
static inline void conn_force_unsubscribe(struct connection *conn)
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
{
BUG/MEDIUM: connections: Remove subscription if going in idle mode. Make sure we don't have any subscription when the connection is going in idle mode, otherwise there's a race condition when the connection is reused, if there are still old subscriptions, new ones won't be done. No backport is needed.
2018-10-20 22:32:01 +00:00
if (conn->recv_wait) {
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 12:59:17 +00:00
conn->recv_wait->events &= ~SUB_RETRY_RECV;
BUG/MEDIUM: connections: Remove subscription if going in idle mode. Make sure we don't have any subscription when the connection is going in idle mode, otherwise there's a race condition when the connection is reused, if there are still old subscriptions, new ones won't be done. No backport is needed.
2018-10-20 22:32:01 +00:00
conn->recv_wait = NULL;
}
if (conn->send_wait) {
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 12:59:17 +00:00
conn->send_wait->events &= ~SUB_RETRY_SEND;
BUG/MEDIUM: connections: Remove subscription if going in idle mode. Make sure we don't have any subscription when the connection is going in idle mode, otherwise there's a race condition when the connection is reused, if there are still old subscriptions, new ones won't be done. No backport is needed.
2018-10-20 22:32:01 +00:00
conn->send_wait = NULL;
}
}
/* Releases a connection previously allocated by conn_new() */
static inline void conn_free(struct connection *conn)
{
MAJOR: sessions: Store multiple outgoing connections in the session. Instead of just storing the last connection in the session, store all of the connections, for at most MAX_SRV_LIST (currently 5) targets. That way we can do keepalive on more than 1 outgoing connection when the client uses HTTP/2.
2018-11-30 16:24:55 +00:00
/* Remove ourself from the session's connections list, if any. */
MEDIUM: sessions: Don't keep an infinite number of idling connections. In session, don't keep an infinite number of connection that can idle. Add a new frontend parameter, "max-session-srv-conns" to set a max number, with a default value of 5.
2018-12-14 18:27:06 +00:00
if (!LIST_ISEMPTY(&conn->session_list)) {
struct session *sess = conn->owner;
sess->resp_conns--;
LIST_DEL(&conn->session_list);
}
MINOR: connection: remove an unwelcome dependency on struct stream There was a reference to struct stream in conn_free() for the case where we're freeing a connection that doesn't have a mux attached. For now we know it's always a stream, and we only need to do it to put a NULL in s->si[1].end. Let's do it better by storing the pointer to si[1].end in the context and specifying that this pointer is always nulled if the mux is null. This way it allows a connection to detach itself from wherever it's being used. Maybe we could even get rid of the condition on the mux.
2018-12-19 13:36:29 +00:00
/* By convention we always place a NULL where the ctx points to if the
* mux is null. It may have been used to store the connection as a
* stream_interface's end point for example.
MAJOR: connections: Defer mux creation for outgoing connection if alpn is set. If an ALPN (or a NPN) was chosen for a server, defer choosing the mux until after the SSL handshake is done, and the ALPN/NPN has been negociated, so that we know which mux to pick.
2018-11-20 23:16:29 +00:00
*/
MINOR: connection: remove an unwelcome dependency on struct stream There was a reference to struct stream in conn_free() for the case where we're freeing a connection that doesn't have a mux attached. For now we know it's always a stream, and we only need to do it to put a NULL in s->si[1].end. Let's do it better by storing the pointer to si[1].end in the context and specifying that this pointer is always nulled if the mux is null. This way it allows a connection to detach itself from wherever it's being used. Maybe we could even get rid of the condition on the mux.
2018-12-19 13:36:29 +00:00
if (conn->ctx != NULL && conn->mux == NULL)
*(void **)conn->ctx = NULL;
MAJOR: connections: Defer mux creation for outgoing connection if alpn is set. If an ALPN (or a NPN) was chosen for a server, defer choosing the mux until after the SSL handshake is done, and the ALPN/NPN has been negociated, so that we know which mux to pick.
2018-11-20 23:16:29 +00:00
MEDIUM: servers: Add a command to limit the number of idling connections. Add a new command, "pool-max-conn" that sets the maximum number of connections waiting in the orphan idling connections list (as activated with idle-timeout). Using "-1" means unlimited. Using pools is now dependant on this.
2018-12-10 17:30:32 +00:00
/* The connection is currently in the server's idle list, so tell it
* there's one less connection available in that list.
*/
if (conn->idle_time > 0) {
struct server *srv = __objt_server(conn->target);
srv->curr_idle_conns--;
}
MAJOR: connections: Defer mux creation for outgoing connection if alpn is set. If an ALPN (or a NPN) was chosen for a server, defer choosing the mux until after the SSL handshake is done, and the ALPN/NPN has been negociated, so that we know which mux to pick.
2018-11-20 23:16:29 +00:00
BUG/MEDIUM: connections: Remove subscription if going in idle mode. Make sure we don't have any subscription when the connection is going in idle mode, otherwise there's a race condition when the connection is reused, if there are still old subscriptions, new ones won't be done. No backport is needed.
2018-10-20 22:32:01 +00:00
conn_force_unsubscribe(conn);
MAJOR: connections: Detach connections from streams. Do not destroy the connection when we're about to destroy a stream. This prevents us from doing keepalive on server connections when the client is using HTTP/2, as a new stream is created for each request. Instead, the session is now responsible for destroying connections. When reusing connections, the attach() mux method is now used to create a new conn_stream.
2018-11-13 15:48:36 +00:00
LIST_DEL(&conn->list);
LIST_INIT(&conn->list);
CLEANUP: pools: rename all pool functions and pointers to remove this "2" During the migration to the second version of the pools, the new functions and pool pointers were all called "pool_something2()" and "pool2_something". Now there's no more pool v1 code and it's a real pain to still have to deal with this. Let's clean this up now by removing the "2" everywhere, and by renaming the pool heads "pool_head_something".
2017-11-24 16:34:44 +00:00
pool_free(pool_head_connection, conn);
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
}
MAJOR: connections: Detach connections from streams. Do not destroy the connection when we're about to destroy a stream. This prevents us from doing keepalive on server connections when the client is using HTTP/2, as a new stream is created for each request. Instead, the session is now responsible for destroying connections. When reusing connections, the attach() mux method is now used to create a new conn_stream.
2018-11-13 15:48:36 +00:00
/* Release a conn_stream */
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
static inline void cs_destroy(struct conn_stream *cs)
{
BUG/MEDIUM: connection: Make sure we have a mux before calling detach(). In some cases, we call cs_destroy() very early, so early the connection doesn't yet have a mux, so we can't call mux->detach(). In this case, just destroy the associated connection. This should be backported to 1.8.
2018-04-13 13:50:27 +00:00
if (cs->conn->mux)
cs->conn->mux->detach(cs);
else {
/* It's too early to have a mux, let's just destroy
* the connection
*/
struct connection *conn = cs->conn;
conn_stop_tracking(conn);
conn_full_close(conn);
if (conn->destroy_cb)
conn->destroy_cb(conn);
conn_free(conn);
}
MINOR: connection: introduce the conn_stream manipulation functions Most of the functions dealing with conn_streams are here. They act at the data layer and interact with the mux. For now they are not used yet but everything builds.
2017-10-08 13:16:00 +00:00
cs_free(cs);
}
MINOR: connection: introduce conn_stream This patch introduces a new struct conn_stream. It's the stream-side of a multiplexed connection. A pool is created and destroyed on exit. For now the conn_streams are not used at all.
2017-09-13 16:30:23 +00:00
/* Returns the conn from a cs. If cs is NULL, returns NULL */
static inline struct connection *cs_conn(const struct conn_stream *cs)
{
return cs ? cs->conn : NULL;
}
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
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;
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
if (conn->ctrl->get_src(conn->handle.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;
REORG/MEDIUM: connection: introduce the notion of connection handle Till now connections used to rely exclusively on file descriptors. It was planned in the past that alternative solutions would be implemented, leading to member "union t" presenting sock.fd only for now. With QUIC, the connection will need to continue to exist but will not rely on a file descriptor but a connection ID. So this patch introduces a "connection handle" which is either a file descriptor or a connection ID, to replace the existing "union t". We've now removed the intermediate "struct sock" which was never used. There is no functional change at all, though the struct connection was inflated by 32 bits on 64-bit platforms due to alignment.
2017-08-24 12:31:19 +00:00
if (conn->ctrl->get_dst(conn->handle.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;
}
REORG: connection: centralize the conn_set_{tos,mark,quickack} functions There were a number of ugly setsockopt() calls spread all over proto_http.c, proto_htx.c and hlua.c just to manipulate the front connection's TOS, mark or TCP quick-ack. These ones entirely relied on the connection, its existence, its control layer's presence, and its addresses. Worse, inet_set_tos() was placed in proto_http.c, exported and used from the two other ones, surrounded in #ifdefs. This patch moves this code to connection.h and makes the other ones rely on it without ifdefs.
2018-12-11 15:37:42 +00:00
/* Sets the TOS header in IPv4 and the traffic class header in IPv6 packets
* (as per RFC3260 #4 and BCP37 #4.2 and #5.2). The connection is tested and if
* it is null, nothing is done.
*/
static inline void conn_set_tos(const struct connection *conn, int tos)
{
if (!conn || !conn_ctrl_ready(conn))
return;
#ifdef IP_TOS
if (conn->addr.from.ss_family == AF_INET)
setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
#endif
#ifdef IPV6_TCLASS
if (conn->addr.from.ss_family == AF_INET6) {
if (IN6_IS_ADDR_V4MAPPED(&((struct sockaddr_in6 *)&conn->addr.from)->sin6_addr))
/* v4-mapped addresses need IP_TOS */
setsockopt(conn->handle.fd, IPPROTO_IP, IP_TOS, &tos, sizeof(tos));
else
setsockopt(conn->handle.fd, IPPROTO_IPV6, IPV6_TCLASS, &tos, sizeof(tos));
}
#endif
}
/* Sets the netfilter mark on the connection's socket. The connection is tested
* and if it is null, nothing is done.
*/
static inline void conn_set_mark(const struct connection *conn, int mark)
{
if (!conn || !conn_ctrl_ready(conn))
return;
#ifdef SO_MARK
setsockopt(conn->handle.fd, SOL_SOCKET, SO_MARK, &mark, sizeof(mark));
#endif
}
/* Sets adjust the TCP quick-ack feature on the connection's socket. The
* connection is tested and if it is null, nothing is done.
*/
static inline void conn_set_quickack(const struct connection *conn, int value)
{
if (!conn || !conn_ctrl_ready(conn))
return;
#ifdef TCP_QUICKACK
setsockopt(conn->handle.fd, IPPROTO_TCP, TCP_QUICKACK, &value, sizeof(value));
#endif
}
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
/* Attaches a conn_stream to a data layer and sets the relevant callbacks */
static inline void cs_attach(struct conn_stream *cs, void *data, const struct data_cb *data_cb)
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
{
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
cs->data_cb = data_cb;
cs->data = data;
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
}
MEDIUM: connections: Change struct wait_list to wait_event. When subscribing, we don't need to provide a list element, only the h2 mux needs it. So instead, Add a list element to struct h2s, and use it when a list is needed. This forces us to use the unsubscribe method, since we can't just unsubscribe by using LIST_DEL anymore. This patch is larger than it should be because it includes some renaming.
2018-10-10 16:25:41 +00:00
static inline struct wait_event *wl_set_waitcb(struct wait_event *wl, struct task *(*cb)(struct task *, void *, unsigned short), void *ctx)
MINOR: connection: simplify subscription by adding a registration function This new function wl_set_waitcb() prepopulates a wait_list with a tasklet and a context and returns it so that it can be passed to ->subscribe() to be added to a connection or conn_stream's wait_list. The caller doesn't need to know all the insiders details anymore this way.
2018-07-18 06:18:20 +00:00
{
if (!wl->task->process) {
wl->task->process = cb;
wl->task->context = ctx;
}
return wl;
}
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
/* Installs the connection's mux layer for upper context <ctx>.
* Returns < 0 on error.
*/
MINOR: connection: pass the proxy when creating a connection Till now it was very difficult for a mux to know what proxy it was working for. Let's pass the proxy when the mux is instanciated at init() time. It's not yet used but the H1 mux will definitely need it, just like the H2 mux when dealing with backend connections.
2018-09-12 10:02:05 +00:00
static inline int conn_install_mux(struct connection *conn, const struct mux_ops *mux,
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 18:42:40 +00:00
void *ctx, struct proxy *prx, struct session *sess)
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
{
conn->mux = mux;
CLEANUP: connection: rename conn->mux_ctx to conn->ctx We most often store the mux context there but it can also be something else while setting up the connection. Better call it "ctx" and know that it's the owner's context than misleadingly call it mux_ctx and get caught doing suspicious tricks.
2018-12-19 13:12:10 +00:00
conn->ctx = ctx;
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 18:42:40 +00:00
return mux->init ? mux->init(conn, prx, sess) : 0;
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
}
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";
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 14:11:10 +00:00
case CO_ER_CIP_EMPTY: return "Connection closed while waiting for NetScaler Client IP header";
case CO_ER_CIP_ABORT: return "Connection error while waiting for NetScaler Client IP header";
case CO_ER_CIP_TRUNCATED: return "Truncated NetScaler Client IP header received";
case CO_ER_CIP_BAD_MAGIC: return "Received an invalid NetScaler Client IP magic number";
case CO_ER_CIP_BAD_PROTO: return "Received an unhandled protocol in the NetScaler Client IP header";
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 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";
MINOR: ssl: add a new error codes for wrong server certificates If a server presents an unexpected certificate to haproxy, that is, a certificate that doesn't match the expected name as configured in verifyhost or as requested using SNI, we want to store that precious information. Fortunately we have access to the connection in the verification callback so it's possible to store an error code there. For this purpose we use CO_ER_SSL_MISMATCH_SNI (for when the cert name didn't match the one requested using SNI) and CO_ER_SSL_MISMATCH for when it doesn't match verifyhost.
2017-07-26 18:09:56 +00:00
case CO_ER_SSL_MISMATCH: return "Server presented an SSL certificate different from the configured one";
case CO_ER_SSL_MISMATCH_SNI: return "Server presented an SSL certificate different from the expected one";
MEDIUM: connection: add error reporting for the SSL Get a bit more info in the logs when client-side SSL handshakes fail.
2012-12-03 15:32:10 +00:00
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 few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
static inline const char *conn_get_ctrl_name(const struct connection *conn)
{
if (!conn_ctrl_ready(conn))
return "NONE";
return conn->ctrl->name;
}
static inline const char *conn_get_xprt_name(const struct connection *conn)
{
if (!conn_xprt_ready(conn))
return "NONE";
MINOR: connection: add names for transport and data layers This makes debugging easier and avoids having to put ugly checks against certain well-known internal struct pointers.
2016-11-24 15:58:12 +00:00
return conn->xprt->name;
MINOR: connection: add a few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
}
MEDIUM: connection: start to introduce a mux layer between xprt and data For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.
2017-08-28 08:53:00 +00:00
static inline const char *conn_get_mux_name(const struct connection *conn)
{
if (!conn->mux)
return "NONE";
return conn->mux->name;
}
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
static inline const char *cs_get_data_name(const struct conn_stream *cs)
MINOR: connection: add a few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
{
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
if (!cs->data_cb)
MINOR: connection: add a few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
return "NONE";
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 16:30:23 +00:00
return cs->data_cb->name;
MINOR: connection: add a few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
}
MINOR: connection: add a minimal transport layer registration system There are still a lot of #ifdef USE_OPENSSL in the code (still 43 occurences) because we never know if we can directly access ssl_sock or not. This patch attacks the problem differently by providing a way for transport layers to register themselves and for users to retrieve the pointer. Unregistered transport layers will point to NULL so it will be easy to check if SSL is registered or not. The mechanism is very inexpensive as it relies on a two-entries array of pointers, so the performance will not be affected.
2016-12-22 19:25:26 +00:00
/* registers pointer to transport layer <id> (XPRT_*) */
static inline void xprt_register(int id, struct xprt_ops *xprt)
{
if (id >= XPRT_ENTRIES)
return;
registered_xprt[id] = xprt;
}
/* returns pointer to transport layer <id> (XPRT_*) or NULL if not registered */
static inline struct xprt_ops *xprt_get(int id)
{
if (id >= XPRT_ENTRIES)
return NULL;
return registered_xprt[id];
}
MINOR: connection: add a few functions to report the data and xprt layers' names These functions will be needed by "show sess" on the CLI, let's make them globally available. It's important to note that due to the fact that we still do not set the data and transport layers' names in the structures, we still have to rely on some exports just to match the pointers. This is ugly but is preferable to adding many includes since the short-term goal is to get rid of these tests by having proper names in place.
2016-11-23 17:00:08 +00:00
MINOR: connection: add a .get_alpn() method to xprt_ops This will be used to retrieve the ALPN negociated over SSL (or possibly via the proxy protocol later). It's likely that this information should be stored in the connection itself, but it requires adding an extra pointer and an extra integer. Thus better rely on the transport layer to pass this info for now.
2016-12-04 17:42:09 +00:00
static inline int conn_get_alpn(const struct connection *conn, const char **str, int *len)
{
if (!conn_xprt_ready(conn) || !conn->xprt->get_alpn)
return 0;
return conn->xprt->get_alpn(conn, str, len);
}
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
/* registers proto mux list <list>. Modifies the list element! */
static inline void register_mux_proto(struct mux_proto_list *list)
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
{
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
LIST_ADDQ(&mux_proto_list.list, &list->list);
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
}
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
/* unregisters proto mux list <list> */
static inline void unregister_mux_proto(struct mux_proto_list *list)
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
{
LIST_DEL(&list->list);
LIST_INIT(&list->list);
}
MINOR: mux: Change get_mux_proto to get an ist as parameter It simplifies the API and ease comparisons with the multiplexers token (which is an ist too).
2018-08-08 08:21:56 +00:00
static inline struct mux_proto_list *get_mux_proto(const struct ist proto)
MINOR: mux: Print the list of existing mux protocols during HA startup This is done in verbose/debug mode and when build options are reported.
2018-04-10 12:37:32 +00:00
{
struct mux_proto_list *item;
list_for_each_entry(item, &mux_proto_list.list, list) {
if (isteq(proto, item->token))
return item;
}
return NULL;
}
/* Lists the known proto mux on <out> */
static inline void list_mux_proto(FILE *out)
{
struct mux_proto_list *item;
struct ist proto;
char *mode, *side;
MINOR: mux: Improve the message with the list of existing mux protocols Because there can be several default multiplexers (without name), they are now reported with the name "<default>". And a message warns they cannot be referenced with the "proto" keyword on a bind line or a server line.
2018-08-08 08:25:57 +00:00
fprintf(out, "Available multiplexer protocols :\n"
BUG/MINOR: connection: report mux modes when HTX is supported It looks like we forgot to report HTX when listing the muxes and their respective protocols, leading to "NONE" being displayed. Let's report "HTX" and "HTTP|HTX" since both will exist. Also fix a minor typo in the output message.
2018-11-30 15:52:32 +00:00
"(protocols marked as <default> cannot be specified using 'proto' keyword)\n");
MINOR: mux: Print the list of existing mux protocols during HA startup This is done in verbose/debug mode and when build options are reported.
2018-04-10 12:37:32 +00:00
list_for_each_entry(item, &mux_proto_list.list, list) {
proto = item->token;
if (item->mode == PROTO_MODE_ANY)
mode = "TCP|HTTP";
else if (item->mode == PROTO_MODE_TCP)
mode = "TCP";
else if (item->mode == PROTO_MODE_HTTP)
mode = "HTTP";
BUG/MINOR: connection: report mux modes when HTX is supported It looks like we forgot to report HTX when listing the muxes and their respective protocols, leading to "NONE" being displayed. Let's report "HTX" and "HTTP|HTX" since both will exist. Also fix a minor typo in the output message.
2018-11-30 15:52:32 +00:00
else if (item->mode == PROTO_MODE_HTX)
mode = "HTX";
else if (item->mode == (PROTO_MODE_HTTP | PROTO_MODE_HTX))
mode = "HTTP|HTX";
MINOR: mux: Print the list of existing mux protocols during HA startup This is done in verbose/debug mode and when build options are reported.
2018-04-10 12:37:32 +00:00
else
mode = "NONE";
if (item->side == PROTO_SIDE_BOTH)
side = "FE|BE";
else if (item->side == PROTO_SIDE_FE)
side = "FE";
else if (item->side == PROTO_SIDE_BE)
side = "BE";
else
side = "NONE";
fprintf(out, " %15s : mode=%-10s side=%s\n",
MINOR: mux: Improve the message with the list of existing mux protocols Because there can be several default multiplexers (without name), they are now reported with the name "<default>". And a message warns they cannot be referenced with the "proto" keyword on a bind line or a server line.
2018-08-08 08:25:57 +00:00
(proto.len ? proto.ptr : "<default>"), mode, side);
MINOR: mux: Print the list of existing mux protocols during HA startup This is done in verbose/debug mode and when build options are reported.
2018-04-10 12:37:32 +00:00
}
}
MINOR: connection: create conn_get_best_mux_entry() We currently have conn_get_best_mux() to return the best mux for a given protocol name, side and proxy mode. But we need the mux entry as well in order to fix the bind_conf and servers at the end of the config parsing. Let's split the function in two parts. It's worth noting that the <conn> argument is never used anymore so this part is eligible to some cleanup.
2018-12-02 12:04:43 +00:00
/* returns the first mux entry in the list matching the exact same <mux_proto>
* and compatible with the <proto_side> (FE or BE) and the <proto_mode> (TCP or
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
* HTTP). <mux_proto> can be empty. Will fall back to the first compatible mux
* with exactly the same <proto_mode> or with an empty name. May return
* null if the code improperly registered the default mux to use as a fallback.
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
*/
MINOR: connection: create conn_get_best_mux_entry() We currently have conn_get_best_mux() to return the best mux for a given protocol name, side and proxy mode. But we need the mux entry as well in order to fix the bind_conf and servers at the end of the config parsing. Let's split the function in two parts. It's worth noting that the <conn> argument is never used anymore so this part is eligible to some cleanup.
2018-12-02 12:04:43 +00:00
static inline const struct mux_proto_list *conn_get_best_mux_entry(
const struct ist mux_proto,
int proto_side, int proto_mode)
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
{
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
struct mux_proto_list *item;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
struct mux_proto_list *fallback = NULL;
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
MINOR: mux: Unlink ALPN and multiplexers to rather speak of mux protocols Multiplexers are not necessarily associated to an ALPN. ALPN is a TLS extension, so it is not always defined or used. Instead, we now rather speak of multiplexer's protocols. So in this patch, there are no significative changes, some structures and functions are just renamed.
2018-04-10 12:33:41 +00:00
list_for_each_entry(item, &mux_proto_list.list, list) {
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
if (!(item->side & proto_side) || !(item->mode & proto_mode))
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
continue;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
if (istlen(mux_proto) && isteq(mux_proto, item->token))
MINOR: connection: create conn_get_best_mux_entry() We currently have conn_get_best_mux() to return the best mux for a given protocol name, side and proxy mode. But we need the mux entry as well in order to fix the bind_conf and servers at the end of the config parsing. Let's split the function in two parts. It's worth noting that the <conn> argument is never used anymore so this part is eligible to some cleanup.
2018-12-02 12:04:43 +00:00
return item;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
else if (!istlen(item->token)) {
if (!fallback || (item->mode == proto_mode && fallback->mode != proto_mode))
fallback = item;
}
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
}
MINOR: connection: create conn_get_best_mux_entry() We currently have conn_get_best_mux() to return the best mux for a given protocol name, side and proxy mode. But we need the mux entry as well in order to fix the bind_conf and servers at the end of the config parsing. Let's split the function in two parts. It's worth noting that the <conn> argument is never used anymore so this part is eligible to some cleanup.
2018-12-02 12:04:43 +00:00
return fallback;
}
/* returns the first mux in the list matching the exact same <mux_proto> and
* compatible with the <proto_side> (FE or BE) and the <proto_mode> (TCP or
* HTTP). <mux_proto> can be empty. Will fall back to the first compatible mux
* with exactly the same <proto_mode> or with an empty name. May return
* null if the code improperly registered the default mux to use as a fallback.
*/
static inline const struct mux_ops *conn_get_best_mux(struct connection *conn,
const struct ist mux_proto,
int proto_side, int proto_mode)
{
const struct mux_proto_list *item;
item = conn_get_best_mux_entry(mux_proto, proto_side, proto_mode);
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
MINOR: connection: create conn_get_best_mux_entry() We currently have conn_get_best_mux() to return the best mux for a given protocol name, side and proxy mode. But we need the mux entry as well in order to fix the bind_conf and servers at the end of the config parsing. Let's split the function in two parts. It's worth noting that the <conn> argument is never used anymore so this part is eligible to some cleanup.
2018-12-02 12:04:43 +00:00
return item ? item->mux : NULL;
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
}
MINOR: connection: add new function conn_is_back() This function returns true if the connection is a backend connection and false if it's a frontend connection.
2018-09-06 12:52:21 +00:00
/* returns 0 if the connection is valid and is a frontend connection, otherwise
* returns 1 indicating it's a backend connection. And uninitialized connection
* also returns 1 to better handle the usage in the middle of initialization.
*/
static inline int conn_is_back(const struct connection *conn)
{
return !objt_listener(conn->target);
}
MINOR: connection: add new function conn_get_proxy() This function returns the proxy associated to a connection. For front connections it returns the frontend, and for back connections it returns the backend. This will be used to retrieve some configuration parameters from within a mux.
2018-09-06 09:48:44 +00:00
/* returns a pointer to the proxy associated with this connection. For a front
* connection it returns a pointer to the frontend ; for a back connection, it
* returns a pointer to the backend.
*/
static inline struct proxy *conn_get_proxy(const struct connection *conn)
{
struct listener *l;
struct server *s;
/* check if it's a frontend connection */
l = objt_listener(conn->target);
if (l)
return l->bind_conf->frontend;
/* check if it's a backend connection */
s = objt_server(conn->target);
if (s)
return s->proxy;
return objt_proxy(conn->target);
}
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
/* installs the best mux for incoming connection <conn> using the upper context
* <ctx>. If the mux protocol is forced, we use it to find the best
* mux. Otherwise we use the ALPN name, if any. Returns < 0 on error.
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
*/
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
static inline int conn_install_mux_fe(struct connection *conn, void *ctx)
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
{
BUILD: connection: silence a couple of null-deref build warnings at -Wextra These ones don't need to be checked either.
2018-09-20 09:26:52 +00:00
struct bind_conf *bind_conf = __objt_listener(conn->target)->bind_conf;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
const struct mux_ops *mux_ops;
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
if (bind_conf->mux_proto)
mux_ops = bind_conf->mux_proto->mux;
else {
struct ist mux_proto;
const char *alpn_str = NULL;
int alpn_len = 0;
MINOR: proxy: add a new option "http-use-htx" This option makes a proxy use only HTX-compatible muxes instead of the HTTP-compatible ones for HTTP modes. It must be set on both ends, this is checked at parsing time.
2018-10-22 09:49:15 +00:00
int mode;
if (bind_conf->frontend->mode == PR_MODE_TCP)
mode = PROTO_MODE_TCP;
else if (bind_conf->frontend->options2 & PR_O2_USE_HTX)
mode = PROTO_MODE_HTX;
else
mode = PROTO_MODE_HTTP;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
conn_get_alpn(conn, &alpn_str, &alpn_len);
mux_proto = ist2(alpn_str, alpn_len);
mux_ops = conn_get_best_mux(conn, mux_proto, PROTO_SIDE_FE, mode);
if (!mux_ops)
return -1;
}
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 18:42:40 +00:00
return conn_install_mux(conn, mux_ops, ctx, bind_conf->frontend, conn->owner);
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
}
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
/* installs the best mux for outgoing connection <conn> using the upper context
* <ctx>. If the mux protocol is forced, we use it to find the best mux. Returns
MEDIUM: session: use the ALPN token and proxy mode to select the mux When an incoming connection is made on an HTTP mode frontend, the session now looks up the mux to use based on the ALPN token and the proxy mode. This will allow easier mux registration, and we don't need to hard-code the mux_pt_ops anymore.
2017-09-15 04:59:55 +00:00
* < 0 on error.
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
*/
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 18:42:40 +00:00
static inline int conn_install_mux_be(struct connection *conn, void *ctx, struct session *sess)
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
{
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
struct server *srv = objt_server(conn->target);
BUG/MEDIUM: connection/mux: take care of serverless proxies Commit 7ce0c89 ("MEDIUM: mux: Use the mux protocol specified on bind/server lines") assumed a bit too strongly that we could only have servers on the connect side :-) It segfaults under this config : defaults contimeout 5s clitimeout 5s srvtimeout 5s mode http listen test1 bind :8001 dispatch 127.0.0.1:8002 frontend test2 mode http bind :8002 redirect location / No backport needed.
2018-08-08 16:40:44 +00:00
struct proxy *prx = objt_proxy(conn->target);
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
const struct mux_ops *mux_ops;
BUG/MEDIUM: connection/mux: take care of serverless proxies Commit 7ce0c89 ("MEDIUM: mux: Use the mux protocol specified on bind/server lines") assumed a bit too strongly that we could only have servers on the connect side :-) It segfaults under this config : defaults contimeout 5s clitimeout 5s srvtimeout 5s mode http listen test1 bind :8001 dispatch 127.0.0.1:8002 frontend test2 mode http bind :8002 redirect location / No backport needed.
2018-08-08 16:40:44 +00:00
if (srv)
prx = srv->proxy;
if (!prx) // target must be either proxy or server
return -1;
if (srv && srv->mux_proto)
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
mux_ops = srv->mux_proto->mux;
else {
MAJOR: connections: Defer mux creation for outgoing connection if alpn is set. If an ALPN (or a NPN) was chosen for a server, defer choosing the mux until after the SSL handshake is done, and the ALPN/NPN has been negociated, so that we know which mux to pick.
2018-11-20 23:16:29 +00:00
struct ist mux_proto;
const char *alpn_str = NULL;
int alpn_len = 0;
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
int mode;
MINOR: proxy: add a new option "http-use-htx" This option makes a proxy use only HTX-compatible muxes instead of the HTTP-compatible ones for HTTP modes. It must be set on both ends, this is checked at parsing time.
2018-10-22 09:49:15 +00:00
if (prx->mode == PR_MODE_TCP)
mode = PROTO_MODE_TCP;
else if (prx->options2 & PR_O2_USE_HTX)
mode = PROTO_MODE_HTX;
else
mode = PROTO_MODE_HTTP;
MAJOR: connections: Defer mux creation for outgoing connection if alpn is set. If an ALPN (or a NPN) was chosen for a server, defer choosing the mux until after the SSL handshake is done, and the ALPN/NPN has been negociated, so that we know which mux to pick.
2018-11-20 23:16:29 +00:00
conn_get_alpn(conn, &alpn_str, &alpn_len);
mux_proto = ist2(alpn_str, alpn_len);
mux_ops = conn_get_best_mux(conn, mux_proto, PROTO_SIDE_BE, mode);
MEDIUM: mux: Use the mux protocol specified on bind/server lines To do so, mux choices are split to handle incoming and outgoing connections in a different way. The protocol specified on the bind/server line is used in priority. Then, for frontend connections, the ALPN is retrieved and used to choose the best mux. For backend connection, there is no ALPN. Finaly, if no protocol is specified and no protocol matches the ALPN, we fall back on a default mux, choosing in priority the first mux with exactly the same mode.
2018-04-10 13:01:45 +00:00
if (!mux_ops)
return -1;
}
MEDIUM: mux: provide the session to the init() and attach() method. Instead of trying to get the session from the connection, which is not always there, and of course there could be multiple sessions per connection, provide it with the init() and attach() methods, so that we know the session for each outgoing stream.
2018-12-14 18:42:40 +00:00
return conn_install_mux(conn, mux_ops, ctx, prx, sess);
MINOR: connection: implement alpn registration of muxes Selecting a mux based on ALPN and the proxy mode will quickly become a pain. This commit provides new functions to register/lookup a mux based on the ALPN string and the proxy mode to make this easier. Given that we're not supposed to support a wide range of muxes, the lookup should not have any measurable performance impact.
2017-09-21 17:40:52 +00:00
}
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