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
bd99aab91f
haproxy/include/proto/connection.h

446 lines
12 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>
#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>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
/* I/O callback for fd-based connections. It calls the read/write handlers
MAJOR: make use of conn_{data|sock}_{poll|stop|want}* in connection handlers This is a second attempt at getting rid of FD_WAIT_*. Now the situation is much better since native I/O handlers can directly manipulate the FD using fd_{poll|want|stop}_* and the connection handlers manipulate connection-level flags using the conn_{data|sock}_* equivalent. Proceeding this way ensures that the connection flags always reflect the reality even after data<->handshake switches.
2012-08-09 12:45:22 +00:00
* provided by the connection's sock_ops. Returns 0.
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 12:13:49 +00:00
*/
int conn_fd_handler(int fd);
MAJOR: connection: make the PROXY decoder a handshake handler The PROXY protocol is now decoded in the connection before other handshakes. This means that it may be extracted from a TCP stream before SSL is decoded from this stream.
2012-08-31 15:43:29 +00:00
/* receive a PROXY protocol header over a connection */
int conn_recv_proxy(struct connection *conn, int flag);
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
/* calls the init() function of the transport layer if any.
* 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
{
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
if (conn->xprt && conn->xprt->init)
return conn->xprt->init(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
return 0;
}
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
/* Calls the close() function of the transport layer if any */
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
{
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
if (conn->xprt && conn->xprt->close)
conn->xprt->close(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: 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
* operation.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
*/
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 15:26:16 +00:00
void conn_update_sock_polling(struct connection *c);
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 15:26:16 +00:00
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the data layer expectations indicated by CO_FL_DATA_*.
* The connection flags are updated with the new flags at the end of the
* operation.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
*/
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 15:26:16 +00:00
void conn_update_data_polling(struct connection *c);
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 15:26:16 +00:00
/* inspects c->flags and returns non-zero if DATA ENA changes from the CURR ENA
* or if the WAIT flags set new flags that were not in CURR POL.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
*/
static inline unsigned int conn_data_polling_changes(const struct connection *c)
{
MAJOR: connection: 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
return (((c->flags << 6) ^ (c->flags << 2)) | /* changes in ENA go to bits 30&31 */
(((c->flags << 8) & ~c->flags))) & /* new bits in POL go to bits 30&31 */
0xC0000000;
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
* or if the WAIT flags set new flags that were not in CURR POL.
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: 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
return (((c->flags << 4) ^ (c->flags << 2)) | /* changes in ENA go to bits 30&31 */
(((c->flags << 8) & ~c->flags))) & /* new bits in POL go to bits 30&31 */
0xC0000000;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 09:55:04 +00:00
}
/* Automatically updates polling on connection <c> depending on the DATA flags
* if no handshake is in progress.
*/
static inline void conn_cond_update_data_polling(struct connection *c)
{
if (!(c->flags & CO_FL_POLL_SOCK) && conn_data_polling_changes(c))
conn_update_data_polling(c);
}
/* Automatically updates polling on connection <c> depending on the SOCK flags
* if a handshake is in progress.
*/
static inline void conn_cond_update_sock_polling(struct connection *c)
{
if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(c);
}
/* Automatically update polling on connection <c> depending on the DATA and
* SOCK flags, and on whether a handshake is in progress or not. This may be
* called at any moment when there is a doubt about the effectiveness of the
* polling state, for instance when entering or leaving the handshake state.
*/
static inline void conn_cond_update_polling(struct connection *c)
{
if (!(c->flags & CO_FL_POLL_SOCK) && conn_data_polling_changes(c))
conn_update_data_polling(c);
else if ((c->flags & CO_FL_POLL_SOCK) && conn_sock_polling_changes(c))
conn_update_sock_polling(c);
}
/***** Event manipulation primitives for use by DATA I/O callbacks *****/
/* The __conn_* versions do not propagate to lower layers and are only meant
* to be used by handlers called by the connection handler. The other ones
* may be used anywhere.
*/
static inline void __conn_data_want_recv(struct connection *c)
{
c->flags |= CO_FL_DATA_RD_ENA;
}
static inline void __conn_data_stop_recv(struct connection *c)
{
c->flags &= ~CO_FL_DATA_RD_ENA;
}
static inline void __conn_data_poll_recv(struct connection *c)
{
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
c->flags |= CO_FL_WAIT_RD | CO_FL_DATA_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
}
static inline void __conn_data_want_send(struct connection *c)
{
c->flags |= CO_FL_DATA_WR_ENA;
}
static inline void __conn_data_stop_send(struct connection *c)
{
c->flags &= ~CO_FL_DATA_WR_ENA;
}
static inline void __conn_data_poll_send(struct connection *c)
{
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
c->flags |= CO_FL_WAIT_WR | CO_FL_DATA_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
}
static inline void __conn_data_stop_both(struct connection *c)
{
c->flags &= ~(CO_FL_DATA_WR_ENA | CO_FL_DATA_RD_ENA);
}
static inline void conn_data_want_recv(struct connection *c)
{
__conn_data_want_recv(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_recv(struct connection *c)
{
__conn_data_stop_recv(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_poll_recv(struct connection *c)
{
__conn_data_poll_recv(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_want_send(struct connection *c)
{
__conn_data_want_send(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_send(struct connection *c)
{
__conn_data_stop_send(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_poll_send(struct connection *c)
{
__conn_data_poll_send(c);
conn_cond_update_data_polling(c);
}
static inline void conn_data_stop_both(struct connection *c)
{
__conn_data_stop_both(c);
conn_cond_update_data_polling(c);
}
/***** Event manipulation primitives for use by handshake I/O callbacks *****/
/* The __conn_* versions do not propagate to lower layers and are only meant
* to be used by handlers called by the connection handler. The other ones
* may be used anywhere.
*/
static inline void __conn_sock_want_recv(struct connection *c)
{
c->flags |= CO_FL_SOCK_RD_ENA;
}
static inline void __conn_sock_stop_recv(struct connection *c)
{
c->flags &= ~CO_FL_SOCK_RD_ENA;
}
static inline void __conn_sock_poll_recv(struct connection *c)
{
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
c->flags |= CO_FL_WAIT_RD | CO_FL_SOCK_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
}
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_poll_send(struct connection *c)
{
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
c->flags |= CO_FL_WAIT_WR | CO_FL_SOCK_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
}
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_poll_recv(struct connection *c)
{
__conn_sock_poll_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_poll_send(struct connection *c)
{
__conn_sock_poll_send(c);
conn_cond_update_sock_polling(c);
}
static inline void conn_sock_stop_both(struct connection *c)
{
__conn_sock_stop_both(c);
conn_cond_update_sock_polling(c);
}
REORG: connection: replace si_data_close() with conn_data_close() This close function only applies to connection-specific parts and the stream-interface entry may soon disappear. Move this to the connection instead.
2012-08-06 13:06:49 +00:00
MINOR: connection: provide conn_{data|sock}_{read0|shutw} functions These functions are used to report unidirectional shutdown and to disable polling in the related direction.
2012-08-20 14:55:48 +00:00
/* shutdown management */
static inline void conn_sock_read0(struct connection *c)
{
c->flags |= CO_FL_SOCK_RD_SH;
__conn_sock_stop_recv(c);
}
static inline void conn_data_read0(struct connection *c)
{
c->flags |= CO_FL_DATA_RD_SH;
__conn_data_stop_recv(c);
}
static inline void conn_sock_shutw(struct connection *c)
{
c->flags |= CO_FL_SOCK_WR_SH;
__conn_sock_stop_send(c);
}
static inline void conn_data_shutw(struct connection *c)
{
c->flags |= CO_FL_DATA_WR_SH;
__conn_data_stop_send(c);
}
/* detect sock->data read0 transition */
static inline int conn_data_read0_pending(struct connection *c)
{
return (c->flags & (CO_FL_DATA_RD_SH | CO_FL_SOCK_RD_SH)) == CO_FL_SOCK_RD_SH;
}
/* detect data->sock shutw transition */
static inline int conn_sock_shutw_pending(struct connection *c)
{
return (c->flags & (CO_FL_DATA_WR_SH | CO_FL_SOCK_WR_SH)) == CO_FL_DATA_WR_SH;
}
REORG: connection: move the target pointer from si to connection The target is per connection and is directly used by the connection, so we need it there. It's not needed anymore in the SI however.
2012-08-30 13:49:18 +00:00
static inline void clear_target(struct target *dest)
{
dest->type = TARG_TYPE_NONE;
dest->ptr.v = NULL;
}
static inline void set_target_client(struct target *dest, struct listener *l)
{
dest->type = TARG_TYPE_CLIENT;
dest->ptr.l = l;
}
static inline void set_target_server(struct target *dest, struct server *s)
{
dest->type = TARG_TYPE_SERVER;
dest->ptr.s = s;
}
static inline void set_target_proxy(struct target *dest, struct proxy *p)
{
dest->type = TARG_TYPE_PROXY;
dest->ptr.p = p;
}
static inline void set_target_applet(struct target *dest, struct si_applet *a)
{
dest->type = TARG_TYPE_APPLET;
dest->ptr.a = a;
}
static inline void set_target_task(struct target *dest, struct task *t)
{
dest->type = TARG_TYPE_TASK;
dest->ptr.t = t;
}
static inline struct target *copy_target(struct target *dest, struct target *src)
{
*dest = *src;
return dest;
}
static inline int target_match(struct target *a, struct target *b)
{
return a->type == b->type && a->ptr.v == b->ptr.v;
}
static inline struct server *target_srv(struct target *t)
{
if (!t || t->type != TARG_TYPE_SERVER)
return NULL;
return t->ptr.s;
}
static inline struct listener *target_client(struct target *t)
{
if (!t || t->type != TARG_TYPE_CLIENT)
return NULL;
return t->ptr.l;
}
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;
if (!conn->ctrl || !conn->ctrl->get_src)
return;
if (conn->ctrl->get_src(conn->t.sock.fd, (struct sockaddr *)&conn->addr.from,
sizeof(conn->addr.from),
conn->target.type != TARG_TYPE_CLIENT) == -1)
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;
if (!conn->ctrl || !conn->ctrl->get_dst)
return;
if (conn->ctrl->get_dst(conn->t.sock.fd, (struct sockaddr *)&conn->addr.to,
sizeof(conn->addr.to),
conn->target.type != TARG_TYPE_CLIENT) == -1)
return;
conn->flags |= CO_FL_ADDR_TO_SET;
}
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
/* Assigns a connection with the appropriate data, ctrl, transport layers, and owner. */
static inline void conn_assign(struct connection *conn, const struct data_cb *data,
const struct protocol *ctrl, const struct xprt_ops *xprt,
void *owner)
CLEANUP: connection: offer conn_prepare() to set up a connection This will be used by checks as well as stream interfaces.
2012-09-24 15:15:42 +00:00
{
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 22:41:04 +00:00
conn->data = data;
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
conn->ctrl = ctrl;
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
conn->xprt = xprt;
MINOR: connection: add a pointer to the connection owner This will be needed to find the stream interface from the connection once they're detached, but in the more immediate term, we'll need this for health checks since they don't use a stream interface.
2012-09-27 20:14:33 +00:00
conn->owner = owner;
MINOR: connection: split conn_prepare() in two functions We'll also need a function to takeover an existing connection without reinitializing it. The same will be needed at the stream interface level.
2012-10-02 18:57:19 +00:00
}
/* prepares a connection with the appropriate data, ctrl, transport layers, and
* owner. The transport state and context are set to 0.
*/
static inline void conn_prepare(struct connection *conn, const struct data_cb *data,
const struct protocol *ctrl, const struct xprt_ops *xprt,
void *owner)
{
conn_assign(conn, data, ctrl, xprt, owner);
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
conn->xprt_st = 0;
conn->xprt_ctx = NULL;
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: 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
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