upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-02-17 17:47:56 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 4
haproxy/src/stream_interface.c

1681 lines
51 KiB
C
Raw Normal View History

[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
/*
* Functions managing stream_interface structures
*
CLEANUP: stream_interface: stop exporting socket layer functions Similarly to the previous patch, we don't need the socket-layer functions outside of stream_interface. They could even move to a file dedicated to applets, though that does not seem particularly useful at the moment.
2012-05-11 11:47:17 -04:00
* Copyright 2000-2012 Willy Tarreau <w@1wt.eu>
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
#include <errno.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/types.h>
MAJOR: session: implement a wait-queue for sessions who need a buffer When a session_alloc_buffers() fails to allocate one or two buffers, it subscribes the session to buffer_wq, and waits for another session to release buffers. It's then removed from the queue and woken up with TASK_WAKE_RES, and can attempt its allocation again. We decide to try to wake as many waiters as we release buffers so that if we release 2 and two waiters need only once, they both have their chance. We must never come to the situation where we don't wake enough tasks up. It's common to release buffers after the completion of an I/O callback, which can happen even if the I/O could not be performed due to half a failure on memory allocation. In this situation, we don't want to move out of the wait queue the session that was just added, otherwise it will never get any buffer. Thus, we only force ourselves out of the queue when freeing the session. Note: at the moment, since session_alloc_buffers() is not used, no task is subscribed to the wait queue.
2014-11-25 15:10:35 -05:00
#include <common/buffer.h>
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
#include <common/compat.h>
#include <common/config.h>
#include <common/debug.h>
#include <common/standard.h>
#include <common/ticks.h>
#include <common/time.h>
REORG: applet: move the applet definitions out of stream_interface We're tidying the definitions so that appctx lives on its own. A new set of applet.h files has been added for this purpose.
2015-04-13 07:24:54 -04:00
#include <proto/applet.h>
REORG: buffers: split buffers into chunk,buffer,channel Many parts of the channel definition still make use of the "buffer" word.
2012-08-24 13:22:53 -04:00
#include <proto/channel.h>
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 09:06:49 -04:00
#include <proto/connection.h>
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
#include <proto/http_htx.h>
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
#include <proto/mux_pt.h>
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
#include <proto/pipe.h>
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
#include <proto/proxy.h>
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
#include <proto/stream.h>
[BUILD] stream_interface: fix conflicting declaration stream_int_check_timeouts was declared void while it's an int.
2009-09-20 14:14:49 -04:00
#include <proto/stream_interface.h>
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
#include <proto/task.h>
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04:00
#include <types/pipe.h>
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* functions used by default on a detached stream-interface */
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutr(struct stream_interface *si);
static void stream_int_shutw(struct stream_interface *si);
CLEANUP: stream_interface: stop exporting socket layer functions Similarly to the previous patch, we don't need the socket-layer functions outside of stream_interface. They could even move to a file dedicated to applets, though that does not seem particularly useful at the moment.
2012-05-11 11:47:17 -04:00
static void stream_int_chk_rcv(struct stream_interface *si);
static void stream_int_chk_snd(struct stream_interface *si);
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* functions used on a conn_stream-based stream-interface */
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutr_conn(struct stream_interface *si);
static void stream_int_shutw_conn(struct stream_interface *si);
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
static void stream_int_chk_rcv_conn(struct stream_interface *si);
static void stream_int_chk_snd_conn(struct stream_interface *si);
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* functions used on an applet-based stream-interface */
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
static void stream_int_shutr_applet(struct stream_interface *si);
static void stream_int_shutw_applet(struct stream_interface *si);
static void stream_int_chk_rcv_applet(struct stream_interface *si);
static void stream_int_chk_snd_applet(struct stream_interface *si);
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* last read notification */
static void stream_int_read0(struct stream_interface *si);
/* post-IO notification callback */
static void stream_int_notify(struct stream_interface *si);
CLEANUP: stream_interface: stop exporting socket layer functions Similarly to the previous patch, we don't need the socket-layer functions outside of stream_interface. They could even move to a file dedicated to applets, though that does not seem particularly useful at the moment.
2012-05-11 11:47:17 -04:00
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
/* stream-interface operations for embedded tasks */
struct si_ops si_embedded_ops = {
REORG/MEDIUM: stream_interface: initialize socket ops from descriptors
2012-05-07 11:15:39 -04:00
.chk_rcv = stream_int_chk_rcv,
.chk_snd = stream_int_chk_snd,
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
.shutr = stream_int_shutr,
.shutw = stream_int_shutw,
REORG/MEDIUM: stream_interface: initialize socket ops from descriptors
2012-05-07 11:15:39 -04:00
};
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
/* stream-interface operations for connections */
struct si_ops si_conn_ops = {
.chk_rcv = stream_int_chk_rcv_conn,
.chk_snd = stream_int_chk_snd_conn,
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
.shutr = stream_int_shutr_conn,
.shutw = stream_int_shutw_conn,
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
};
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
/* stream-interface operations for connections */
struct si_ops si_applet_ops = {
.chk_rcv = stream_int_chk_rcv_applet,
.chk_snd = stream_int_chk_snd_applet,
.shutr = stream_int_shutr_applet,
.shutw = stream_int_shutw_applet,
};
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* Functions used to communicate with a conn_stream. The first two may be used
* directly, the last one is mostly a wake callback.
*/
int si_cs_recv(struct conn_stream *cs);
int si_cs_send(struct conn_stream *cs);
static int si_cs_process(struct conn_stream *cs);
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 18:41:04 -04:00
struct data_cb si_conn_cb = {
MINOR: h2/stream_interface: Reintroduce te wake() method. For the time being, reintroduce the wake methods, it may be revisited later.h
2018-09-14 17:21:44 -04:00
.wake = si_cs_process,
MINOR: connection: add names for transport and data layers This makes debugging easier and avoids having to put ugly checks against certain well-known internal struct pointers.
2016-11-24 10:58:12 -05:00
.name = "STRM",
REORG/MEDIUM: stream_interface: initialize socket ops from descriptors
2012-05-07 11:15:39 -04:00
};
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
/*
* This function only has to be called once after a wakeup event in case of
* suspected timeout. It controls the stream interface timeouts and sets
* si->flags accordingly. It does NOT close anything, as this timeout may
* be used for any purpose. It returns 1 if the timeout fired, otherwise
* zero.
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
int si_check_timeouts(struct stream_interface *si)
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
{
if (tick_is_expired(si->exp, now_ms)) {
si->flags |= SI_FL_EXP;
return 1;
}
return 0;
}
[MAJOR] complete layer4/7 separation All the processing has now completely been split in layers. As of now, everything is still in process_session() which is not the right place, but the code sequence works. Timeouts, retries, errors, all work. The shutdown sequence has been strictly applied: BF_SHUTR/BF_SHUTW are only assigned by lower layers. Upper layers can only indicate their wish to close using BF_SHUTR_NOW and BF_SHUTW_NOW. When a shutdown is performed on a stream interface, the buffer flags are updated accordingly and re-checked by upper layers. A lot of care has been taken to ensure that aborts during intermediate connection setups are correctly handled and shutdowns correctly propagated to both buffers. A future evolution would consist in ensuring that BF_SHUT?_NOW may be set at any time, and applies only when the buffer is empty. This might help with error messages, but might complicate the processing of data remaining in buffers. Some useless buffer flag combinations have been removed. Stat counters are still broken (eg: per-server total number of sessions). Error messages should be delayed to the close instant and be produced by protocol. Many functions must now move to proper locations.
2008-11-30 12:14:12 -05:00
/* to be called only when in SI_ST_DIS with SI_FL_ERR */
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
void si_report_error(struct stream_interface *si)
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
{
if (!si->err_type)
si->err_type = SI_ET_DATA_ERR;
REORG/MEDIUM: stream-int: introduce si_ic/si_oc to access channels We'll soon remove direct references to the channels from the stream interface since everything belongs to the same session, so let's first not dereference si->ib / si->ob anymore and use macros instead.
2014-11-28 05:11:05 -05:00
si_oc(si)->flags |= CF_WRITE_ERROR;
si_ic(si)->flags |= CF_READ_ERROR;
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
}
[MINOR] replace client_retnclose() with stream_int_retnclose() This makes more sense to return a message to a stream interface than to a session. senddata.{c,h} have been removed.
2008-11-30 13:48:07 -05:00
/*
* Returns a message to the client ; the connection is shut down for read,
* and the request is cleared so that no server connection can be initiated.
* The buffer is marked for read shutdown on the other side to protect the
* message, and the buffer write is enabled. The message is contained in a
[BUG] stream_interface: fix retnclose and remove cond_close The stream_int_cond_close() function was added to preserve the contents of the response buffer because stream_int_retnclose() was buggy. It flushed the response instead of flushing the request. This caused issues with pipelined redirects followed by error messages which ate the previous response. This might even have caused object truncation on pipelined requests followed by an error or by a server redirection. Now that this is fixed, simply get rid of the now useless function.
2010-01-10 04:21:21 -05:00
* "chunk". If it is null, then an empty message is used. The reply buffer does
* not need to be empty before this, and its contents will not be overwritten.
* The primary goal of this function is to return error messages to a client.
[MINOR] replace client_retnclose() with stream_int_retnclose() This makes more sense to return a message to a stream interface than to a session. senddata.{c,h} have been removed.
2008-11-30 13:48:07 -05:00
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
void si_retnclose(struct stream_interface *si,
MAJOR: chunks: replace struct chunk with struct buffer Now all the code used to manipulate chunks uses a struct buffer instead. The functions are still called "chunk*", and some of them will progressively move to the generic buffer handling code as they are cleaned up.
2018-07-13 05:56:34 -04:00
const struct buffer *msg)
[MINOR] replace client_retnclose() with stream_int_retnclose() This makes more sense to return a message to a stream interface than to a session. senddata.{c,h} have been removed.
2008-11-30 13:48:07 -05:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
channel_auto_read(ic);
channel_abort(ic);
channel_auto_close(ic);
channel_erase(ic);
channel_truncate(oc);
[BUG] stream_interface: truncate buffers when sending error messages When an error message is returned to a client, all buffer contents were left intact. Since the analysers were removed, the potentially invalid data that were read had a chance to be sent too. Now we ensure we only keep the already scheduled data in the buffer and we truncate it after that. That means that responses with data that must be blocked will really be blocked, and that incorrectly chunked data will be stopped at the point where the chunking fails.
2010-12-12 07:06:00 -05:00
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
if (likely(msg && msg->data))
co_inject(oc, msg->area, msg->data);
[MINOR] replace client_retnclose() with stream_int_retnclose() This makes more sense to return a message to a stream interface than to a session. senddata.{c,h} have been removed.
2008-11-30 13:48:07 -05:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->wex = tick_add_ifset(now_ms, oc->wto);
channel_auto_read(oc);
channel_auto_close(oc);
channel_shutr_now(oc);
[MINOR] new function stream_int_cond_close() This one will be used to conditionally send a message upon a close on a stream interface. It will not overwrite any existing data.
2009-12-27 16:51:06 -05:00
}
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
/*
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
* This function performs a shutdown-read on a detached stream interface in a
* connected or init state (it does nothing for other states). It either shuts
* the read side or marks itself as closed. The buffer flags are updated to
* reflect the new state. If the stream interface has SI_FL_NOHALF, we also
* forward the close to the write side. The owner task is woken up if it exists.
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
*/
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutr(struct stream_interface *si)
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si_rx_shut_blk(si);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->flags & CF_SHUTR)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
if (si->state != SI_ST_EST && si->state != SI_ST_CON)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
REORG/MEDIUM: stream-int: introduce si_ic/si_oc to access channels We'll soon remove direct references to the channels from the stream interface since everything belongs to the same session, so let's first not dereference si->ib / si->ob anymore and use macros instead.
2014-11-28 05:11:05 -05:00
if (si_oc(si)->flags & CF_SHUTW) {
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
si->state = SI_ST_DIS;
si->exp = TICK_ETERNITY;
[BUG] stream_interface: only call si->release when both dirs are closed si->release() was called each time we closed one direction of a stream interface, while it should only have been called when both sides are closed. This bug is specific to 1.5 and only affects embedded tasks.
2010-09-07 10:16:50 -04:00
}
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
else if (si->flags & SI_FL_NOHALF) {
/* we want to immediately forward this close to the write side */
return stream_int_shutw(si);
}
[MEDIUM] stream-interface: add a ->release callback When a connection is closed on a stream interface, some iohandlers will need to be informed in order to release some resources. This normally happens upon a shutr+shutw. It is the equivalent of the fd_delete() call which is done for real sockets, except that this time we release internal resources. It can also be used with real sockets because it does not cost anything else and might one day be useful.
2010-07-02 05:18:03 -04:00
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
/* note that if the task exists, it must unregister itself once it runs */
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
if (!(si->flags & SI_FL_DONT_WAKE))
task_wakeup(si_task(si), TASK_WOKEN_IO);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
/*
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
* This function performs a shutdown-write on a detached stream interface in a
* connected or init state (it does nothing for other states). It either shuts
* the write side or marks itself as closed. The buffer flags are updated to
* reflect the new state. It does also close everything if the SI was marked as
* being in error state. The owner task is woken up if it exists.
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
*/
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutw(struct stream_interface *si)
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
oc->flags &= ~CF_SHUTW_NOW;
if (oc->flags & CF_SHUTW)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags |= CF_SHUTW;
oc->wex = TICK_ETERNITY;
MINOR: stream-int: make use of si_done_{get,put}() in shut{w,r} It's cleaner to use these functions there to properly clear the flags.
2018-11-06 13:23:03 -05:00
si_done_get(si);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
BUG/MEDIUM: stream: fix client-fin/server-fin handling A tcp half connection can cause 100% CPU on expiration. First reproduced with this haproxy configuration : global tune.bufsize 10485760 defaults timeout server-fin 90s timeout client-fin 90s backend node2 mode tcp timeout server 900s timeout connect 10s server def 127.0.0.1:3333 frontend fe_api mode tcp timeout client 900s bind :1990 use_backend node2 Ie timeout server-fin shorter than timeout server, the backend server sends data, this package is left in the cache of haproxy, the backend server continue sending fin package, haproxy recv fin package. this time the session information is as follows: time the session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=1s calls=3 rq[f=848000h,i=0,an=00h,rx=14m58s,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=,wx=14m58s,ax=] s0=[7,0h,fd=6,ex=] s1=[7,18h,fd=7,ex=] exp=14m58s rp has set the CF_SHUTR state, next, the client sends the fin package, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=38s calls=4 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=1m11s,wx=14m21s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=1m11s After waiting 90s, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=04 age=4m11s calls=718074391 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=?,wx=10m49s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=? run(nice=0) cpu information: 6899 root 20 0 112224 21408 4260 R 100.0 0.7 3:04.96 haproxy Buffering is set to ensure that there is data in the haproxy buffer, and haproxy can receive the fin package, set the CF_SHUTR flag, If the CF_SHUTR flag has been set, The following code does not clear the timeout message, causing cpu 100%: stream.c:process_stream: if (unlikely((res->flags & (CF_SHUTR|CF_READ_TIMEOUT)) == CF_READ_TIMEOUT)) { if (si_b->flags & SI_FL_NOHALF) si_b->flags |= SI_FL_NOLINGER; si_shutr(si_b); } If you have closed the read, set the read timeout does not make sense. With or without cf_shutr, read timeout is set: if (tick_isset(s->be->timeout.serverfin)) { res->rto = s->be->timeout.serverfin; res->rex = tick_add(now_ms, res->rto); } After discussion on the mailing list, setting half-closed timeouts the hard way here doesn't make sense. They should be set only at the moment the shutdown() is performed. It will also solve a special case which was already reported of some half-closed timeouts not working when the shutw() is performed directly at the stream-interface layer (no analyser involved). Since the stream interface layer cannot know the timeout values, we'll have to store them directly in the stream interface so that they are used upon shutw(). This patch does this, fixing the problem. An easier reproducer to validate the fix is to keep the huge buffer and shorten all timeouts, then call it under tcploop server and client, and wait 3 seconds to see haproxy run at 100% CPU : global tune.bufsize 10485760 listen px bind :1990 timeout client 90s timeout server 90s timeout connect 1s timeout server-fin 3s timeout client-fin 3s server def 127.0.0.1:3333 $ tcploop 3333 L W N20 A P100 F P10000 & $ tcploop 127.0.0.1:1990 C S10000000 F
2017-03-10 12:41:51 -05:00
if (tick_isset(si->hcto)) {
ic->rto = si->hcto;
ic->rex = tick_add(now_ms, ic->rto);
}
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
switch (si->state) {
case SI_ST_EST:
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
/* we have to shut before closing, otherwise some short messages
* may never leave the system, especially when there are remaining
* unread data in the socket input buffer, or when nolinger is set.
* However, if SI_FL_NOLINGER is explicitly set, we know there is
* no risk so we close both sides immediately.
*/
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
if (!(si->flags & (SI_FL_ERR | SI_FL_NOLINGER)) &&
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
!(ic->flags & (CF_SHUTR|CF_DONT_READ)))
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
/* fall through */
case SI_ST_CON:
case SI_ST_CER:
[CRITICAL] session: correctly leave turn-around and queue states on abort When a client connection aborts while the server-side connection is in turn-around after a failed connection attempt, the turn-around timeout is reset in shutw() but the state is not changed. The session then remains stuck in this state forever. Change the QUE and TAR states to DIS just as we do for CER to fix this. This patch should be backported to 1.4.
2010-12-29 08:03:02 -05:00
case SI_ST_QUE:
case SI_ST_TAR:
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
/* Note that none of these states may happen with applets */
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
si->state = SI_ST_DIS;
default:
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si->flags &= ~SI_FL_NOLINGER;
si_rx_shut_blk(si);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
si->exp = TICK_ETERNITY;
}
MAJOR: stream_int: use a common stream_int_shut*() functions regardless of the data layer Up to now, we had to use a shutr/shutw interface per data layer, which basically means 3 distinct functions when we include SSL : - generic stream_interface - sock_raw - sock_ssl With this change, the code located in the stream_interface manages all the stream_interface and buffer updates, and calls the data layer hooks when needed. At the moment, the socket layer hook had been implicitly considered as being a regular socket, so the si_shut*() functions call the normal shutdown() and EV_FD_CLR() functions on the fd if a socket layer is defined. This may change in the future. The stream_int_shut*() functions don't call EV_FD_CLR() so that they can later be embedded in lower layers. Thus, the si->data->shutr() is not called anymore and si->data->shutw() is called to close the data layer only (eg: only for SSL). Proceeding like this is very important because it's the only way to be able not to rely on these functions when called from the connection handlers, and call the data layers' instead.
2012-08-06 13:31:45 -04:00
/* note that if the task exists, it must unregister itself once it runs */
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
if (!(si->flags & SI_FL_DONT_WAKE))
task_wakeup(si_task(si), TASK_WOKEN_IO);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
/* default chk_rcv function for scheduled tasks */
CLEANUP: stream_interface: stop exporting socket layer functions Similarly to the previous patch, we don't need the socket-layer functions outside of stream_interface. They could even move to a file dedicated to applets, though that does not seem particularly useful at the moment.
2012-05-11 11:47:17 -04:00
static void stream_int_chk_rcv(struct stream_interface *si)
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
DPRINTF(stderr, "%s: si=%p, si->state=%d ic->flags=%08x oc->flags=%08x\n",
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
__FUNCTION__,
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
si, si->state, ic->flags, si_oc(si)->flags);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
if (ic->pipe) {
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
/* stop reading */
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_blk(si);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
else {
/* (re)start reading */
MEDIUM: connections: Don't directly mess with the polling from the upper layers. Avoid using conn_xprt_want_send/recv, and totally nuke cs_want_send/recv, from the upper layers. The polling is now directly handled by the connection layer, it is activated on subscribe(), and unactivated once we got the event and we woke the related task.
2018-10-10 09:46:36 -04:00
tasklet_wakeup(si->wait_event.task);
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
if (!(si->flags & SI_FL_DONT_WAKE))
task_wakeup(si_task(si), TASK_WOKEN_IO);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
}
/* default chk_snd function for scheduled tasks */
CLEANUP: stream_interface: stop exporting socket layer functions Similarly to the previous patch, we don't need the socket-layer functions outside of stream_interface. They could even move to a file dedicated to applets, though that does not seem particularly useful at the moment.
2012-05-11 11:47:17 -04:00
static void stream_int_chk_snd(struct stream_interface *si)
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *oc = si_oc(si);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
DPRINTF(stderr, "%s: si=%p, si->state=%d ic->flags=%08x oc->flags=%08x\n",
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
__FUNCTION__,
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
si, si->state, si_ic(si)->flags, oc->flags);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (unlikely(si->state != SI_ST_EST || (oc->flags & CF_SHUTW)))
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
return;
if (!(si->flags & SI_FL_WAIT_DATA) || /* not waiting for data */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
channel_is_empty(oc)) /* called with nothing to send ! */
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
return;
/* Otherwise there are remaining data to be sent in the buffer,
* so we tell the handler.
*/
si->flags &= ~SI_FL_WAIT_DATA;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (!tick_isset(oc->wex))
oc->wex = tick_add_ifset(now_ms, oc->wto);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
if (!(si->flags & SI_FL_DONT_WAKE))
task_wakeup(si_task(si), TASK_WOKEN_IO);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
CLEANUP: stream-int: fix a few outdated comments about stream_int_register_handler() They were not updated after the infrastructure change.
2015-07-19 12:46:30 -04:00
/* Register an applet to handle a stream_interface as a new appctx. The SI will
* wake it up everytime it is solicited. The appctx must be deleted by the task
* handler using si_release_endpoint(), possibly from within the function itself.
* It also pre-initializes the applet's context and returns it (or NULL in case
* it could not be allocated).
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
struct appctx *si_register_handler(struct stream_interface *si, struct applet *app)
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
{
MAJOR: stream-interface: dynamically allocate the applet context From now on, a call to stream_int_register_handler() causes a call to si_alloc_appctx() and returns an initialized appctx for the current stream interface. If one was previously allocated, it is released. If the stream interface was attached to a connection, it is released as well. The appctx are allocated from the same pools as the connections, because they're substantially smaller in size, and we can't have both a connection and an appctx on an interface at any moment. In case of memory shortage, the call may return NULL, which is already handled by all consumers of stream_int_register_handler(). The field appctx was removed from the stream interface since we only rely on the endpoint now. On 32-bit, the stream_interface size went down from 108 to 44 bytes. On 64-bit, it went down from 144 to 64 bytes. This represents a memory saving of 160 bytes per session. It seems that a later improvement could be to move the call to stream_int_register_handler() to session.c for most cases.
2013-12-01 05:31:38 -05:00
struct appctx *appctx;
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
DPRINTF(stderr, "registering handler %p for si %p (was %p)\n", app, si, si_task(si));
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
MINOR: stream-int: make appctx_new() take the applet in argument Doing so simplifies the initialization of a new appctx. We don't need appctx_set_applet() anymore.
2015-04-04 18:15:26 -04:00
appctx = si_alloc_appctx(si, app);
BUG/MAJOR: stream-int: properly check the memory allocation return In stream_int_register_handler(), we call si_alloc_appctx(si) but as a mistake, instead of checking the return value for a NULL, we test <si>. This bug was discovered under extreme memory contention (memory for only two buffers with 500 connections waiting) and after 3 million failed connections. While it was very hard to produce it, the fix is tagged major because in theory it could happen when haproxy runs with a very low "-m" setting preventing from allocating just the few bytes needed for an appctx. But most users will never be able to trigger it. The fix was confirmed to address the bug. This fix must be backported to 1.5.
2014-12-22 13:34:00 -05:00
if (!appctx)
MAJOR: stream-interface: dynamically allocate the applet context From now on, a call to stream_int_register_handler() causes a call to si_alloc_appctx() and returns an initialized appctx for the current stream interface. If one was previously allocated, it is released. If the stream interface was attached to a connection, it is released as well. The appctx are allocated from the same pools as the connections, because they're substantially smaller in size, and we can't have both a connection and an appctx on an interface at any moment. In case of memory shortage, the call may return NULL, which is already handled by all consumers of stream_int_register_handler(). The field appctx was removed from the stream interface since we only rely on the endpoint now. On 32-bit, the stream_interface size went down from 108 to 44 bytes. On 64-bit, it went down from 144 to 64 bytes. This represents a memory saving of 160 bytes per session. It seems that a later improvement could be to move the call to stream_int_register_handler() to session.c for most cases.
2013-12-01 05:31:38 -05:00
return NULL;
MINOR: stream-int: rename si_applet_{want|stop|cant}_{get|put} It doesn't make sense to limit this code to applets, as any stream interface can use it. Let's rename it by simply dropping the "applet_" part of the name. No other change was made except updating the comments.
2018-11-06 12:46:37 -05:00
si_cant_get(si);
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
appctx_wakeup(appctx);
MEDIUM: stream-int: return the allocated appctx in stream_int_register_handler() The task returned by stream_int_register_handler() is never used, however we always need to access the appctx afterwards. So make it return the appctx instead. We already plan for it to fail, which is the reason for the addition of a few tests and the possibility for the HTTP analyser to return a status code 500.
2013-12-01 03:35:41 -05:00
return si_appctx(si);
[MINOR] stream_interface: add functions to support running as internal/external tasks It will soon be necessary to have stream interfaces running as part of the current task, or as independant tasks. For instance when we want to implement compression or SSL. It will also be used for applets running as stream interfaces. These new functions are used to perform exactly that. Note that it's still not easy to write a simple echo applet and more functions will likely be needed.
2009-09-05 14:57:35 -04:00
}
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
/* This callback is used to send a valid PROXY protocol line to a socket being
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 08:45:22 -04:00
* established. It returns 0 if it fails in a fatal way or needs to poll to go
* further, otherwise it returns non-zero and removes itself from the connection's
MEDIUM: proxy-proto: don't use buffer flags in conn_si_send_proxy() These ones should only be handled by the stream interface at the end of the handshake now. Similarly a number of information are now taken at the connection level rather than at the data level (eg: shutdown). Fast polling updates have been used instead of slow ones since the function is only called by the connection handler.
2012-08-24 06:14:49 -04:00
* flags (the bit is provided in <flag> by the caller). It is designed to be
* called by the connection handler and relies on it to commit polling changes.
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
* Note that it can emit a PROXY line by relying on the other end's address
* when the connection is attached to a stream interface, or by resolving the
* local address otherwise (also called a LOCAL line).
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
*/
int conn_si_send_proxy(struct connection *conn, unsigned int flag)
{
/* we might have been called just after an asynchronous shutw */
MEDIUM: proxy-proto: don't use buffer flags in conn_si_send_proxy() These ones should only be handled by the stream interface at the end of the handshake now. Similarly a number of information are now taken at the connection level rather than at the data level (eg: shutdown). Fast polling updates have been used instead of slow ones since the function is only called by the connection handler.
2012-08-24 06:14:49 -04:00
if (conn->flags & CO_FL_SOCK_WR_SH)
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
goto out_error;
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 04:23:20 -05:00
if (!conn_ctrl_ready(conn))
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
goto out_error;
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
/* If we have a PROXY line to send, we'll use this to validate the
* connection, in which case the connection is validated only once
* we've sent the whole proxy line. Otherwise we use connect().
*/
CLEANUP: stream: Remove bogus loop in conn_si_send_proxy The if-statement was converted into a while-loop in 7fe45698f58a53dda9182a5970a2ea4bda9f92fe to handle EINTR. This special handling was later replaced in 0a03c0f022faf2773995fc8b9d14256c8a306e5a by conn_sock_send. The while-loop was not changed back and is not unconditionally exited after one iteration, with no `continue` inside the body. Replace by an if-statement.
2019-02-26 11:09:51 -05:00
if (conn->send_proxy_ofs) {
MINOR: stream-int: make conn_si_send_proxy() use cs_get_first() The function used to abuse the internals of mux_pt to retrieve a conn_stream, which will not work anymore after the idle connection changes. Let's make it rely on the more reliable cs_get_first() instead.
2018-11-18 15:38:19 -05:00
const struct conn_stream *cs;
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
int ret;
MINOR: stream-int: make conn_si_send_proxy() use cs_get_first() The function used to abuse the internals of mux_pt to retrieve a conn_stream, which will not work anymore after the idle connection changes. Let's make it rely on the more reliable cs_get_first() instead.
2018-11-18 15:38:19 -05:00
cs = cs_get_first(conn);
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
/* The target server expects a PROXY line to be sent first.
* If the send_proxy_ofs is negative, it corresponds to the
* offset to start sending from then end of the proxy string
* (which is recomputed every time since it's constant). If
* it is positive, it means we have to send from the start.
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
* We can only send a "normal" PROXY line when the connection
* is attached to a stream interface. Otherwise we can only
* send a LOCAL line (eg: for use with health checks).
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
*/
MINOR: stream-int: make conn_si_send_proxy() use cs_get_first() The function used to abuse the internals of mux_pt to retrieve a conn_stream, which will not work anymore after the idle connection changes. Let's make it rely on the more reliable cs_get_first() instead.
2018-11-18 15:38:19 -05:00
if (cs && cs->data_cb == &si_conn_cb) {
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
struct stream_interface *si = cs->data;
struct conn_stream *remote_cs = objt_cs(si_opposite(si)->end);
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ret = make_proxy_line(trash.area, trash.size,
objt_server(conn->target),
remote_cs ? remote_cs->conn : NULL);
BUG/MEDIUM: connection: Use the session to get the origin address if needed. In conn_si_send_proxy(), if we don't have a conn_stream yet, because the mux won't be created until the SSL handshake is done, retrieve the opposite's connection from the session. At this point, we know the session associated with the connection is the one that initiated it, and we can thus just use the session's origin. This should be backported to 1.9.
2019-05-29 11:08:03 -04:00
/* We may not have a conn_stream yet, if we don't
* know which mux to use, because it will be decided
* during the SSL handshake. In this case, there should
* be a session associated to the connection in
* conn->owner, and we know it is the session that
* initiated that connection, so we can just use
* its origin, which should contain the client
* connection.
*/
} else if (!cs && conn->owner) {
struct session *sess = conn->owner;
ret = make_proxy_line(trash.area, trash.size,
objt_server(conn->target),
objt_conn(sess->origin));
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
}
else {
/* The target server expects a LOCAL line to be sent first. Retrieving
* local or remote addresses may fail until the connection is established.
*/
conn_get_from_addr(conn);
if (!(conn->flags & CO_FL_ADDR_FROM_SET))
goto out_wait;
conn_get_to_addr(conn);
if (!(conn->flags & CO_FL_ADDR_TO_SET))
goto out_wait;
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ret = make_proxy_line(trash.area, trash.size,
objt_server(conn->target), conn);
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
}
MAJOR: stream-int: stop using si->conn and use si->end instead The connection will only remain there as a pre-allocated entity whose goal is to be placed in ->end when establishing an outgoing connection. All connection initialization can be made on this connection, but all information retrieved should be applied to the end point only. This change is huge because there were many users of si->conn. Now the only users are those who initialize the new connection. The difficulty appears in a few places such as backend.c, proto_http.c, peers.c where si->conn is used to hold the connection's target address before assigning the connection to the stream interface. This is why we have to keep si->conn for now. A future improvement might consist in dynamically allocating the connection when it is needed.
2013-10-01 04:45:07 -04:00
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
if (!ret)
goto out_error;
MEDIUM: connection: move the send_proxy offset to the connection Till now the send_proxy_ofs field remained in the stream interface, but since the dynamic allocation of the connection, it makes a lot of sense to move that into the connection instead of the stream interface, since it will not be statically allocated for each session. Also, it turns out that moving it to the connection fils an alignment hole on 64 bit architectures so it does not consume more memory, and removing it from the stream interface was an opportunity to correctly reorder fields and reduce the stream interface's size from 160 to 144 bytes (-10%). This is 32 bytes saved per session.
2013-10-24 15:10:08 -04:00
if (conn->send_proxy_ofs > 0)
conn->send_proxy_ofs = -ret; /* first call */
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
MEDIUM: proxy-proto: don't use buffer flags in conn_si_send_proxy() These ones should only be handled by the stream interface at the end of the handshake now. Similarly a number of information are now taken at the connection level rather than at the data level (eg: shutdown). Fast polling updates have been used instead of slow ones since the function is only called by the connection handler.
2012-08-24 06:14:49 -04:00
/* we have to send trash from (ret+sp for -sp bytes). If the
* data layer has a pending write, we'll also set MSG_MORE.
*/
MEDIUM: chunks: make the chunk struct's fields match the buffer struct Chunks are only a subset of a buffer (a non-wrapping version with no head offset). Despite this we still carry a lot of duplicated code between buffers and chunks. Replacing chunks with buffers would significantly reduce the maintenance efforts. This first patch renames the chunk's fields to match the name and types used by struct buffers, with the goal of isolating the code changes from the declaration changes. Most of the changes were made with spatch using this coccinelle script : @rule_d1@ typedef chunk; struct chunk chunk; @@ - chunk.str + chunk.area @rule_d2@ typedef chunk; struct chunk chunk; @@ - chunk.len + chunk.data @rule_i1@ typedef chunk; struct chunk *chunk; @@ - chunk->str + chunk->area @rule_i2@ typedef chunk; struct chunk *chunk; @@ - chunk->len + chunk->data Some minor updates to 3 http functions had to be performed to take size_t ints instead of ints in order to match the unsigned length here.
2018-07-13 04:54:26 -04:00
ret = conn_sock_send(conn,
trash.area + ret + conn->send_proxy_ofs,
-conn->send_proxy_ofs,
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 12:30:23 -04:00
(conn->flags & CO_FL_XPRT_WR_ENA) ? MSG_MORE : 0);
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
MEDIUM: stream-int: make conn_si_send_proxy() use conn_sock_send() This substantially simplifies the code as we don't need to handle the file descriptors anymore nor the specific error codes from send().
2015-03-12 19:05:28 -04:00
if (ret < 0)
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
goto out_error;
MEDIUM: connection: move the send_proxy offset to the connection Till now the send_proxy_ofs field remained in the stream interface, but since the dynamic allocation of the connection, it makes a lot of sense to move that into the connection instead of the stream interface, since it will not be statically allocated for each session. Also, it turns out that moving it to the connection fils an alignment hole on 64 bit architectures so it does not consume more memory, and removing it from the stream interface was an opportunity to correctly reorder fields and reduce the stream interface's size from 160 to 144 bytes (-10%). This is 32 bytes saved per session.
2013-10-24 15:10:08 -04:00
conn->send_proxy_ofs += ret; /* becomes zero once complete */
if (conn->send_proxy_ofs != 0)
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
goto out_wait;
/* OK we've sent the whole line, we're connected */
}
MEDIUM: proxy-proto: don't use buffer flags in conn_si_send_proxy() These ones should only be handled by the stream interface at the end of the handshake now. Similarly a number of information are now taken at the connection level rather than at the data level (eg: shutdown). Fast polling updates have been used instead of slow ones since the function is only called by the connection handler.
2012-08-24 06:14:49 -04:00
/* The connection is ready now, simply return and let the connection
* handler notify upper layers if needed.
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
*/
if (conn->flags & CO_FL_WAIT_L4_CONN)
conn->flags &= ~CO_FL_WAIT_L4_CONN;
conn->flags &= ~flag;
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 08:45:22 -04:00
return 1;
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
out_error:
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 08:45:22 -04:00
/* Write error on the file descriptor */
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
conn->flags |= CO_FL_ERROR;
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 08:45:22 -04:00
return 0;
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
out_wait:
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 08:45:22 -04:00
return 0;
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
}
MEDIUM: stream-int: implement a very simplistic idle connection manager Idle connections are not monitored right now. So if a server closes after a response without advertising it, it won't be detected until a next request wants to use the connection. This is a bit problematic because it unnecessarily maintains file descriptors and sockets in an idle state. This patch implements a very simple idle connection manager for the stream interface. It presents itself as an I/O callback. The HTTP engine enables it when it recycles a connection. If a close or an error is detected on the underlying socket, it tries to drain as much data as possible from the socket, detect the close and responds with a close as well, then detaches from the stream interface.
2013-12-16 18:00:28 -05:00
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
/* This function is the equivalent to si_update() except that it's
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
* designed to be called from outside the stream handlers, typically the lower
* layers (applets, connections) after I/O completion. After updating the stream
* interface and timeouts, it will try to forward what can be forwarded, then to
* wake the associated task up if an important event requires special handling.
MINOR: stream-int: rename SI_FL_WAIT_ROOM to SI_FL_RXBLK_ROOM This flag is not enough to describe all blocking situations, as can be seen in each case we remove it. The muxes has taught us that using multiple blocking flags in parallel will be much easier, so let's start to do this now. This patch only renames this flags in order to make next changes more readable.
2018-11-14 05:10:26 -05:00
* It may update SI_FL_WAIT_DATA and/or SI_FL_RXBLK_ROOM, that the callers are
MINOR: stream-int: make stream_int_notify() not wake the tasklet up stream_int_notify() is I/O agnostic and should not wake up the tasklet, it's up to si_cs_process() to do that, just like si_applet_wake_cb() does it for the applet.
2018-10-25 07:55:20 -04:00
* encouraged to watch to take appropriate action.
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
* It should not be called from within the stream itself, si_update()
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
* is designed for this.
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
static void stream_int_notify(struct stream_interface *si)
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
{
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
struct stream_interface *sio = si_opposite(si);
BUG/MAJOR: stream-int: Update the stream expiration date in stream_int_notify() Since a long time, the expiration date of a stream is only updated in process_stream(). It is calculated, among others, using the channels expiration dates for reads and writes (.rex and .wex values). But these values are updated by the stream-interface. So when this happens at the connection layer, the update is only done if the stream's task is woken up. Otherwise, the stream expiration date is not immediatly updated. This leads to unexpected behaviours. Time to time, users reported that the wrong timeout was hitted or the wrong termination state was reported. This is partly because of this bug. Recently, we observed some blocked sessions for a while when big objects are served from the cache applet. It seems only concern the clients not reading the response. Because delivered objects are big, not all data can be sent. And because delivered objects are big, data are fast forwarded (from the input to the output with no stream wakeup). So in such situation, the stream expiration date is never updated and no timeout is hitted. The session remains blocked while the client remains connected. This bug exists at least since HAProxy 1.5. But recent changes on the connection layer make it more visible. It must be backported from 1.9 to 1.6. And with more pain it should be backported to 1.5.
2019-01-03 10:24:54 -05:00
struct task *task = si_task(si);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
/* process consumer side */
if (channel_is_empty(oc)) {
MINOR: ssl: Make sure we don't shutw the connection before the handshake. Instead of trying to finish the handshake in ssl_sock_shutw, which may fail, try not to shutdown until the handshake is finished.
2017-11-16 11:49:25 -05:00
struct connection *conn = objt_cs(si->end) ? objt_cs(si->end)->conn : NULL;
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
if (((oc->flags & (CF_SHUTW|CF_SHUTW_NOW)) == CF_SHUTW_NOW) &&
MINOR: ssl: Make sure we don't shutw the connection before the handshake. Instead of trying to finish the handshake in ssl_sock_shutw, which may fail, try not to shutdown until the handshake is finished.
2017-11-16 11:49:25 -05:00
(si->state == SI_ST_EST) && (!conn || !(conn->flags & (CO_FL_HANDSHAKE | CO_FL_EARLY_SSL_HS))))
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
si_shutw(si);
oc->wex = TICK_ETERNITY;
}
BUG/MINOR: stream-int: automatically release SI_FL_WAIT_DATA on SHUTW_NOW While developing an experimental applet performing only one read per full line, it appeared that it would be woken up for the client's close, not read all data (missing LF), then wait for a subsequent call, and would only be woken up on client timeout to finish the read. The reason is that we preset SI_FL_WAIT_DATA in the stream-interface's flags to avoid a fast loop, but there's nothing which can remove this flag until there's a read operation. We must definitely remove it in stream_int_notify() each time we're called with CF_SHUTW_NOW because we know there will be no more subsequent read and we don't want an applet which keeps the WANT_GET flag to block on this. This fix should be backported to 1.7 and 1.6 though it's uncertain whether cli, peers, lua or spoe really are affected there.
2016-12-13 09:21:25 -05:00
/* indicate that we may be waiting for data from the output channel or
* we're about to close and can't expect more data if SHUTW_NOW is there.
*/
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
if (!(oc->flags & (CF_SHUTW|CF_SHUTW_NOW)))
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
si->flags |= SI_FL_WAIT_DATA;
BUG/MINOR: stream-int: automatically release SI_FL_WAIT_DATA on SHUTW_NOW While developing an experimental applet performing only one read per full line, it appeared that it would be woken up for the client's close, not read all data (missing LF), then wait for a subsequent call, and would only be woken up on client timeout to finish the read. The reason is that we preset SI_FL_WAIT_DATA in the stream-interface's flags to avoid a fast loop, but there's nothing which can remove this flag until there's a read operation. We must definitely remove it in stream_int_notify() each time we're called with CF_SHUTW_NOW because we know there will be no more subsequent read and we don't want an applet which keeps the WANT_GET flag to block on this. This fix should be backported to 1.7 and 1.6 though it's uncertain whether cli, peers, lua or spoe really are affected there.
2016-12-13 09:21:25 -05:00
else if ((oc->flags & (CF_SHUTW|CF_SHUTW_NOW)) == CF_SHUTW_NOW)
si->flags &= ~SI_FL_WAIT_DATA;
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
/* update OC timeouts and wake the other side up if it's waiting for room */
if (oc->flags & CF_WRITE_ACTIVITY) {
if ((oc->flags & (CF_SHUTW|CF_WRITE_PARTIAL)) == CF_WRITE_PARTIAL &&
!channel_is_empty(oc))
if (tick_isset(oc->wex))
oc->wex = tick_add_ifset(now_ms, oc->wto);
if (!(si->flags & SI_FL_INDEP_STR))
if (tick_isset(ic->rex))
ic->rex = tick_add_ifset(now_ms, ic->rto);
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
}
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
if ((sio->flags & SI_FL_RXBLK_ROOM) &&
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
((oc->flags & CF_WRITE_PARTIAL) || channel_is_empty(oc)))
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_rdy(sio);
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (oc->flags & CF_DONT_READ)
si_rx_chan_blk(sio);
else
si_rx_chan_rdy(sio);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
/* Notify the other side when we've injected data into the IC that
* needs to be forwarded. We can do fast-forwarding as soon as there
* are output data, but we avoid doing this if some of the data are
* not yet scheduled for being forwarded, because it is very likely
* that it will be done again immediately afterwards once the following
MINOR: stream-int: rename SI_FL_WAIT_ROOM to SI_FL_RXBLK_ROOM This flag is not enough to describe all blocking situations, as can be seen in each case we remove it. The muxes has taught us that using multiple blocking flags in parallel will be much easier, so let's start to do this now. This patch only renames this flags in order to make next changes more readable.
2018-11-14 05:10:26 -05:00
* data are parsed (eg: HTTP chunking). We only SI_FL_RXBLK_ROOM once
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
* we've emptied *some* of the output buffer, and not just when there
* is available room, because applets are often forced to stop before
* the buffer is full. We must not stop based on input data alone because
* an HTTP parser might need more data to complete the parsing.
*/
if (!channel_is_empty(ic) &&
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
(sio->flags & SI_FL_WAIT_DATA) &&
MINOR: stream-int: relax the forwarding rules in stream_int_notify() There currently is an optimization in stream_int_notify() consisting in not trying to forward small bits of data if extra data remain to be processed. The purpose is to avoid forwarding one chunk at a time if multiple chunks are available to be parsed at once. It consists in avoiding sending pending output data if there are still data to be parsed in the channel's buffer, since process_stream() will have the opportunity to deal with them all at once. Not only this optimization is less useful with the new way the connections work, but it even causes problems like lost events since WAIT_ROOM will not be removed. And with HTX, it will never be able to update the input buffer after the first read. Let's relax the rules now, by always sending if we don't have the CF_EXPECT_MORE flag (used to group writes), or if the buffer is already full.
2018-11-18 09:46:10 -05:00
(!(ic->flags & CF_EXPECT_MORE) || c_full(ic) || ci_data(ic) == 0 || ic->pipe)) {
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
int new_len, last_len;
MINOR: stream-int: use the new buffer API A few locations still accessing ->i and ->o directly were changed to use ci_data() and co_data() respectively. A call to b_del() was replaced with co_set_data() in si_cs_send() so that ->o will is automatically be decremented after the migration.
2018-06-19 01:03:14 -04:00
last_len = co_data(ic);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
if (ic->pipe)
last_len += ic->pipe->data;
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
si_chk_snd(sio);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
MINOR: stream-int: use the new buffer API A few locations still accessing ->i and ->o directly were changed to use ci_data() and co_data() respectively. A call to b_del() was replaced with co_set_data() in si_cs_send() so that ->o will is automatically be decremented after the migration.
2018-06-19 01:03:14 -04:00
new_len = co_data(ic);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
if (ic->pipe)
new_len += ic->pipe->data;
/* check if the consumer has freed some space either in the
* buffer or in the pipe.
*/
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
if (new_len < last_len)
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_rdy(si);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
}
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (!(ic->flags & CF_DONT_READ))
si_rx_chan_rdy(si);
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
si_chk_rcv(si);
si_chk_rcv(sio);
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (si_rx_blocked(si)) {
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
ic->rex = TICK_ETERNITY;
}
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
else if ((ic->flags & (CF_SHUTR|CF_READ_PARTIAL)) == CF_READ_PARTIAL) {
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
/* we must re-enable reading if si_chk_snd() has freed some space */
if (!(ic->flags & CF_READ_NOEXP) && tick_isset(ic->rex))
ic->rex = tick_add_ifset(now_ms, ic->rto);
}
/* wake the task up only when needed */
if (/* changes on the production side */
(ic->flags & (CF_READ_NULL|CF_READ_ERROR)) ||
BUG/MEDIUM: stream-int: don't wake up for nothing during SI_ST_CON Commit eafd8ebcf ("MEDIUM: stream-int: call si_cs_process() in stream_int_update_conn") uncovered a sleeping bug. By calling si_cs_process() within si_update(), we end up calling stream_int_notify(). We rely on it to update the stream-int before quitting as a hack, but it happens to immediately wake the task up while the stream int's state is still SI_ST_CON (during the connection establishment). The observable effect is that an unreachable server causes haproxy to use 100% CPU until the connection timeout strikes. This patch fixes this by not causing the wake up for the SI_ST_CON state. It would equally be possible to check for states higher than SI_ST_EST as is done in other places, but for now better stay on the safe side by covering the only issue that can be triggered. It's suspected that this issue slightly affects older versions by causing one extra call to process_stream() during the connection setup for each activity change on the other side, but this should not have any observable effect. No backport is needed.
2018-11-08 08:32:16 -05:00
(si->state != SI_ST_EST && si->state != SI_ST_CON) ||
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
(si->flags & SI_FL_ERR) ||
((ic->flags & CF_READ_PARTIAL) &&
MINOR: channel: Report EOI on the input channel if it was reached in the mux The flag CF_EOI is now set on the input channel when the flag CS_FL_EOI is set on the corresponding conn_stream. In addition, if a read activity is reported when this flag is set, the stream is woken up. This patch should be backported to 1.9.
2019-03-22 09:16:14 -04:00
((ic->flags & CF_EOI) || !ic->to_forward || sio->state != SI_ST_EST)) ||
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
/* changes on the consumption side */
(oc->flags & (CF_WRITE_NULL|CF_WRITE_ERROR)) ||
MEDIUM: channel: merge back flags CF_WRITE_PARTIAL and CF_WRITE_EVENT The behaviour of the flag CF_WRITE_PARTIAL was modified by commit 95fad5ba4 ("BUG/MAJOR: stream-int: don't re-arm recv if send fails") due to a situation where it could trigger an immediate wake up of the other side, both acting in loops via the FD cache. This loss has caused the need to introduce CF_WRITE_EVENT as commit c5a9d5bf, to replace it, but both flags express more or less the same thing and this distinction creates a lot of confusion and complexity in the code. Since the FD cache now acts via tasklets, the issue worked around in the first patch no longer exists, so it's more than time to kill this hack and to restore CF_WRITE_PARTIAL's semantics (i.e.: there has been some write activity since we last left process_stream). This patch mostly reverts the two commits above. Only the part making use of CF_WROTE_DATA instead of CF_WRITE_PARTIAL to detect the loss of data upon connection setup was kept because it's more accurate and better suited.
2018-10-24 11:17:56 -04:00
((oc->flags & CF_WRITE_ACTIVITY) &&
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
((oc->flags & CF_SHUTW) ||
BUG/MEDIUM: stream-int: also wake the stream up on end of transfer There is an issue with some medium sized transfers occasionally not shutting down at the end. Olivier tracked this to being caused by a missing wakeup of process_stream(). What happens is that one of the analysers sets CF_WAKE_WRITE to be woken up at the end of the transfer to take note of the end of transaction, but a failed si_cs_send() at the end of process_stream causes the call to be attempted again, with CF_WAKE_WRITE lost. Then stream_int_notify() doesn't find any valid condition to wake up process_stream(), and the stream stays there, idling till the timeout. In fact, CF_WAKE_WRITE has been designed for calling the analysers to complete an operation without closing (keep-alive HTTP transfer for instance). It only applies once the buffer is empty and there is nothing left to be forwarded. In case the channel is closed, the wakeup is already granted. So what we need here is to make sure to wake process_stream() up in case the channel will not be closed and it doesn't have anything left to be transferred. This is detected by the lack of CF_AUTO_CLOSE and the emptiness of the buffer + to_forward after a write activity. So now we take care of always waking the stream up on end of transfers even if the analysers didn't subscribe to this or if their subscription was lost. CF_WAKE_WRITE should probably be killed now, though this first requires careful inspection. No backport is needed. Cc: Olivier Houchard <ohouchard@haproxy.com> Cc: Christopher Faulet <cfaulet@haproxy.com>
2018-12-19 05:00:00 -05:00
(((oc->flags & CF_WAKE_WRITE) ||
!(oc->flags & (CF_AUTO_CLOSE|CF_SHUTW_NOW|CF_SHUTW))) &&
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
(sio->state != SI_ST_EST ||
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
(channel_is_empty(oc) && !oc->to_forward)))))) {
BUG/MAJOR: stream-int: Update the stream expiration date in stream_int_notify() Since a long time, the expiration date of a stream is only updated in process_stream(). It is calculated, among others, using the channels expiration dates for reads and writes (.rex and .wex values). But these values are updated by the stream-interface. So when this happens at the connection layer, the update is only done if the stream's task is woken up. Otherwise, the stream expiration date is not immediatly updated. This leads to unexpected behaviours. Time to time, users reported that the wrong timeout was hitted or the wrong termination state was reported. This is partly because of this bug. Recently, we observed some blocked sessions for a while when big objects are served from the cache applet. It seems only concern the clients not reading the response. Because delivered objects are big, not all data can be sent. And because delivered objects are big, data are fast forwarded (from the input to the output with no stream wakeup). So in such situation, the stream expiration date is never updated and no timeout is hitted. The session remains blocked while the client remains connected. This bug exists at least since HAProxy 1.5. But recent changes on the connection layer make it more visible. It must be backported from 1.9 to 1.6. And with more pain it should be backported to 1.5.
2019-01-03 10:24:54 -05:00
task_wakeup(task, TASK_WOKEN_IO);
}
else {
/* Update expiration date for the task and requeue it */
task->expire = tick_first((tick_is_expired(task->expire, now_ms) ? 0 : task->expire),
tick_first(tick_first(ic->rex, ic->wex),
tick_first(oc->rex, oc->wex)));
task_queue(task);
MINOR: stream-int: implement the stream_int_notify() function stream_int_notify() was taken from the common part between si_conn_wake_cb() and si_applet_done(). It is designed to report activity to a stream from outside its handler. It'll generally be used by lower layers to report I/O completion but may also be used by remote streams if the buffer processing is shared.
2015-09-23 12:40:09 -04:00
}
if (ic->flags & CF_READ_ACTIVITY)
ic->flags &= ~CF_READ_DONTWAIT;
}
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
/* Called by I/O handlers after completion.. It propagates
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
* connection flags to the stream interface, updates the stream (which may or
* may not take this opportunity to try to forward data), then update the
* connection's polling based on the channels and stream interface's final
* states. The function always returns 0.
MEDIUM: stream_interface: offer a generic function for connection updates We need to have a generic function to be called by upper layers when buffer flags have been updated (the si->update function). At the moment, both sock_raw and sock_ssl had their own which basically was a copy-paste. Since these functions are only used to update stream interface flags, it is logical to have them handled by the stream interface code. This allowed us to remove the stream_interface-specific update function from sock_raw and sock_ssl which now use the generic code. The stream_sock_update_conn callback has also been more appropriately renamed conn_notify_si() since it's meant to be called by lower layers to notify the SI and possibly upper layers about incoming changes.
2012-08-20 06:06:26 -04:00
*/
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
static int si_cs_process(struct conn_stream *cs)
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04: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 12:30:23 -04:00
struct connection *conn = cs->conn;
struct stream_interface *si = cs->data;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04:00
BUG/MEDIUM: stream_interface: try to call si_cs_send() earlier. Call si_cs_send() at the beginning of si_cs_wake_cb(), instead of from stream_int_notify-), so that if we get a connection error while trying to send, the stream_interface will get SI_FL_ERR, the associated task will be woken up, and the connection will be properly destroyed. No backport needed.
2018-08-28 13:37:41 -04:00
/* If we have data to send, try it now */
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (!channel_is_empty(oc) && !(si->wait_event.events & SUB_RETRY_SEND))
MINOR: stream-int: don't needlessly call si_cs_send() in si_cs_process() There's a call there to si_cs_send() while we're supposed to come from si_cs_io_cb() which has just done it. But in fact we can also come here as a lower layer callback from ->wake() after a connection is established. Since most of the time we'll end up here with either no data in the buffer or a blocked output, let's simply check if we're already susbcribed to send events before calling si_cs_send().
2018-10-25 08:02:47 -04:00
si_cs_send(cs);
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
/* First step, report to the stream-int what was detected at the
* connection layer : errors and connection establishment.
*/
MINOR: connection: make conn_stream users also check for per-stream error flag In a 1:1 connection:stream there's no problem relying on the connection flags alone to check for errors. But in a mux, it will be possible to mark certain streams in error without having to mark all of them. An example is an H2 client sending RST_STREAM frames to abort a long download, or a parse error requiring to abort only this specific stream. This commit ensures that stream-interface and checks properly check for CS_FL_ERROR in cs->flags wherever CO_FL_ERROR was in use. Most likely over the long term, any check for CO_FL_ERROR will have to disappear.
2017-10-16 09:17:17 -04:00
if (conn->flags & CO_FL_ERROR || cs->flags & CS_FL_ERROR)
MEDIUM: stream_interface: centralize the SI_FL_ERR management It's better to have only stream_sock_update_conn() handle the conversion of the CO_FL_ERROR flag to SI_FL_ERR than having it in each and every I/O callback.
2012-07-23 13:19:51 -04:00
si->flags |= SI_FL_ERR;
MINOR: ssl/proto_http: Add keywords to take care of early data. Add a new sample fetch, "ssl_fc_has_early", a boolean that will be true if early data were sent, and a new action, "wait-for-handshake", if used, the request won't be forwarded until the SSL handshake is done.
2017-10-02 05:51:03 -04:00
/* If we had early data, and the handshake ended, then
* we can remove the flag, and attempt to wake the task up,
* in the event there's an analyser waiting for the end of
* the handshake.
*/
MINOR: early data: Don't rely on CO_FL_EARLY_DATA to wake up streams. Instead of looking for CO_FL_EARLY_DATA to know if we have to try to wake up a stream, because it is waiting for a SSL handshake, instead add a new conn_stream flag, CS_FL_WAIT_FOR_HS. This way we don't have to rely on CO_FL_EARLY_DATA, and we will only wake streams that are actually waiting.
2017-11-27 12:41:32 -05:00
if (!(conn->flags & (CO_FL_HANDSHAKE | CO_FL_EARLY_SSL_HS)) &&
(cs->flags & CS_FL_WAIT_FOR_HS)) {
cs->flags &= ~CS_FL_WAIT_FOR_HS;
MINOR: ssl/proto_http: Add keywords to take care of early data. Add a new sample fetch, "ssl_fc_has_early", a boolean that will be true if early data were sent, and a new action, "wait-for-handshake", if used, the request won't be forwarded until the SSL handshake is done.
2017-10-02 05:51:03 -04:00
task_wakeup(si_task(si), TASK_WOKEN_MSG);
}
BUG/MAJOR: stream-int: do not depend on connection flags to detect connection Recent fix 7bf3fa3 ("BUG/MAJOR: connection: update CO_FL_CONNECTED before calling the data layer") marked an end to a fragile situation where the absence of CO_FL_{CONNECTED,L4,L6}* flags is used to mark the completion of a connection setup. The problem is that by setting the CO_FL_CONNECTED flag earlier, we can indeed call the ->wake() function from conn_fd_handler but the stream-interface's wake function needs to see CO_FL_CONNECTED unset to detect that a connection has just been established, so if there's no pending data in the buffer, the connection times out. The other ->wake() functions (health checks and idle connections) don't do this though. So instead of trying to detect a subtle change in connection flags, let's simply rely on the stream-interface's state and validate that the connection is properly established and that handshakes are completed before reporting the WRITE_NULL indicating that a pending connection was just completed. This patch passed all tests of handshake and non-handshake combinations, with synchronous and asynchronous connect() and should be safe for backport to 1.7, 1.6 and 1.5 when the fix above is already present.
2017-03-18 12:11:37 -04:00
if ((si->state < SI_ST_EST) &&
(conn->flags & (CO_FL_CONNECTED | CO_FL_HANDSHAKE)) == CO_FL_CONNECTED) {
MAJOR: connection: add a new CO_FL_CONNECTED flag This new flag is used to indicate that the connection was already connected. It can be used by I/O handlers to know that a connection has just completed. It is used by stream_sock_update_conn(), allowing the sock_opt handlers not to manipulate the SI timeout nor the BF_WRITE_NULL flag anymore.
2012-07-23 13:45:44 -04:00
si->exp = TICK_ETERNITY;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags |= CF_WRITE_NULL;
MAJOR: connection: add a new CO_FL_CONNECTED flag This new flag is used to indicate that the connection was already connected. It can be used by I/O handlers to know that a connection has just completed. It is used by stream_sock_update_conn(), allowing the sock_opt handlers not to manipulate the SI timeout nor the BF_WRITE_NULL flag anymore.
2012-07-23 13:45:44 -04:00
}
MINOR: channel: Report EOI on the input channel if it was reached in the mux The flag CF_EOI is now set on the input channel when the flag CS_FL_EOI is set on the corresponding conn_stream. In addition, if a read activity is reported when this flag is set, the stream is woken up. This patch should be backported to 1.9.
2019-03-22 09:16:14 -04:00
/* Report EOI on the channel if it was reached from the mux point of
* view. */
if ((cs->flags & CS_FL_EOI) && !(ic->flags & CF_EOI))
BUG/MINOR: mux-h1: Report EOI instead EOS on parsing error or H2 upgrade When a parsing error occurrs in the H1 multiplexer, we stop to copy HTX blocks. So the error may be reported with an emtpy HTX message. For instance, if the headers parsing failed. When it happens, the flag CS_FL_EOS is also set on the conn_stream. But it is an error. Most of time, it is set on established connections, so it is not really an issue. But if it happens when the server connection is not fully established, the connection is shut down immediatly and the stream-interface is switched from SI_ST_CON to SI_ST_DIS/CLO. So HTX analyzers have no chance to catch the error. Instead of setting CS_FL_EOS, it is fairly better to set CS_FL_EOI, which is the right flag to use. The same is also done on H2 upgrade. As a side effet of this fix, in the stream-interface code, we must now set the flag CF_READ_PARTIAL on the channel when the flag CF_EOI is set. It is a warranty to wakeup the stream when EOI is reported to the channel while no data are received. This patch must be backported to 1.9.
2019-05-17 03:14:10 -04:00
ic->flags |= (CF_EOI|CF_READ_PARTIAL);
MINOR: muxes: Report the Last read with a dedicated flag For conveniance, in HTTP muxes (h1 and h2), the end of the stream and the end of the message are reported the same way to the stream, by setting the flag CS_FL_EOS. In the stream-interface, when CS_FL_EOS is detected, a shutdown for read is reported on the channel side. This is historical. With the legacy HTTP layer, because the parsing is done by the stream in HTTP analyzers, the EOS really means a shutdown for read. Most of time, for muxes h1 and h2, it works pretty well, especially because the keep-alive is handled by the muxes. The stream is only used for one transaction. So mixing EOS and EOM is good enough. But not everytime. For now, client aborts are only reported if it happens before the end of the request. It is an error and it is properly handled. But because the EOS was already reported, client aborts after the end of the request are silently ignored. Eventually an error can be reported when the response is sent to the client, if the sending fails. Otherwise, if the server does not reply fast enough, an error is reported when the server timeout is reached. It is the expected behaviour, excpect when the option abortonclose is set. In this case, we must report an error when the client aborts. But as said before, this event can be ignored. So to be short, for now, the abortonclose is broken. In fact, it is a design problem and we have to rethink all channel's flags and probably the conn-stream ones too. It is important to split EOS and EOM to not loose information anymore. But it is not a small job and the refactoring will be far from straightforward. So for now, temporary flags are introduced. When the last read is received, the flag CS_FL_READ_NULL is set on the conn-stream. This way, we can set the flag SI_FL_READ_NULL on the stream interface. Both flags are persistant. And to be sure to wake the stream, the event CF_READ_NULL is reported. So the stream will always have the chance to handle the last read. This patch must be backported to 1.9 because it will be used by another patch to fix the option abortonclose.
2019-03-08 03:23:46 -05:00
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
/* Second step : update the stream-int and channels, try to forward any
* pending data, then possibly wake the stream up based on the new
* stream-int status.
MAJOR: stream-interface: make conn_notify_si() more robust This function was relying on the result of file descriptor polling which is inappropriate as it may be subject to race conditions during handshakes. Make it more robust by relying solely on buffer activity.
2012-08-24 06:12:53 -04:00
*/
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
stream_int_notify(si);
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 11:30:18 -05:00
channel_release_buffer(ic, &(si_strm(si)->buffer_wait));
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04:00
MEDIUM: connection: make it possible for data->wake to return an error Just like ->init(), ->wake() may now be used to return an error and abort the connection. Currently this is not used but will be with embryonic sessions.
2012-10-03 15:12:16 -04:00
return 0;
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04:00
}
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
/*
* This function is called to send buffer data to a stream socket.
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
* It calls the mux layer's snd_buf function. It relies on the
OPTIM: stream_interface: return directly if the connection flag CO_FL_ERROR has been set The connection flag CO_FL_ERROR will be tested in the functions both si_conn_recv_cb() and si_conn_send_cb(). If CO_FL_ERROR has been set, out_error branch will be executed. But the only job of out_error branch is to set CO_FL_ERROR on connection flag. So it's better return directly than goto out_error branch under such conditions. As a result, out_error branch becomes needless and can be removed. In addition, the return type of si_conn_send_loop() is also changed to void. The caller should check conn->flags for errors just like stream_int_chk_snd_conn() does as below: static void stream_int_chk_snd_conn(struct stream_interface *si) { ... conn_refresh_polling_flags(si->conn); - if (si_conn_send(si->conn) < 0) { + si_conn_send(si->conn); + if (si->conn->flags & CO_FL_ERROR) { ... } Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-12-04 04:24:06 -05:00
* caller to commit polling changes. The caller should check conn->flags
* for errors.
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
*/
BUG/MEDIUM: process_stream: Don't use si_cs_io_cb() in process_stream(). Instead of using si_cs_io_cb() in process_stream() use si_cs_send/si_cs_recv instead, as si_cs_io_cb() may lead to process_stream being woken up when it shouldn't be, and thus timeout would never get triggered.
2018-09-14 13:41:13 -04:00
int si_cs_send(struct conn_stream *cs)
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04: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 12:30:23 -04:00
struct connection *conn = cs->conn;
struct stream_interface *si = cs->data;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *oc = si_oc(si);
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
int ret;
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
int did_send = 0;
/* We're already waiting to be able to send, give up */
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (si->wait_event.events & SUB_RETRY_SEND)
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
return 0;
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
if (conn->flags & CO_FL_ERROR || cs->flags & (CS_FL_ERROR|CS_FL_ERR_PENDING)) {
si->flags |= SI_FL_ERR;
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
}
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
/* we might have been called just after an asynchronous shutw */
MINOR: stream-int: remove useless checks on CS and conn flags in si_cs_send() In si_cs_send(), some checks are done the CS flags en the connection flags before calling snd_buf(). But these checks are useless because they have already been done earlier in the function. The harder to figure out is the flag CO_FL_SOCK_WR_SH. So it is now tested with CF_SHUTW at the beginning.
2018-11-20 04:30:02 -05:00
if (conn->flags & CO_FL_SOCK_WR_SH || oc->flags & CF_SHUTW)
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04: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 12:30:23 -04:00
if (oc->pipe && conn->xprt->snd_pipe && conn->mux->snd_pipe) {
ret = conn->mux->snd_pipe(cs, oc->pipe);
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
if (ret > 0) {
MEDIUM: channel: merge back flags CF_WRITE_PARTIAL and CF_WRITE_EVENT The behaviour of the flag CF_WRITE_PARTIAL was modified by commit 95fad5ba4 ("BUG/MAJOR: stream-int: don't re-arm recv if send fails") due to a situation where it could trigger an immediate wake up of the other side, both acting in loops via the FD cache. This loss has caused the need to introduce CF_WRITE_EVENT as commit c5a9d5bf, to replace it, but both flags express more or less the same thing and this distinction creates a lot of confusion and complexity in the code. Since the FD cache now acts via tasklets, the issue worked around in the first patch no longer exists, so it's more than time to kill this hack and to restore CF_WRITE_PARTIAL's semantics (i.e.: there has been some write activity since we last left process_stream). This patch mostly reverts the two commits above. Only the part making use of CF_WROTE_DATA instead of CF_WRITE_PARTIAL to detect the loss of data upon connection setup was kept because it's more accurate and better suited.
2018-10-24 11:17:56 -04:00
oc->flags |= CF_WRITE_PARTIAL | CF_WROTE_DATA;
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
did_send = 1;
}
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (!oc->pipe->data) {
put_pipe(oc->pipe);
oc->pipe = NULL;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
}
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
if (conn->flags & CO_FL_ERROR || cs->flags & (CS_FL_ERROR|CS_FL_ERR_PENDING)) {
si->flags |= SI_FL_ERR;
MINOR: stream-int: Notify caller when an error is reported after a rcv_pipe() In si_cs_send(), when an error is found on the CS or the connection at the beginning of the function, we return 1 to notify the caller some processing may be triggered. So, it seems logical to do the same after the call to rcv_pipe(). This patch is not flagged as a bug because no strange behaviour was yet observed without it. It is just a proactive fix to be consistent.
2018-11-19 16:02:07 -05:00
return 1;
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
}
BUG/MINOR: stream-int: Don't call snd_buf() if there are still data in the pipe In si_cs_send, as said in comments, snd_buf() should only be called if there is no data in the pipe anymore. But actually, this condition was not respected.
2018-11-20 04:21:08 -05:00
if (oc->pipe)
goto end;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
}
/* At this point, the pipe is empty, but we may still have data pending
* in the normal buffer.
*/
MINOR: stream-int: remove useless checks on CS and conn flags in si_cs_send() In si_cs_send(), some checks are done the CS flags en the connection flags before calling snd_buf(). But these checks are useless because they have already been done earlier in the function. The harder to figure out is the flag CO_FL_SOCK_WR_SH. So it is now tested with CF_SHUTW at the beginning.
2018-11-20 04:30:02 -05:00
if (co_data(oc)) {
/* when we're here, we already know that there is no spliced
* data left, and that there are sendable buffered data.
*/
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
/* check if we want to inform the kernel that we're interested in
* sending more data after this call. We want this if :
* - we're about to close after this last send and want to merge
* the ongoing FIN with the last segment.
* - we know we can't send everything at once and must get back
* here because of unaligned data
* - there is still a finite amount of data to forward
* The test is arranged so that the most common case does only 2
* tests.
*/
MEDIUM: connection: don't use real send() flags in snd_buf() This prevents us from passing other useful info and requires the upper levels to know these flags. Let's use a new flags category instead : CO_SFL_*. For now, only MSG_MORE has been remapped.
2014-02-01 19:51:17 -05:00
unsigned int send_flag = 0;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if ((!(oc->flags & (CF_NEVER_WAIT|CF_SEND_DONTWAIT)) &&
((oc->to_forward && oc->to_forward != CHN_INFINITE_FORWARD) ||
BUG/MINOR: stream-int: don't set MSG_MORE on SHUTW_NOW without AUTO_CLOSE Since around 1.5-dev12, we've been setting MSG_MORE on send() on various conditions, including the fact that SHUTW_NOW is present, but we don't check that it's accompanied with AUTO_CLOSE. The result is that on requests immediately followed by a close (where AUTO_CLOSE is not set), the request gets delayed in the TCP stack before being sent to the server. This is visible with the H2 code where the end-of-stream flag is set on requests, but probably happens when a POLL_HUP is detected along with the request. The (lack of) presence of option abortonclose has no effect here since we never send the SHUTW along with the request. This fix can be backported to 1.7, 1.6 and 1.5.
2017-10-17 10:33:46 -04:00
(oc->flags & CF_EXPECT_MORE))) ||
BUG/MINOR: stream-int: don't set MSG_MORE on closed request path Commit 4ac4928 ("BUG/MINOR: stream-int: don't set MSG_MORE on SHUTW_NOW without AUTO_CLOSE") was incomplete. H2 reveals another situation where the input stream is marked closed with the request and we set MSG_MORE, causing a delay before the request leaves. Better avoid setting the flag on the request path for close cases in general.
2017-11-07 09:07:25 -05:00
((oc->flags & CF_ISRESP) &&
((oc->flags & (CF_AUTO_CLOSE|CF_SHUTW_NOW)) == (CF_AUTO_CLOSE|CF_SHUTW_NOW))))
MEDIUM: connection: don't use real send() flags in snd_buf() This prevents us from passing other useful info and requires the upper levels to know these flags. Let's use a new flags category instead : CO_SFL_*. For now, only MSG_MORE has been remapped.
2014-02-01 19:51:17 -05:00
send_flag |= CO_SFL_MSG_MORE;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (oc->flags & CF_STREAMER)
OPTIM: ssl: implement dynamic record size adjustment By having the stream interface pass the CF_STREAMER flag to the snd_buf() primitive, we're able to tell the send layer whether we're sending large chunks or small ones. We use this information in SSL to adjust the max record dynamically. This results in small chunks respecting tune.ssl.maxrecord at the beginning of a transfer or for small transfers, with an automatic switch to full records if the exchanges last long. This allows the receiver to parse HTML contents on the fly without having to retrieve 16kB of data, which is even more important with small initcwnd since the receiver does not need to wait for round trips to start fetching new objects. However, sending large files still produces large chunks. For example, with tune.ssl.maxrecord = 2859, we see 5 write(2885) sent in two segments each and 6 write(16421). This idea was first proposed on the haproxy mailing list by Ilya Grigorik.
2014-02-01 20:00:24 -05:00
send_flag |= CO_SFL_STREAMER;
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
if ((si->flags & SI_FL_L7_RETRY) && !b_data(&si->l7_buffer)) {
BUG/MEDIUM: streams: Don't use CF_EOI to decide if the request is complete. In si_cs_send(), don't check CF_EOI on the request channel to decide if the request is complete and if we should save the buffer to eventually attempt L7 retries. The flag may not be set yet, and it may too be set to early, before we're done modifying the buffer. Instead, get the msg, and make sure its state is HTTP_MSG_DONE. That way we will store the request buffer when sending it even in H2.
2019-05-17 09:38:29 -04:00
struct stream *s = si_strm(si);
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
/* If we want to be able to do L7 retries, copy
* the data we're about to send, so that we are able
* to resend them if needed
*/
/* Try to allocate a buffer if we had none.
* If it fails, the next test will just
* disable the l7 retries by setting
* l7_conn_retries to 0.
*/
BUG/MEDIUM: streams: Don't use CF_EOI to decide if the request is complete. In si_cs_send(), don't check CF_EOI on the request channel to decide if the request is complete and if we should save the buffer to eventually attempt L7 retries. The flag may not be set yet, and it may too be set to early, before we're done modifying the buffer. Instead, get the msg, and make sure its state is HTTP_MSG_DONE. That way we will store the request buffer when sending it even in H2.
2019-05-17 09:38:29 -04:00
if (!s->txn || (s->txn->req.msg_state != HTTP_MSG_DONE))
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
si->flags &= ~SI_FL_L7_RETRY;
else {
if (b_is_null(&si->l7_buffer))
b_alloc(&si->l7_buffer);
if (b_is_null(&si->l7_buffer))
si->flags &= ~SI_FL_L7_RETRY;
else {
memcpy(b_orig(&si->l7_buffer),
b_orig(&oc->buf),
b_size(&oc->buf));
si->l7_buffer.head = co_data(oc);
b_add(&si->l7_buffer, co_data(oc));
}
}
}
MINOR: connections: Get rid of txbuf. Remove txbuf from conn_stream. It is not used yet, and its only user will probably be the mux_h2, so it will be better suited in the struct h2s.
2018-08-16 09:41:52 -04:00
ret = cs->conn->mux->snd_buf(cs, &oc->buf, co_data(oc), send_flag);
CLEANUP: stream_interface: cleanup loop information in si_conn_send_loop() Though si_conn_send_loop() does not loop over ->snd_buf() after commit ed7f836, there is still some codes left which use `while` but only execute once. This commit does the cleanup job and rename si_conn_send_loop() to si_conn_send(). Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-10-11 03:48:29 -04:00
if (ret > 0) {
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
did_send = 1;
MEDIUM: channel: merge back flags CF_WRITE_PARTIAL and CF_WRITE_EVENT The behaviour of the flag CF_WRITE_PARTIAL was modified by commit 95fad5ba4 ("BUG/MAJOR: stream-int: don't re-arm recv if send fails") due to a situation where it could trigger an immediate wake up of the other side, both acting in loops via the FD cache. This loss has caused the need to introduce CF_WRITE_EVENT as commit c5a9d5bf, to replace it, but both flags express more or less the same thing and this distinction creates a lot of confusion and complexity in the code. Since the FD cache now acts via tasklets, the issue worked around in the first patch no longer exists, so it's more than time to kill this hack and to restore CF_WRITE_PARTIAL's semantics (i.e.: there has been some write activity since we last left process_stream). This patch mostly reverts the two commits above. Only the part making use of CF_WROTE_DATA instead of CF_WRITE_PARTIAL to detect the loss of data upon connection setup was kept because it's more accurate and better suited.
2018-10-24 11:17:56 -04:00
oc->flags |= CF_WRITE_PARTIAL | CF_WROTE_DATA;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
MINOR: stream-int: use the new buffer API A few locations still accessing ->i and ->o directly were changed to use ci_data() and co_data() respectively. A call to b_del() was replaced with co_set_data() in si_cs_send() so that ->o will is automatically be decremented after the migration.
2018-06-19 01:03:14 -04:00
co_set_data(oc, co_data(oc) - ret);
MEDIUM: mux: make mux->snd_buf() take the byte count in argument This way the mux doesn't need to modify the buffer's metadata anymore nor to know the output's size. The mux->snd_buf() function now takes a const buffer and it's up to the caller to update the buffer's state. The return type was updated to return a size_t to comply with the count argument.
2018-06-14 12:38:55 -04:00
c_realign_if_empty(oc);
if (!co_data(oc)) {
CLEANUP: stream_interface: cleanup loop information in si_conn_send_loop() Though si_conn_send_loop() does not loop over ->snd_buf() after commit ed7f836, there is still some codes left which use `while` but only execute once. This commit does the cleanup job and rename si_conn_send_loop() to si_conn_send(). Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-10-11 03:48:29 -04:00
/* Always clear both flags once everything has been sent, they're one-shot */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags &= ~(CF_EXPECT_MORE | CF_SEND_DONTWAIT);
CLEANUP: stream_interface: cleanup loop information in si_conn_send_loop() Though si_conn_send_loop() does not loop over ->snd_buf() after commit ed7f836, there is still some codes left which use `while` but only execute once. This commit does the cleanup job and rename si_conn_send_loop() to si_conn_send(). Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-10-11 03:48:29 -04:00
}
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
CLEANUP: stream_interface: cleanup loop information in si_conn_send_loop() Though si_conn_send_loop() does not loop over ->snd_buf() after commit ed7f836, there is still some codes left which use `while` but only execute once. This commit does the cleanup job and rename si_conn_send_loop() to si_conn_send(). Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-10-11 03:48:29 -04:00
/* if some data remain in the buffer, it's only because the
* system buffers are full, we will try next time.
*/
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
}
MINOR: stream-int: Notify caller when an error is reported after a rcv_buf() For the same reason than for the commit b46784b1c ("MINOR: stream-int: Notify caller when an error is reported after a rcv_pipe()"), we return 1 after the call to rcv_buf() in si_cs_send() to notify the caller some processing may be triggered. This patch is not flagged as a bug because no strange behaviour was yet observed without it. It is just a proactive fix to be consistent.
2018-11-20 03:34:35 -05:00
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
if (conn->flags & CO_FL_ERROR || cs->flags & (CS_FL_ERROR|CS_FL_ERR_PENDING)) {
si->flags |= SI_FL_ERR;
MINOR: stream-int: Notify caller when an error is reported after a rcv_buf() For the same reason than for the commit b46784b1c ("MINOR: stream-int: Notify caller when an error is reported after a rcv_pipe()"), we return 1 after the call to rcv_buf() in si_cs_send() to notify the caller some processing may be triggered. This patch is not flagged as a bug because no strange behaviour was yet observed without it. It is just a proactive fix to be consistent.
2018-11-20 03:34:35 -05:00
return 1;
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
}
CLEANUP: stream_interface: cleanup loop information in si_conn_send_loop() Though si_conn_send_loop() does not loop over ->snd_buf() after commit ed7f836, there is still some codes left which use `while` but only execute once. This commit does the cleanup job and rename si_conn_send_loop() to si_conn_send(). Signed-off-by: Godbach <nylzhaowei@gmail.com>
2013-10-11 03:48:29 -04:00
}
MINOR: stream-int: remove useless checks on CS and conn flags in si_cs_send() In si_cs_send(), some checks are done the CS flags en the connection flags before calling snd_buf(). But these checks are useless because they have already been done earlier in the function. The harder to figure out is the flag CO_FL_SOCK_WR_SH. So it is now tested with CF_SHUTW at the beginning.
2018-11-20 04:30:02 -05:00
BUG/MEDIUM: stream-int: make failed splice_in always subscribe to recv As part of the changes that went into 1.9-dev2 regarding the polling modifications, the changes consecutive to the removal of the wait_list from the conn_streams (commit 71384551a) made si_cs_recv() occasionally return without subscribing to receive events, causing spliced transfers to randomly fail if the client was at least as fast as the server. This may remain unnoticed on most deployments since servers are usually close to haproxy with higher bandwidth than clients have, resulting in buffers always being full. In order to reproduce his effect, it is better to do it on the local machine and to transfer very large objects (hundreds of gigs) over a single connection, to see it suddenly stall after a few tens of gigs. Now with this fix it's fine even after 3 TB over a single connection. No backport is needed.
2018-11-15 08:33:05 -05:00
end:
MEDIUM: connections/mux: Revamp the send direction. Totally nuke the "send" method, instead, the upper layer decides when it's time to send data, and if it's not possible, uses the new subscribe() method to be called when it can send data again.
2018-07-17 12:49:38 -04:00
/* We couldn't send all of our data, let the mux know we'd like to send more */
BUG/MEDIUM: stream-int: convert some co_data() checks to channel_is_empty() Splicing was in great part broken over the last few development version due to the use of co_data() to detect if data are available in the channel. But co_data() only looks at buffered data, not spliced data. Channel_is_empty() takes care of both and should be used. With this, splicing restarts to work but there are still a few cases where transfers may stall. No backport is needed.
2018-11-12 12:48:52 -05:00
if (!channel_is_empty(oc))
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
conn->mux->subscribe(cs, SUB_RETRY_SEND, &si->wait_event);
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
return did_send;
MAJOR: connection: split the send call into connection and stream interface Similar to what was done on the receive path, the data layer now provides only an snd_buf() callback that is iterated over by the stream interface's si_conn_send_loop() function. The data layer now has no knowledge about channels nor stream interfaces. The splice() code still need to be ported as it currently is disabled.
2012-08-21 12:22:06 -04:00
}
CLEANUP: stream-int: retro-document si_cs_io_cb() It took me 17 minutes this morning to figure where si->wait_event was set (it's in si_reset() which should now probably be renamed since it doesn't just perform a reset anymore but also an allocation) and what its task was assigned to (si_cs_io_cb() even for applets and empty SI). This is too confusing and not intuitive enough, let's at least add a few comments for now to help figure how this stuff works next time.
2018-11-07 01:47:52 -05:00
/* This is the ->process() function for any stream-interface's wait_event task.
* It's assigned during the stream-interface's initialization, for any type of
* stream interface. Thus it is always safe to perform a tasklet_wakeup() on a
* stream interface, as the presence of the CS is checked there.
*/
MINOR: stream_interface: Don't use si_cs_send() as a task handler. Instead of using si_cs_send() as a task handler, define a new function, si_cs_io_cb(), and give si_cs_send() its original prototype. Right now si_cs_io_cb() just handles send, but later it'll handle recv() too.
2018-08-02 12:06:28 -04:00
struct task *si_cs_io_cb(struct task *t, void *ctx, unsigned short state)
{
MINOR: stream_interface: Give stream_interface its own wait_list. Instead of just using the conn_stream wait_list, give the stream_interface its own. When the conn_stream will have its own buffers, the stream_interface may have to wait on it.
2018-08-02 12:21:38 -04:00
struct stream_interface *si = ctx;
BUG/MEDIUM: stream-int: Check if the conn_stream exist in si_cs_io_cb. It is possible that the conn_stream gets detached from the stream_interface, and as it subscribed to the wait list, si_cs_io_cb() gets called anyway, so make sure we have a conn_stream before attempting to send more data. This is 1.9-specific, no backport is needed.
2018-08-21 09:59:43 -04:00
struct conn_stream *cs = objt_cs(si->end);
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
int ret = 0;
BUG/MEDIUM: stream-int: Check if the conn_stream exist in si_cs_io_cb. It is possible that the conn_stream gets detached from the stream_interface, and as it subscribed to the wait list, si_cs_io_cb() gets called anyway, so make sure we have a conn_stream before attempting to send more data. This is 1.9-specific, no backport is needed.
2018-08-21 09:59:43 -04:00
if (!cs)
return NULL;
CLEANUP: stream-int: retro-document si_cs_io_cb() It took me 17 minutes this morning to figure where si->wait_event was set (it's in si_reset() which should now probably be renamed since it doesn't just perform a reset anymore but also an allocation) and what its task was assigned to (si_cs_io_cb() even for applets and empty SI). This is too confusing and not intuitive enough, let's at least add a few comments for now to help figure how this stuff works next time.
2018-11-07 01:47:52 -05:00
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (!(si->wait_event.events & SUB_RETRY_SEND) && !channel_is_empty(si_oc(si)))
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
ret = si_cs_send(cs);
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (!(si->wait_event.events & SUB_RETRY_RECV))
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
ret |= si_cs_recv(cs);
if (ret != 0)
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
si_cs_process(cs);
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
MINOR: stream_interface: Don't use si_cs_send() as a task handler. Instead of using si_cs_send() as a task handler, define a new function, si_cs_io_cb(), and give si_cs_send() its original prototype. Right now si_cs_io_cb() just handles send, but later it'll handle recv() too.
2018-08-02 12:06:28 -04:00
return (NULL);
}
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
/* This function is designed to be called from within the stream handler to
* update the channels' expiration timers and the stream interface's flags
* based on the channels' flags. It needs to be called only once after the
* channels' flags have settled down, and before they are cleared, though it
* doesn't harm to call it as often as desired (it just slightly hurts
* performance). It must not be called from outside of the stream handler,
* as what it does will be used to compute the stream task's expiration.
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
void si_update(struct stream_interface *si)
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
{
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
if (!(ic->flags & CF_SHUTR)) {
/* Read not closed, update FD status and timeout for reads */
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (ic->flags & CF_DONT_READ)
si_rx_chan_blk(si);
else
si_rx_chan_rdy(si);
if (!channel_is_empty(ic)) {
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
/* stop reading, imposed by channel's policy or contents */
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_blk(si);
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
}
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
else {
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
/* (re)start reading and update timeout. Note: we don't recompute the timeout
* everytime we get here, otherwise it would risk never to expire. We only
* update it if is was not yet set. The stream socket handler will already
* have updated it if there has been a completed I/O.
*/
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_rdy(si);
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
}
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (si->flags & SI_FL_RXBLK_ANY & ~SI_FL_RX_WAIT_EP)
ic->rex = TICK_ETERNITY;
else if (!(ic->flags & CF_READ_NOEXP) && !tick_isset(ic->rex))
ic->rex = tick_add_ifset(now_ms, ic->rto);
MEDIUM: stream-int: unconditionally call si_chk_rcv() in update and notify For a long time, stream_int_update() and stream_int_notify() used to only conditionally call si_chk_rcv() based on state change detection. This detection is not reliable and quite complex. With the new blocked flags that si_chk_rcv() checks, it's much more reliable to always call the function to take into account recent changes,and let it decide if it needs to wake something up or not. This also removes the calls to si_chk_rcv() that were performed in si_update_both() since these ones are systematically performed in stream_int_update() after updating the Rx flags.
2018-11-15 01:46:57 -05:00
si_chk_rcv(si);
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
}
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
else
si_rx_shut_blk(si);
MINOR: stream-int: implement a new stream_int_update() function This function is designed to be called from within the stream handler to update the channels' expiration timers and the stream interface's flags based on the channels' flags. It needs to be called only once after the channels' flags have settled down, and before they are cleared, though it doesn't harm to call it as often as desired (it just slightly hurts performance). It must not be called from outside of the stream handler, as what it does will be used to compute the stream task's expiration. The code was taken directly from stream_int_update_applet() and stream_int_update_conn() which had exactly the same one except for applet-specific or connection-specific status update.
2015-09-24 05:32:22 -04:00
if (!(oc->flags & CF_SHUTW)) {
/* Write not closed, update FD status and timeout for writes */
if (channel_is_empty(oc)) {
/* stop writing */
if (!(si->flags & SI_FL_WAIT_DATA)) {
if ((oc->flags & CF_SHUTW_NOW) == 0)
si->flags |= SI_FL_WAIT_DATA;
oc->wex = TICK_ETERNITY;
}
}
else {
/* (re)start writing and update timeout. Note: we don't recompute the timeout
* everytime we get here, otherwise it would risk never to expire. We only
* update it if is was not yet set. The stream socket handler will already
* have updated it if there has been a completed I/O.
*/
si->flags &= ~SI_FL_WAIT_DATA;
if (!tick_isset(oc->wex)) {
oc->wex = tick_add_ifset(now_ms, oc->wto);
if (tick_isset(ic->rex) && !(si->flags & SI_FL_INDEP_STR)) {
/* Note: depending on the protocol, we don't know if we're waiting
* for incoming data or not. So in order to prevent the socket from
* expiring read timeouts during writes, we refresh the read timeout,
* except if it was already infinite or if we have explicitly setup
* independent streams.
*/
ic->rex = tick_add_ifset(now_ms, ic->rto);
}
}
}
}
}
MINOR: stream-int: replace si_update() with si_update_both() The function used to be called in turn for each side of the stream, but since it's called exclusively from process_stream(), it prevents us from making use of the knowledge we have of the operations in progress for each side, resulting in having to go all the way through functions like stream_int_notify() which are not appropriate there. That patch creates a new function, si_update_both() which takes two stream interfaces expected to belong to the same stream, and processes their flags in a more suitable order, but for now doesn't change the logic at all. The next step will consist in trying to reinsert the rest of the socket layer-specific update code to ultimately update the flags correctly at the end of the operation.
2018-11-08 12:15:29 -05:00
/* updates both stream ints of a same stream at once */
/* Updates at once the channel flags, and timers of both stream interfaces of a
* same stream, to complete the work after the analysers, then updates the data
* layer below. This will ensure that any synchronous update performed at the
* data layer will be reflected in the channel flags and/or stream-interface.
*/
void si_update_both(struct stream_interface *si_f, struct stream_interface *si_b)
{
struct channel *req = si_ic(si_f);
struct channel *res = si_oc(si_f);
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
struct conn_stream *cs;
MINOR: stream-int: replace si_update() with si_update_both() The function used to be called in turn for each side of the stream, but since it's called exclusively from process_stream(), it prevents us from making use of the knowledge we have of the operations in progress for each side, resulting in having to go all the way through functions like stream_int_notify() which are not appropriate there. That patch creates a new function, si_update_both() which takes two stream interfaces expected to belong to the same stream, and processes their flags in a more suitable order, but for now doesn't change the logic at all. The next step will consist in trying to reinsert the rest of the socket layer-specific update code to ultimately update the flags correctly at the end of the operation.
2018-11-08 12:15:29 -05:00
req->flags &= ~(CF_READ_NULL|CF_READ_PARTIAL|CF_READ_ATTACHED|CF_WRITE_NULL|CF_WRITE_PARTIAL);
res->flags &= ~(CF_READ_NULL|CF_READ_PARTIAL|CF_READ_ATTACHED|CF_WRITE_NULL|CF_WRITE_PARTIAL);
si_f->prev_state = si_f->state;
si_b->prev_state = si_b->state;
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
/* front stream-int */
cs = objt_cs(si_f->end);
if (cs &&
si_f->state == SI_ST_EST &&
!(res->flags & CF_SHUTW) && /* Write not closed */
!channel_is_empty(res) &&
!(cs->flags & CS_FL_ERROR) &&
!(cs->conn->flags & CO_FL_ERROR)) {
if (si_cs_send(cs))
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_rdy(si_b);
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
}
/* back stream-int */
cs = objt_cs(si_b->end);
if (cs &&
(si_b->state == SI_ST_EST || si_b->state == SI_ST_CON) &&
!(req->flags & CF_SHUTW) && /* Write not closed */
!channel_is_empty(req) &&
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
!(cs->flags & (CS_FL_ERROR|CS_FL_ERR_PENDING)) &&
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
!(cs->conn->flags & CO_FL_ERROR)) {
if (si_cs_send(cs))
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_rdy(si_f);
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
}
/* let's recompute both sides states */
if (si_f->state == SI_ST_EST)
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
si_update(si_f);
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
if (si_b->state == SI_ST_EST)
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
si_update(si_b);
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
/* stream ints are processed outside of process_stream() and must be
* handled at the latest moment.
*/
if (obj_type(si_f->end) == OBJ_TYPE_APPCTX &&
MINOR: stream-int: use si_rx_blocked()/si_tx_blocked() to check readiness This way we don't limit ourselves to random flags only and the code is more readable and safer for the long term.
2018-11-14 08:07:59 -05:00
((si_rx_endp_ready(si_f) && !si_rx_blocked(si_f)) ||
(si_tx_endp_ready(si_f) && !si_tx_blocked(si_f))))
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
appctx_wakeup(si_appctx(si_f));
if (obj_type(si_b->end) == OBJ_TYPE_APPCTX &&
MINOR: stream-int: use si_rx_blocked()/si_tx_blocked() to check readiness This way we don't limit ourselves to random flags only and the code is more readable and safer for the long term.
2018-11-14 08:07:59 -05:00
((si_rx_endp_ready(si_b) && !si_rx_blocked(si_b)) ||
(si_tx_endp_ready(si_b) && !si_tx_blocked(si_b))))
MEDIUM: stream-int: make stream_int_update() aware of the lower layers It's far from being clean, but at least it allows to resync both CS and applets from the same place, taking into account the fact that CS are processed synchronously for the send side while appletx are processed outside of the process_stream() loop. The arrangement is optimised to minimize the amount of iteration by handling send first, then updating the SI_FL_WAIT_ROOM flags and only then dealing with si_chk_rcv() on both sides. The SI_FL_WANT_PUT flag is set if needed before calling si_chk_rcv() since this is done prior to calling stream_int_update(). Now there's no risk that stream_int_notify() is called anymore during such operations, thus we cannot have any spurious wake-up anymore. The case where a successful send() could complete a pending connect() is handled by taking any stream-int state changes into account at the call place, which is normal since process_stream() is designed to iterate till stabilisation. Doing this solves most of the remaining inconsistencies between CS and applets.
2018-11-09 08:59:25 -05:00
appctx_wakeup(si_appctx(si_b));
MINOR: stream-int: replace si_update() with si_update_both() The function used to be called in turn for each side of the stream, but since it's called exclusively from process_stream(), it prevents us from making use of the knowledge we have of the operations in progress for each side, resulting in having to go all the way through functions like stream_int_notify() which are not appropriate there. That patch creates a new function, si_update_both() which takes two stream interfaces expected to belong to the same stream, and processes their flags in a more suitable order, but for now doesn't change the logic at all. The next step will consist in trying to reinsert the rest of the socket layer-specific update code to ultimately update the flags correctly at the end of the operation.
2018-11-08 12:15:29 -05:00
}
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
/*
* This function performs a shutdown-read on a stream interface attached to
* a connection in a connected or init state (it does nothing for other
* states). It either shuts the read side or marks itself as closed. The buffer
* flags are updated to reflect the new state. If the stream interface has
* SI_FL_NOHALF, we also forward the close to the write side. If a control
* layer is defined, then it is supposed to be a socket layer and file
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
* descriptors are then shutdown or closed accordingly. The function
* automatically disables polling if needed.
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
*/
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutr_conn(struct stream_interface *si)
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04: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 12:30:23 -04:00
struct conn_stream *cs = __objt_cs(si->end);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si_rx_shut_blk(si);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->flags & CF_SHUTR)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
if (si->state != SI_ST_EST && si->state != SI_ST_CON)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection This is the equivalent of SI_FL_KILL_CONN but for the connstreams. It will be set by the stream-interface during the various shutdown operations.
2019-01-31 13:09:59 -05:00
if (si->flags & SI_FL_KILL_CONN)
cs->flags |= CS_FL_KILL_CONN;
REORG/MEDIUM: stream-int: introduce si_ic/si_oc to access channels We'll soon remove direct references to the channels from the stream interface since everything belongs to the same session, so let's first not dereference si->ib / si->ob anymore and use macros instead.
2014-11-28 05:11:05 -05:00
if (si_oc(si)->flags & CF_SHUTW) {
MEDIUM: connection: replace conn_full_close() with cs_close() At all call places where a conn_stream is in use, we can now use cs_close() to get rid of a conn_stream and of its underlying connection if the mux estimates it makes sense. This is what is currently being done for the pass-through mux.
2017-10-05 12:52:17 -04:00
cs_close(cs);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
si->state = SI_ST_DIS;
si->exp = TICK_ETERNITY;
}
else if (si->flags & SI_FL_NOHALF) {
/* we want to immediately forward this close to the write side */
return stream_int_shutw_conn(si);
}
}
/*
* This function performs a shutdown-write on a stream interface attached to
* a connection in a connected or init state (it does nothing for other
* states). It either shuts the write side or marks itself as closed. The
* buffer flags are updated to reflect the new state. It does also close
* everything if the SI was marked as being in error state. If there is a
MEDIUM: stream-int: replace xprt->shutw calls with conn_data_shutw() Now that the connection performs the correct controls when shutting down, use that in the few places where conn->xprt->shutw() was called. The calls were split between conn_data_shutw() and conn_data_shutw_hard() depending on the argument. Since the connection flags are updated, we don't need to call conn_data_stop_send() anymore, instead we just have to call conn_cond_update_polling().
2015-03-12 18:04:07 -04:00
* data-layer shutdown, it is called.
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
*/
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
static void stream_int_shutw_conn(struct stream_interface *si)
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04: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 12:30:23 -04:00
struct conn_stream *cs = __objt_cs(si->end);
struct connection *conn = cs->conn;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags &= ~CF_SHUTW_NOW;
if (oc->flags & CF_SHUTW)
MINOR: stream-int: make the shutr/shutw functions void This is to be more consistent with the other functions. The only reason why these functions used to return a value was to let the caller adjust polling by itself, but now their only callers were the si_shutr()/si_shutw() inline functions. Now these functions do not depend anymore on the connection. These connection variant of these functions now call conn_data_stop_recv()/conn_data_stop_send() before returning order not to require a return code anymore. The applet version does not need this at all.
2013-09-29 09:16:03 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags |= CF_SHUTW;
oc->wex = TICK_ETERNITY;
MINOR: stream-int: make use of si_done_{get,put}() in shut{w,r} It's cleaner to use these functions there to properly clear the flags.
2018-11-06 13:23:03 -05:00
si_done_get(si);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
BUG/MEDIUM: stream: fix client-fin/server-fin handling A tcp half connection can cause 100% CPU on expiration. First reproduced with this haproxy configuration : global tune.bufsize 10485760 defaults timeout server-fin 90s timeout client-fin 90s backend node2 mode tcp timeout server 900s timeout connect 10s server def 127.0.0.1:3333 frontend fe_api mode tcp timeout client 900s bind :1990 use_backend node2 Ie timeout server-fin shorter than timeout server, the backend server sends data, this package is left in the cache of haproxy, the backend server continue sending fin package, haproxy recv fin package. this time the session information is as follows: time the session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=1s calls=3 rq[f=848000h,i=0,an=00h,rx=14m58s,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=,wx=14m58s,ax=] s0=[7,0h,fd=6,ex=] s1=[7,18h,fd=7,ex=] exp=14m58s rp has set the CF_SHUTR state, next, the client sends the fin package, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=38s calls=4 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=1m11s,wx=14m21s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=1m11s After waiting 90s, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=04 age=4m11s calls=718074391 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=?,wx=10m49s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=? run(nice=0) cpu information: 6899 root 20 0 112224 21408 4260 R 100.0 0.7 3:04.96 haproxy Buffering is set to ensure that there is data in the haproxy buffer, and haproxy can receive the fin package, set the CF_SHUTR flag, If the CF_SHUTR flag has been set, The following code does not clear the timeout message, causing cpu 100%: stream.c:process_stream: if (unlikely((res->flags & (CF_SHUTR|CF_READ_TIMEOUT)) == CF_READ_TIMEOUT)) { if (si_b->flags & SI_FL_NOHALF) si_b->flags |= SI_FL_NOLINGER; si_shutr(si_b); } If you have closed the read, set the read timeout does not make sense. With or without cf_shutr, read timeout is set: if (tick_isset(s->be->timeout.serverfin)) { res->rto = s->be->timeout.serverfin; res->rex = tick_add(now_ms, res->rto); } After discussion on the mailing list, setting half-closed timeouts the hard way here doesn't make sense. They should be set only at the moment the shutdown() is performed. It will also solve a special case which was already reported of some half-closed timeouts not working when the shutw() is performed directly at the stream-interface layer (no analyser involved). Since the stream interface layer cannot know the timeout values, we'll have to store them directly in the stream interface so that they are used upon shutw(). This patch does this, fixing the problem. An easier reproducer to validate the fix is to keep the huge buffer and shorten all timeouts, then call it under tcploop server and client, and wait 3 seconds to see haproxy run at 100% CPU : global tune.bufsize 10485760 listen px bind :1990 timeout client 90s timeout server 90s timeout connect 1s timeout server-fin 3s timeout client-fin 3s server def 127.0.0.1:3333 $ tcploop 3333 L W N20 A P100 F P10000 & $ tcploop 127.0.0.1:1990 C S10000000 F
2017-03-10 12:41:51 -05:00
if (tick_isset(si->hcto)) {
ic->rto = si->hcto;
ic->rex = tick_add(now_ms, ic->rto);
}
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
switch (si->state) {
case SI_ST_EST:
/* we have to shut before closing, otherwise some short messages
* may never leave the system, especially when there are remaining
* unread data in the socket input buffer, or when nolinger is set.
* However, if SI_FL_NOLINGER is explicitly set, we know there is
* no risk so we close both sides immediately.
*/
MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection This is the equivalent of SI_FL_KILL_CONN but for the connstreams. It will be set by the stream-interface during the various shutdown operations.
2019-01-31 13:09:59 -05:00
if (si->flags & SI_FL_KILL_CONN)
cs->flags |= CS_FL_KILL_CONN;
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
if (si->flags & SI_FL_ERR) {
/* quick close, the socket is alredy shut anyway */
}
else if (si->flags & SI_FL_NOLINGER) {
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
/* unclean data-layer shutdown, typically an aborted request
* or a forwarded shutdown from a client to a server due to
* option abortonclose. No need for the TLS layer to try to
* emit a shutdown message.
*/
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 09:25:48 -04:00
cs_shutw(cs, CS_SHW_SILENT);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
}
else {
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
/* clean data-layer shutdown. This only happens on the
* frontend side, or on the backend side when forwarding
* a client close in TCP mode or in HTTP TUNNEL mode
* while option abortonclose is set. We want the TLS
* layer to try to signal it to the peer before we close.
*/
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 09:25:48 -04:00
cs_shutw(cs, CS_SHW_NORMAL);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
MEDIUM: connection: replace conn_full_close() with cs_close() At all call places where a conn_stream is in use, we can now use cs_close() to get rid of a conn_stream and of its underlying connection if the mux estimates it makes sense. This is what is currently being done for the pass-through mux.
2017-10-05 12:52:17 -04:00
if (!(ic->flags & (CF_SHUTR|CF_DONT_READ))) {
/* OK just a shutw, but we want the caller
* to disable polling on this FD if exists.
*/
conn_cond_update_polling(conn);
return;
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
}
}
/* fall through */
case SI_ST_CON:
/* we may have to close a pending connection, and mark the
* response buffer as shutr
*/
MINOR: connstream: have a new flag CS_FL_KILL_CONN to kill a connection This is the equivalent of SI_FL_KILL_CONN but for the connstreams. It will be set by the stream-interface during the various shutdown operations.
2019-01-31 13:09:59 -05:00
if (si->flags & SI_FL_KILL_CONN)
cs->flags |= CS_FL_KILL_CONN;
MEDIUM: connection: replace conn_full_close() with cs_close() At all call places where a conn_stream is in use, we can now use cs_close() to get rid of a conn_stream and of its underlying connection if the mux estimates it makes sense. This is what is currently being done for the pass-through mux.
2017-10-05 12:52:17 -04:00
cs_close(cs);
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
/* fall through */
case SI_ST_CER:
case SI_ST_QUE:
case SI_ST_TAR:
si->state = SI_ST_DIS;
MAJOR: stream interface: remove the ->release function pointer Since last commit, we now have a pointer to the applet in the applet context. So we don't need the si->release function pointer anymore, it can be extracted from applet->applet.release. At many places, the ->release function was still tested for real connections while it is only limited to applets, so most of them were simply removed. For the remaining valid uses, a new inline function si_applet_release() was added to simplify the check and the call.
2013-10-24 14:10:45 -04:00
/* fall through */
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
default:
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si->flags &= ~SI_FL_NOLINGER;
si_rx_shut_blk(si);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
MEDIUM: stream-int: split the shutr/shutw functions between applet and conn These functions induce a lot of ifs everywhere because they consider two different cases, one which is where the connection exists and has a file descriptor, and the other one which is the default case where at most an applet has to be notified. Let's have them in si_ops and automatically decide which one to use. The connection shutdown sequence has been slightly simplified, and we now clear the flags at the end. Also we remove SHUTR_NOW after a shutw with nolinger, as it's cleaner not to keep it.
2013-09-29 08:51:58 -04:00
si->exp = TICK_ETERNITY;
}
}
MEDIUM: stream-interface: offer a generic chk_rcv function for connections sock_raw and sock_ssl use a pretty generic chk_rcv function, so let's move this function to the stream_interface and remove specific functions. Later we might have a single chk_rcv function.
2012-08-20 06:38:36 -04:00
/* This function is used for inter-stream-interface calls. It is called by the
* consumer to inform the producer side that it may be interested in checking
* for free space in the buffer. Note that it intentionally does not update
* timeouts, so that we can still check them later at wake-up. This function is
* dedicated to connection-based stream interfaces.
*/
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
static void stream_int_chk_rcv_conn(struct stream_interface *si)
MEDIUM: stream-interface: offer a generic chk_rcv function for connections sock_raw and sock_ssl use a pretty generic chk_rcv function, so let's move this function to the stream_interface and remove specific functions. Later we might have a single chk_rcv function.
2012-08-20 06:38:36 -04:00
{
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
/* (re)start reading */
BUG/MEDIUM: stream_interface: Don't bother doing chk_rcv/snd if not connected. If the interface is not in state SI_ST_CON or SI_ST_EST, don't bother trying to send/recv data, we can't do it anyway, and if we're in SI_ST_TAR, that may lead to adding the SI_FL_ERR flag back on the stream_interface, while we don't want it. This should be backported to 1.9.
2019-04-11 07:56:26 -04:00
if (si->state == SI_ST_CON || si->state == SI_ST_EST)
tasklet_wakeup(si->wait_event.task);
MEDIUM: stream-interface: offer a generic chk_rcv function for connections sock_raw and sock_ssl use a pretty generic chk_rcv function, so let's move this function to the stream_interface and remove specific functions. Later we might have a single chk_rcv function.
2012-08-20 06:38:36 -04:00
}
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
/* This function is used for inter-stream-interface calls. It is called by the
* producer to inform the consumer side that it may be interested in checking
* for data in the buffer. Note that it intentionally does not update timeouts,
* so that we can still check them later at wake-up.
*/
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
static void stream_int_chk_snd_conn(struct stream_interface *si)
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
{
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *oc = si_oc(si);
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
struct conn_stream *cs = __objt_cs(si->end);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
BUG/MEDIUM: stream_interface: Don't bother doing chk_rcv/snd if not connected. If the interface is not in state SI_ST_CON or SI_ST_EST, don't bother trying to send/recv data, we can't do it anyway, and if we're in SI_ST_TAR, that may lead to adding the SI_FL_ERR flag back on the stream_interface, while we don't want it. This should be backported to 1.9.
2019-04-11 07:56:26 -04:00
if (unlikely((si->state != SI_ST_CON && si->state != SI_ST_EST) ||
(oc->flags & CF_SHUTW)))
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (unlikely(channel_is_empty(oc))) /* called with nothing to send ! */
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (!oc->pipe && /* spliced data wants to be forwarded ASAP */
BUG/MINOR: stream_interface: don't return when the fd is already set Back in the days where polling was made with select() where all FDs were checked at once, stream_int_chk_snd_conn() used to check whether the file descriptor it was passed was ready or not, so that it did not perform the work for nothing. Right now FDs are checked just before calling the I/O handler so this test never matches at best, or may return false information at worst. Since conn_fd_handler() always clears the flags upon exit, it looks like a missed event cannot happen right now. Still, better remove this outdated check than wait for it to cause issues.
2012-12-15 04:12:39 -05:00
!(si->flags & SI_FL_WAIT_DATA)) /* not waiting for data */
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
return;
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (!(si->wait_event.events & SUB_RETRY_SEND) && !channel_is_empty(si_oc(si)))
MINOR: stream_interface: Avoid calling si_cs_send/recv if not needed. Don't bother calling si_cs_send and si_cs_recv if we're either already subscribe, or if the output buffer is empty for si_cs_send.
2018-10-22 10:01:09 -04:00
si_cs_send(cs);
MINOR: stream-int: don't needlessly call tasklet_wakeup() in stream_int_chk_snd_conn() This one was added by commit 53216e7db ("MEDIUM: connections: Don't directly mess with the polling from the upper layers.") after the removal of the conditional cs_want_send() call. But after analysis it turned out that it's not needed since the si_cs_send() call will either succeed or subscribe.
2018-10-25 07:49:49 -04:00
MEDIUM: stream-int: always consider all CS errors on the send side We still have an issue with asynchronous errors, which is that while they don't truncate reads anymore, they might be missed during a send() attempt. This can happen for example when processing a request followed by undesired data for which the stream doesn't try to receive, while the send side experiences an error (transfer aborted by the client). In this case we definitely want all send() attempts to fail as soon as the error was reported, even if it's only pending. This way we leave an opportunity to the stream interface to try to receive the last data pending in the buffer but it cannot send anymore and knows that there is an error when trying to do so.
2018-12-19 11:17:10 -05:00
if (cs->flags & (CS_FL_ERROR|CS_FL_ERR_PENDING) || cs->conn->flags & CO_FL_ERROR) {
MINOR: stream-int: stop checking for useless connection flags in chk_snd_conn We've been keep this test for a connection being established since 1.5-dev14 when the stream-interface was still accessing the FD directly. The test on CO_FL_HANDSHAKE and L{4,6}_CONN is totally useless here, and can even be counter-productive on pure TCP where it could prevent a request from being sent on a connection still attempting to complete its establishment. And it creates an abnormal dependency between the layers that will complicate the implementation of the mux, so let's get rid of it now.
2017-10-25 08:22:28 -04:00
/* Write error on the file descriptor */
si->flags |= SI_FL_ERR;
goto out_wakeup;
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
}
/* OK, so now we know that some data might have been sent, and that we may
* have to poll first. We have to do that too if the buffer is not empty.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (channel_is_empty(oc)) {
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
/* the connection is established but we can't write. Either the
* buffer is empty, or we just refrain from sending because the
* ->o limit was reached. Maybe we just wrote the last
* chunk and need to close.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (((oc->flags & (CF_SHUTW|CF_AUTO_CLOSE|CF_SHUTW_NOW)) ==
CLEANUP: channel: usr CF_/CHN_ prefixes instead of BF_/BUF_ Get rid of these confusing BF_* flags. Now channel naming should clearly be used everywhere appropriate. No code was changed, only a renaming was performed. The comments about channel operations was updated.
2012-08-27 17:14:58 -04:00
(CF_AUTO_CLOSE|CF_SHUTW_NOW)) &&
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
(si->state == SI_ST_EST)) {
si_shutw(si);
goto out_wakeup;
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if ((oc->flags & (CF_SHUTW|CF_SHUTW_NOW)) == 0)
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
si->flags |= SI_FL_WAIT_DATA;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->wex = TICK_ETERNITY;
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
}
else {
/* Otherwise there are remaining data to be sent in the buffer,
* which means we have to poll before doing so.
*/
si->flags &= ~SI_FL_WAIT_DATA;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (!tick_isset(oc->wex))
oc->wex = tick_add_ifset(now_ms, oc->wto);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (likely(oc->flags & CF_WRITE_ACTIVITY)) {
struct channel *ic = si_ic(si);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
/* update timeout if we have written something */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if ((oc->flags & (CF_SHUTW|CF_WRITE_PARTIAL)) == CF_WRITE_PARTIAL &&
!channel_is_empty(oc))
oc->wex = tick_add_ifset(now_ms, oc->wto);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (tick_isset(ic->rex) && !(si->flags & SI_FL_INDEP_STR)) {
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
/* Note: to prevent the client from expiring read timeouts
* during writes, we refresh it. We only do this if the
* interface is not configured for "independent streams",
* because for some applications it's better not to do this,
* for instance when continuously exchanging small amounts
* of data which can full the socket buffers long before a
* write timeout is detected.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->rex = tick_add_ifset(now_ms, ic->rto);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
}
}
/* in case of special condition (error, shutdown, end of write...), we
* have to notify the task.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (likely((oc->flags & (CF_WRITE_NULL|CF_WRITE_ERROR|CF_SHUTW)) ||
((oc->flags & CF_WAKE_WRITE) &&
((channel_is_empty(oc) && !oc->to_forward) ||
BUG/MEDIUM: stream-interface: don't wake the task up before end of transfer Recent commit d7ad9f5 ("MAJOR: channel: add a new flag CF_WAKE_WRITE to notify the task of writes") was not correct. It used to wake up the task as soon as there was some write activity and the flag was set, even if there were still some data to be forwarded. This resulted in process_session() being called a lot when transfering chunk-encoded HTTP responses made of very large chunks. The purpose of the flag is to wake up only a task waiting for some room and not the other ones, so it's totally counter-productive to wake it up as long as there are data to forward because the task will not be allowed to write anyway. Also, the commit above was taking some risks by not considering certain events anymore (eg: state != SI_ST_EST). While such events are not used at the moment, if some new features were developped in the future relying on these, it would be better that they could be notified when subscribing to the WAKE_WRITE event, so let's restore the condition.
2014-01-24 20:33:21 -05:00
si->state != SI_ST_EST)))) {
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
out_wakeup:
MEDIUM: stream-int: use si_task() to retrieve the task from the stream int We go back to the session to get the owner. Here again it's very easy and is just a matter of relative offsets. Since the owner always exists and always points to the session's task, we can remove some unneeded tests.
2014-11-28 06:08:47 -05:00
if (!(si->flags & SI_FL_DONT_WAKE))
task_wakeup(si_task(si), TASK_WOKEN_IO);
MEDIUM: stream-interface: provide a generic stream_int_chk_snd_conn() function This one can be used by both sock_raw and sock_ssl instead of each having their own.
2012-08-20 09:01:10 -04:00
}
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/*
* This is the callback which is called by the connection layer to receive data
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
* into the buffer from the connection. It iterates over the mux layer's
REORG: connection: rename the data layer the "transport layer" While working on the changes required to make the health checks use the new connections, it started to become obvious that some naming was not logical at all in the connections. Specifically, it is not logical to call the "data layer" the layer which is in charge for all the handshake and which does not yet provide a data layer once established until a session has allocated all the required buffers. In fact, it's more a transport layer, which makes much more sense. The transport layer offers a medium on which data can transit, and it offers the functions to move these data when the upper layer requests this. And it is the upper layer which iterates over the transport layer's functions to move data which should be called the data layer. The use case where it's obvious is with embryonic sessions : an incoming SSL connection is accepted. Only the connection is allocated, not the buffers nor stream interface, etc... The connection handles the SSL handshake by itself. Once this handshake is complete, we can't use the data functions because the buffers and stream interface are not there yet. Hence we have to first call a specific function to complete the session initialization, after which we'll be able to use the data functions. This clearly proves that SSL here is only a transport layer and that the stream interface constitutes the data layer. A similar change will be performed to rename app_cb => data, but the two could not be in the same commit for obvious reasons.
2012-10-02 18:19:48 -04:00
* rcv_buf function.
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
*/
BUG/MEDIUM: process_stream: Don't use si_cs_io_cb() in process_stream(). Instead of using si_cs_io_cb() in process_stream() use si_cs_send/si_cs_recv instead, as si_cs_io_cb() may lead to process_stream being woken up when it shouldn't be, and thus timeout would never get triggered.
2018-09-14 13:41:13 -04:00
int si_cs_recv(struct conn_stream *cs)
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04: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 12:30:23 -04:00
struct connection *conn = cs->conn;
struct stream_interface *si = cs->data;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
int ret, max, cur_read = 0;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
int read_poll = MAX_READ_POLL_LOOPS;
MINOR: conn_stream: Add a flag to notify the mux it should flush its buffers By setting the flag CO_RFL_BUF_FLUSH when calling mux->rcv_buf, the stream-interface notifies the mux it should flush its buffers without reading more data. This flag is set when the SI want to use the kernel TCP splicing to forward data. Of course, the mux can respect it or not, depending on its state. It's just an information.
2018-10-11 09:56:04 -04:00
int flags = 0;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
/* If another call to si_cs_recv() failed, and we subscribed to
* recv events already, give up now.
*/
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
if (si->wait_event.events & SUB_RETRY_RECV)
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
return 0;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/* maybe we were called immediately after an asynchronous shutr */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->flags & CF_SHUTR)
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04: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 01:35:35 -04:00
/* stop here if we reached the end of data */
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
if (cs->flags & CS_FL_EOS)
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 01:35:35 -04:00
goto out_shutdown_r;
BUG/MINOR: stream-int: Process read0 even if no data was received in si_cs_recv The flag CS_FL_EOS can be set while no data was received. So the flas CS_FL_RCV_MORE is not set. In this case, the read0 was never processed by the stream interface. To be sure to process it, the test on CS_FL_RCV_MORE has been moved after the one on CS_FL_EOS.
2018-12-07 08:51:20 -05:00
/* stop immediately on errors. Note that we DON'T want to stop on
* POLL_ERR, as the poller might report a write error while there
* are still data available in the recv buffer. This typically
* happens when we send too large a request to a backend server
* which rejects it before reading it all.
*/
if (!(cs->flags & CS_FL_RCV_MORE)) {
if (!conn_xprt_ready(conn))
return 0;
if (conn->flags & CO_FL_ERROR || cs->flags & CS_FL_ERROR)
return 1; // We want to make sure si_cs_wake() is called, so that process_strema is woken up, on failure
}
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
BUG/MEDIUM: stream-int: always clear CS_FL_WANT_ROOM before receiving Commit d94f877cd ("BUG/MINOR: mux_pt: Set CS_FL_WANT_ROOM when count is zero in rcv_buf() callback") triggered a pending issue with this flag, which is that it's cleared too late and sometimes causes some Rx transfers to stall. We need to clear it before attempting to receive otherwise we may risk to see an earlier copy of the flag. Note that it should probably be defined that this flag could be purged on each invocation of mux->rcv_buf(), which would make sense. No backport is needed.
2018-12-18 03:15:43 -05:00
/* prepare to detect if the mux needs more room */
cs->flags &= ~CS_FL_WANT_ROOM;
MINOR: stream-int: use the new buffer API A few locations still accessing ->i and ->o directly were changed to use ci_data() and co_data() respectively. A call to b_del() was replaced with co_set_data() in si_cs_send() so that ->o will is automatically be decremented after the migration.
2018-06-19 01:03:14 -04:00
if ((ic->flags & (CF_STREAMER | CF_STREAMER_FAST)) && !co_data(ic) &&
MINOR: config: make the stream interface idle timer user-configurable The new tune.idletimer value allows one to set a different value for idle stream detection. The default value remains set to one second. It is possible to disable it using zero, and to change the default value at build time using DEFAULT_IDLE_TIMER.
2014-02-12 10:35:14 -05:00
global.tune.idle_timer &&
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
(unsigned short)(now_ms - ic->last_read) >= global.tune.idle_timer) {
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
/* The buffer was empty and nothing was transferred for more
* than one second. This was caused by a pause and not by
* congestion. Reset any streaming mode to reduce latency.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->xfer_small = 0;
ic->xfer_large = 0;
ic->flags &= ~(CF_STREAMER | CF_STREAMER_FAST);
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
/* First, let's see if we may splice data across the channel without
* using a buffer.
*/
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
if (conn->xprt->rcv_pipe && conn->mux->rcv_pipe &&
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
(ic->pipe || ic->to_forward >= MIN_SPLICE_FORWARD) &&
ic->flags & CF_KERN_SPLICING) {
MINOR: buffer: replace buffer_not_empty() with b_data() or c_data() It's mostly for consistency as many places already use one of these instead.
2018-07-10 03:50:25 -04:00
if (c_data(ic)) {
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
/* We're embarrassed, there are already data pending in
* the buffer and we don't want to have them at two
* locations at a time. Let's indicate we need some
* place and ask the consumer to hurry.
*/
MINOR: conn_stream: Add a flag to notify the mux it should flush its buffers By setting the flag CO_RFL_BUF_FLUSH when calling mux->rcv_buf, the stream-interface notifies the mux it should flush its buffers without reading more data. This flag is set when the SI want to use the kernel TCP splicing to forward data. Of course, the mux can respect it or not, depending on its state. It's just an information.
2018-10-11 09:56:04 -04:00
flags |= CO_RFL_BUF_FLUSH;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
goto abort_splice;
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (unlikely(ic->pipe == NULL)) {
if (pipes_used >= global.maxpipes || !(ic->pipe = get_pipe())) {
ic->flags &= ~CF_KERN_SPLICING;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
goto abort_splice;
}
}
MAJOR: connection : Split struct connection into struct connection and struct conn_stream. All the references to connections in the data path from streams and stream_interfaces were changed to use conn_streams. Most functions named "something_conn" were renamed to "something_cs" for this. Sometimes the connection still is what matters (eg during a connection establishment) and were not always renamed. The change is significant and minimal at the same time, and was quite thoroughly tested now. As of this patch, all accesses to the connection from upper layers go through the pass-through mux.
2017-09-13 12:30:23 -04:00
ret = conn->mux->rcv_pipe(cs, ic->pipe, ic->to_forward);
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
if (ret < 0) {
/* splice not supported on this end, let's disable it */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags &= ~CF_KERN_SPLICING;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
goto abort_splice;
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
if (ret > 0) {
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->to_forward != CHN_INFINITE_FORWARD)
ic->to_forward -= ret;
ic->total += ret;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
cur_read += ret;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_READ_PARTIAL;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
}
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04: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 12:30:23 -04:00
if (cs->flags & CS_FL_EOS)
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
goto out_shutdown_r;
MINOR: connection: make conn_stream users also check for per-stream error flag In a 1:1 connection:stream there's no problem relying on the connection flags alone to check for errors. But in a mux, it will be possible to mark certain streams in error without having to mark all of them. An example is an H2 client sending RST_STREAM frames to abort a long download, or a parse error requiring to abort only this specific stream. This commit ensures that stream-interface and checks properly check for CS_FL_ERROR in cs->flags wherever CO_FL_ERROR was in use. Most likely over the long term, any check for CO_FL_ERROR will have to disappear.
2017-10-16 09:17:17 -04:00
if (conn->flags & CO_FL_ERROR || cs->flags & CS_FL_ERROR)
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
BUG/MEDIUM: splicing: fix abnormal CPU usage with splicing Mark Janssen reported an issue in 1.5-dev19 which was introduced in 1.5-dev12 by commit 96199b10. From time to time, randomly, the CPU usage spikes to 100% for seconds to minutes. A deep analysis of the traces provided shows that it happens when waiting for the response to a second pipelined HTTP request, or when trying to handle the received shutdown advertised by epoll() after the last block of data. Each time, splice() was involved with data pending in the pipe. The cause of this was that such events could not be taken into account by splice nor by recv and were left pending : - the transfer of the last block of data, optionally with a shutdown was not handled by splice() because of the validation that to_forward is higher than MIN_SPLICE_FORWARD ; - the next recv() call was inhibited because of the test on presence of data in the pipe. This is also what prevented the recv() call from handling a response to a pipelined request until the client had ACKed the previous response. No less than 4 different methods were experimented to fix this, and the current one was finally chosen. The principle is that if an event is not caught by splice(), then it MUST be caught by recv(). So we remove the condition on the pipe's emptiness to perform an recv(), and in order to prevent recv() from being used in the middle of a transfer, we mark supposedly full pipes with CO_FL_WAIT_ROOM, which makes sense because the reason for stopping a splice()-based receive is that the pipe is supposed to be full. The net effect is that we don't wake up and sleep in loops during these transient states. This happened much more often than expected, sometimes for a few cycles at end of transfers, but rarely long enough to be noticed, unless a client timed out with data pending in the pipe. The effect on CPU usage is visible even when transfering 1MB objects in pipeline, where the CPU usage drops from 10 to 6% on a small machine at medium bandwidth. Some further improvements are needed : - the last chunk of a splice() transfer is never done using splice due to the test on to_forward. This is wrong and should be performed with splice if the pipe has not yet been emptied ; - si_chk_snd() should not be called when the write event is already being polled, otherwise we're almost certain to get EAGAIN. Many thanks to Mark for all the traces he cared to provide, they were essential for understanding this issue which was not reproducible without. Only 1.5-dev is affected, no backport is needed.
2013-07-18 15:49:32 -04:00
if (conn->flags & CO_FL_WAIT_ROOM) {
/* the pipe is full or we have read enough data that it
* could soon be full. Let's stop before needing to poll.
*/
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_blk(si);
BUG/MINOR: stream-int: make sure not to go through the rcv_buf path after splice() When splice() reports a pipe full condition, we go through the common code used to release a possibly empty pipe (which we don't have) and which immediately tries to allocate a buffer that will never be used. Further, it may even subscribe to get this buffer if the resources are low. Let's simply get out of this way if the pipe is full. This fix could be backported to 1.8 though the code is a bit different overthere.
2018-11-15 10:06:02 -05:00
goto done_recv;
BUG/MEDIUM: splicing: fix abnormal CPU usage with splicing Mark Janssen reported an issue in 1.5-dev19 which was introduced in 1.5-dev12 by commit 96199b10. From time to time, randomly, the CPU usage spikes to 100% for seconds to minutes. A deep analysis of the traces provided shows that it happens when waiting for the response to a second pipelined HTTP request, or when trying to handle the received shutdown advertised by epoll() after the last block of data. Each time, splice() was involved with data pending in the pipe. The cause of this was that such events could not be taken into account by splice nor by recv and were left pending : - the transfer of the last block of data, optionally with a shutdown was not handled by splice() because of the validation that to_forward is higher than MIN_SPLICE_FORWARD ; - the next recv() call was inhibited because of the test on presence of data in the pipe. This is also what prevented the recv() call from handling a response to a pipelined request until the client had ACKed the previous response. No less than 4 different methods were experimented to fix this, and the current one was finally chosen. The principle is that if an event is not caught by splice(), then it MUST be caught by recv(). So we remove the condition on the pipe's emptiness to perform an recv(), and in order to prevent recv() from being used in the middle of a transfer, we mark supposedly full pipes with CO_FL_WAIT_ROOM, which makes sense because the reason for stopping a splice()-based receive is that the pipe is supposed to be full. The net effect is that we don't wake up and sleep in loops during these transient states. This happened much more often than expected, sometimes for a few cycles at end of transfers, but rarely long enough to be noticed, unless a client timed out with data pending in the pipe. The effect on CPU usage is visible even when transfering 1MB objects in pipeline, where the CPU usage drops from 10 to 6% on a small machine at medium bandwidth. Some further improvements are needed : - the last chunk of a splice() transfer is never done using splice due to the test on to_forward. This is wrong and should be performed with splice if the pipe has not yet been emptied ; - si_chk_snd() should not be called when the write event is already being polled, otherwise we're almost certain to get EAGAIN. Many thanks to Mark for all the traces he cared to provide, they were essential for understanding this issue which was not reproducible without. Only 1.5-dev is affected, no backport is needed.
2013-07-18 15:49:32 -04:00
}
MEDIUM: connection: complete the polling cleanups I/O handlers now all use __conn_{sock,data}_{stop,poll,want}_* instead of returning dummy flags. The code has become slightly simpler because some tricks such as the MIN_RET_FOR_READ_LOOP are not needed anymore, and the data handlers which switch to a handshake handler do not need to disable themselves anymore.
2012-09-02 12:34:44 -04:00
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/* splice not possible (anymore), let's go on on standard copy */
}
BUG/MEDIUM: stream-int: clear CO_FL_WAIT_ROOM after splicing data in Since we don't necessarily pass through conn_fd_handler() when reading, conn_refresh_polling_flags() is not necessarily called when performing a recv() operation, thus flags like CO_FL_WAIT_ROOM are not cleared. It happens that si_cs_recv() checks CO_FL_WAIT_ROOM before deciding to receive into a buffer, to see if the previous rcv_pipe() call failed by lack of pipe room. The combined effect of these two statements is that at the end of a file transmission, when there's too little data to warrant the use of a pipe and the pipe is empty, we refrain from using rcv_pipe() for the last few bytes, but since CO_FL_WAIT_ROOM is still present, we don't use rcv_buf() either, and the connection remains frozen in this state with si_cs_recv() called in loops. In order to fix this we can simply manually clear CO_FL_WAIT_ROOM when not using pipe so that the next check sees the result of the previous operation and not an old one. We could equally call cond_refresh_polling_flags() but that would be overkill and dangerous given that it would manipulate the connection's flags under the mux. By the way ideally the mux should report this flag into the connstream for cleaner manipulation. No backport is needed as this is only post 1.9-dev2.
2018-11-15 09:52:53 -05:00
else {
/* be sure not to block regular receive path below */
conn->flags &= ~CO_FL_WAIT_ROOM;
}
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
abort_splice:
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->pipe && unlikely(!ic->pipe->data)) {
put_pipe(ic->pipe);
ic->pipe = NULL;
MAJOR: stream-interface: restore splicing mechanism The splicing is now provided by the data-layer rcv_pipe/snd_pipe functions which in turn are called by the stream interface's recv and send callbacks. The presence of the rcv_pipe/snd_pipe functions is used to attest support for splicing at the data layer. It looks like the stream-interface's SI_FL_CAP_SPLICE flag does not make sense anymore as it's used as a proxy for the pointers above. It also appears that we call chk_snd() from the recv callback and then try to call it again in update_conn(). It is very likely that this last function will progressively slip into the recv/send callbacks in order to avoid duplicate check code. The code works right now with and without splicing. Only raw_sock provides support for it and it is automatically selected when the various splice options are set. However it looks like splice-auto doesn't enable it, which possibly means that the streamer detection code does not work anymore, or that it's only called at a time where it's too late to enable splicing (in process_session).
2012-08-23 18:46:52 -04:00
}
BUG/MAJOR: Fix how the list of entities waiting for a buffer is handled When an entity tries to get a buffer, if it cannot be allocted, for example because the number of buffers which may be allocated per process is limited, this entity is added in a list (called <buffer_wq>) and wait for an available buffer. Historically, the <buffer_wq> list was logically attached to streams because it were the only entities likely to be added in it. Now, applets can also be waiting for a free buffer. And with filters, we could imagine to have more other entities waiting for a buffer. So it make sense to have a generic list. Anyway, with the current design there is a bug. When an applet failed to get a buffer, it will wait. But we add the stream attached to the applet in <buffer_wq>, instead of the applet itself. So when a buffer is available, we wake up the stream and not the waiting applet. So, it is possible to have waiting applets and never awakened. So, now, <buffer_wq> is independant from streams. And we really add the waiting entity in <buffer_wq>. To be generic, the entity is responsible to define the callback used to awaken it. In addition, applets will still request an input buffer when they become active. But they will not be sleeped anymore if no buffer are available. So this is the responsibility to the applet I/O handler to check if this buffer is allocated or not. This way, an applet can decide if this buffer is required or not and can do additional processing if not. [wt: backport to 1.7 and 1.6]
2016-12-09 11:30:18 -05:00
/* now we'll need a input buffer for the stream */
MEDIUM: stream-int: replace channel_alloc_buffer() with si_alloc_ibuf() everywhere Well that's only 3 places (applet.c, stream_interface.c, hlua.c). This ensures we always clear SI_FL_WAIT_ROOM before setting it on failure, so that it is granted that SI_FL_WAIT_ROOM always indicates a lack of room for doing an operation, including the inability to allocate a buffer for this.
2018-10-25 04:21:41 -04:00
if (!si_alloc_ibuf(si, &(si_strm(si)->buffer_wait)))
MAJOR: session: only allocate buffers when needed A session doesn't need buffers all the time, especially when they're empty. With this patch, we don't allocate buffers anymore when the session is initialized, we only allocate them in two cases : - during process_session() - during I/O operations During process_session(), we try hard to allocate both buffers at once so that we know for sure that a started operation can complete. Indeed, a previous version of this patch used to allocate one buffer at a time, but it can result in a deadlock when all buffers are allocated for requests for example, and there's no buffer left to emit error responses. Here, if any of the buffers cannot be allocated, the whole operation is cancelled and the session is added at the tail of the buffer wait queue. At the end of process_session(), a call to session_release_buffers() is done so that we can offer unused buffers to other sessions waiting for them. For I/O operations, we only need to allocate a buffer on the Rx path. For this, we only allocate a single buffer but ensure that at least two are available to avoid the deadlock situation. In case buffers are not available, SI_FL_WAIT_ROOM is set on the stream interface and the session is queued. Unused buffers resulting either from a successful send() or from an unused read buffer are offered to pending sessions during the ->wake() callback.
2014-11-25 13:46:36 -05:00
goto end_recv;
BUG/MEDIUM: splicing: fix abnormal CPU usage with splicing Mark Janssen reported an issue in 1.5-dev19 which was introduced in 1.5-dev12 by commit 96199b10. From time to time, randomly, the CPU usage spikes to 100% for seconds to minutes. A deep analysis of the traces provided shows that it happens when waiting for the response to a second pipelined HTTP request, or when trying to handle the received shutdown advertised by epoll() after the last block of data. Each time, splice() was involved with data pending in the pipe. The cause of this was that such events could not be taken into account by splice nor by recv and were left pending : - the transfer of the last block of data, optionally with a shutdown was not handled by splice() because of the validation that to_forward is higher than MIN_SPLICE_FORWARD ; - the next recv() call was inhibited because of the test on presence of data in the pipe. This is also what prevented the recv() call from handling a response to a pipelined request until the client had ACKed the previous response. No less than 4 different methods were experimented to fix this, and the current one was finally chosen. The principle is that if an event is not caught by splice(), then it MUST be caught by recv(). So we remove the condition on the pipe's emptiness to perform an recv(), and in order to prevent recv() from being used in the middle of a transfer, we mark supposedly full pipes with CO_FL_WAIT_ROOM, which makes sense because the reason for stopping a splice()-based receive is that the pipe is supposed to be full. The net effect is that we don't wake up and sleep in loops during these transient states. This happened much more often than expected, sometimes for a few cycles at end of transfers, but rarely long enough to be noticed, unless a client timed out with data pending in the pipe. The effect on CPU usage is visible even when transfering 1MB objects in pipeline, where the CPU usage drops from 10 to 6% on a small machine at medium bandwidth. Some further improvements are needed : - the last chunk of a splice() transfer is never done using splice due to the test on to_forward. This is wrong and should be performed with splice if the pipe has not yet been emptied ; - si_chk_snd() should not be called when the write event is already being polled, otherwise we're almost certain to get EAGAIN. Many thanks to Mark for all the traces he cared to provide, they were essential for understanding this issue which was not reproducible without. Only 1.5-dev is affected, no backport is needed.
2013-07-18 15:49:32 -04:00
/* Important note : if we're called with POLL_IN|POLL_HUP, it means the read polling
* was enabled, which implies that the recv buffer was not full. So we have a guarantee
* that if such an event is not handled above in splice, it will be handled here by
* recv().
*/
BUG/MEDIUM: stream_interface: Make REALLY sure we read all the data. In si_cs_recv(), try inconditionally to recv as long as the CS_FL_RCV_MORE is set on the conn_stream, or we will miss some data.
2018-12-04 09:46:16 -05:00
while ((cs->flags & CS_FL_RCV_MORE) ||
(!(conn->flags & (CO_FL_ERROR | CO_FL_WAIT_ROOM | CO_FL_HANDSHAKE)) &&
(!(cs->flags & (CS_FL_ERROR|CS_FL_EOS))) && !(ic->flags & CF_SHUTR))) {
MEDIUM: stream-int: Try to read data even if channel's buffer seems to be full Before calling the mux to get incoming data, we get the amount of space available at the input of the buffer. If there is no space, we don't try to read more data. This is good enough when raw data are stored in the buffer. But this info has no meaning when structured data are stored. Because with the HTTP refactoring, such kind of data will be stored in buffers, it is a bit annoying. So, to avoid any problems, we always call the mux. It is the mux's responsiblity to notify the stream interface it needs more space to store more data. This must be done by setting the flag CS_FL_RCV_MORE on the conn_stream. This is exactly what we do in the pass-through mux when <count> is null.
2018-10-11 09:29:21 -04:00
/* <max> may be null. This is the mux responsibility to set
* CS_FL_RCV_MORE on the CS if more space is needed.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
max = channel_recv_max(ic);
MINOR: stream-int: Don't use the flag CO_RFL_KEEP_RSV anymore in si_cs_recv() Because the channel_recv_max() always return the right value, for HTX and legacy streams, we don't need to set this flag. The multiplexer don't use it anymore.
2019-05-14 16:46:41 -04:00
ret = cs->conn->mux->rcv_buf(cs, &ic->buf, max, flags | (co_data(ic) ? CO_RFL_BUF_WET : 0));
BUG/MEDIUM: stream-int: don't mark as blocked an empty buffer on Rx After 8706c8131 ("BUG/MEDIUM: mux_pt: Always set CS_FL_RCV_MORE."), a side effect caused failed receives to mark the buffer as missing room, a flag that no other place can remove since it's empty. Ideally we need a separate flag to mean "failed to deliver data by lack of room", but in the mean time at the very least we must not mark as blocked an empty buffer. No backport is needed.
2018-12-05 07:45:41 -05:00
BUG/MEDIUM: connections: Split CS_FL_RCV_MORE into 2 flags. CS_FL_RCV_MORE is used in two cases, to let the conn_stream know there may be more data available, and to let it know that it needs more room. We can't easily differentiate between the two, and that may leads to hangs, so split it into two flags, CS_FL_RCV_MORE, that means there may be more data, and CS_FL_WANT_ROOM, that means we need more room. This should not be backported.
2018-12-06 10:22:29 -05:00
if (cs->flags & CS_FL_WANT_ROOM)
MINOR: stream-int: replace si_cant_put() with si_rx_room_{blk,rdy}() Remaining calls to si_cant_put() were all for lack of room and were turned to si_rx_room_blk(). A few places where SI_FL_RXBLK_ROOM was cleared by hand were converted to si_rx_room_rdy(). The now unused si_cant_put() function was removed.
2018-11-15 05:08:52 -05:00
si_rx_room_blk(si);
BUG/MEDIUM: stream-int: always set SI_FL_WAIT_ROOM on CS_FL_RCV_MORE When a stream interface tries to read data from a mux using rcv_buf(), sometimes it sees 0 as the return value and concludes that there's no more data while there are, resulting in the connection being polled for more data and no new attempt being made at reading these pending data. Now it will automatically check for flag CS_FL_RCV_MORE to know if the mux really did not have anything available or was not able to provide these data by lack of room in the destination buffer, and will set SI_FL_WAIT_ROOM accordingly. This will ensure that once current data lying in the buffer are forwarded to the other side, reading chk_rcv() will be called to re-enable reading. It's important to note that in practice it will rely on the mux's update_poll() function to re-enable reading and that where the calls are placed in the stream interface, it's not possible to perform a new synchronous rcv_buf() call. Thus a corner case remains where the mux cannot receive due to a full buffer or any similar condition, but needs to be able to wake itself up to deliver pending data. This is a limitation of the current connection/conn_stream API which will likely need a new event subscription to at least call ->wake() asynchronously (eg: mux->{kick,restart,touch,update} ?). For now the affected mux (h2 only) will have to take care of the extra logic to carefully enable polling to restart processing incoming data. This patch relies on previous one (MINOR: conn_stream: add new flag CS_FL_RCV_MORE to indicate pending data) and both must be backported to 1.8.
2017-12-10 15:19:33 -05:00
MINOR: conn_stream: Add a flag to notify the SI some data were received The flag CS_FL_READ_PARTIAL can be set by the mux on the conn_stream to notify the stream interface that some data were received. Is is used in si_cs_recv to re-arm read timeout on the channel.
2018-10-31 03:53:54 -04:00
if (cs->flags & CS_FL_READ_PARTIAL) {
if (tick_isset(ic->rex))
ic->rex = tick_add_ifset(now_ms, ic->rto);
cs->flags &= ~CS_FL_READ_PARTIAL;
}
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
if (ret <= 0) {
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
break;
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
if (si->flags & SI_FL_L7_RETRY) {
struct htx *htx;
struct htx_sl *sl;
htx = htxbuf(&ic->buf);
if (htx) {
MINOR: htx: Replace the function http_find_stline() by http_get_stline() Now, we only return the start-line. If not found, NULL is returned. No lookup is performed and the HTX message is no more updated. It is now the caller responsibility to update the position of the start-line to the right value. So when it is not found, i.e sl_pos is set to -1, it means the last start-line has been already processed and the next one has not been inserted yet. It is mandatory to rely on this kind of warranty to store 1xx informational responses and final reponse in the same HTX message.
2019-05-13 08:41:27 -04:00
sl = http_get_stline(htx);
MEDIUM: streams: Add the ability to retry a request on L7 failure. When running in HTX mode, if we sent the request, but failed to get the answer, either because the server just closed its socket, we hit a server timeout, or we get a 404, 408, 425, 500, 501, 502, 503 or 504 error, attempt to retry the request, exactly as if we just failed to connect to the server. To do so, add a new backend keyword, "retry-on". It accepts a list of keywords, which can be "none" (never retry), "conn-failure" (we failed to connect, or to do the SSL handshake), "empty-response" (the server closed the connection without answering), "response-timeout" (we timed out while waiting for the server response), or "404", "408", "425", "500", "501", "502", "503" and "504". The default is "conn-failure".
2019-04-05 09:30:12 -04:00
if (sl && l7_status_match(si_strm(si)->be,
sl->info.res.status)) {
/* If we got a status for which we would
* like to retry the request, empty
* the buffer and pretend there's an
* error on the channel.
*/
ic->flags |= CF_READ_ERROR;
htx_reset(htx);
return 1;
}
}
si->flags &= ~SI_FL_L7_RETRY;
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
cur_read += ret;
/* if we're allowed to directly forward data, we must update ->o */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->to_forward && !(ic->flags & (CF_SHUTW|CF_SHUTW_NOW))) {
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
unsigned long fwd = ret;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->to_forward != CHN_INFINITE_FORWARD) {
if (fwd > ic->to_forward)
fwd = ic->to_forward;
ic->to_forward -= fwd;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
}
MINOR: channel/buffer: replace b_{adv,rew} with c_{adv,rew} These ones manipulate the output data count which will be specific to the channel soon, so prepare the call points to use the channel only. The b_* functions are now unused and were removed.
2018-06-06 01:13:22 -04:00
c_adv(ic, fwd);
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_READ_PARTIAL;
ic->total += ret;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
if ((ic->flags & CF_READ_DONTWAIT) || --read_poll <= 0) {
/* we're stopped by the channel's policy */
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
si_rx_chan_blk(si);
BUG/MINOR: stream-int: don't try to read again when CF_READ_DONTWAIT is set Commit 9aaf778 ("MAJOR: connection : Split struct connection into struct connection and struct conn_stream.") had to change the way the stream interface deals with incoming data to accomodate the mux. A break statement got lost during a change, leading to the receive call being performed twice even when CF_READ_DONTWAIT is set. The most noticeable effect is that it made the bug described in commit 33982cb ("BUG/MAJOR: stream: ensure analysers are always called upon close") much easier to reproduce as it would appear even with an HTTP frontend. Let's just restore the stream-interface flag and the break here, as in the previous code. No backport is needed as this was introduced during 1.8-dev.
2017-11-18 05:26:20 -05:00
break;
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/* if too many bytes were missing from last read, it means that
* it's pointless trying to read again because the system does
* not have them in buffers.
*/
if (ret < max) {
/* if a streamer has read few data, it may be because we
* have exhausted system buffers. It's not worth trying
* again.
*/
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
if (ic->flags & CF_STREAMER) {
/* we're stopped by the channel's policy */
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
si_rx_chan_blk(si);
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
break;
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/* if we read a large block smaller than what we requested,
* it's almost certain we'll never get anything more.
*/
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
if (ret >= global.tune.recv_enough) {
/* we're stopped by the channel's policy */
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
si_rx_chan_blk(si);
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
break;
BUG/MEDIUM: stream-int: change the way buffer room is requested by a stream-int Subsequent to the recent stream-int updates, we started to consider that SI_FL_WANT_PUT needs to be set when receipt is enabled, but this is wrong and results in 100% CPU when an HTTP client stays idle after a keep-alive request because the stream-int has nothing to provide and nothing to send. In fact just like for applets this flag should reflect the continuation of an attempt. So it's si_cs_recv() which should set the flag, and clear it if it has nothing more to provide. This function is called the first time in process_stream()), and called again during transfers, so it will always be up to date during stream_int_update() and stream_int_notify(). As a special case, it should also be set when a connection switches to the established state. And we should absolutely refrain from calling si_cs_recv() to re-enable reading, normally just setting this flag (from within the stream-int's handler or prior to calling si_chk_rcv()) is expected to be OK. A corner case remains where it was observed that in stream_int_notify() we can sometimes be called with an empty output channel with SI_FL_WAIT_ROOM and no CF_WRITE_PARTIAL, so there's no way to detect that we should re-enable receiving. It's easy to also take care of this condition there for the time it takes to figure if this situation is expected or not. Now it becomes more obvious that relying on a single flag to request room (or on two flags to arbiter activity) is not workable given the autonomy of both sides. The mux_h2 has taught us that blocking flags are much more reliable, require much less condition and are much easier to deal with. That's probably something to consider quickly in this area. No backport is needed.
2018-11-12 10:11:08 -05:00
}
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
}
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
/* if we are waiting for more space, don't try to read more data
* right now.
*/
MEDIUM: stream-int: make use of si_rx_chan_{rdy,blk} to control the stream-int from the channel The channel can disable reading from the stream-interface using various methods, such as : - CF_DONT_READ - !channel_may_recv() - and possibly others Till now this was done by mangling SI_FL_RX_WAIT_EP which is not appropriate at all since it's not the stream interface which decides whether it wants to deliver data or not. Some places were also wrongly relying on SI_FL_RXBLK_ROOM since it was the only other alternative, but it's not suitable for CF_DONT_READ. Let's use the SI_FL_RXBLK_CHAN flag for this instead. It will properly prevent the stream interface from being woken up and reads from subscribing to more receipt without being accidently removed. It is automatically reset if CF_DONT_READ is not set in stream_int_notify(). The code is not trivial because it splits the logic between everything related to buffer contents (channel_is_empty(), CF_WRITE_PARTIAL, etc) and buffer policy (CF_DONT_READ). Also it now needs to decide timeouts based on any blocking flag and not just SI_FL_RXBLK_ROOM anymore. It looks like this patch has caused a minor performance degradation on connection rate, which possibly deserves being investigated deeper as the test conditions are uncertain (e.g. slightly more subscribe calls?).
2018-11-14 11:10:36 -05:00
if (si_rx_blocked(si))
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
break;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
} /* while !flags */
BUG/MINOR: stream-int: make sure not to go through the rcv_buf path after splice() When splice() reports a pipe full condition, we go through the common code used to release a possibly empty pipe (which we don't have) and which immediately tries to allocate a buffer that will never be used. Further, it may even subscribe to get this buffer if the resources are low. Let's simply get out of this way if the pipe is full. This fix could be backported to 1.8 though the code is a bit different overthere.
2018-11-15 10:06:02 -05:00
done_recv:
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
if (cur_read) {
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if ((ic->flags & (CF_STREAMER | CF_STREAMER_FAST)) &&
MAJOR: buffer: finalize buffer detachment Now the buffers only contain the header and a pointer to the storage area which can be anywhere. This will significantly simplify buffer swapping and will make it possible to map chunks on buffers as well. The buf_empty variable was removed, as now it's enough to have size==0 and area==NULL to designate the empty buffer (thus a non-allocated head is the empty buffer by default). buf_wanted for now is indicated by size==0 and area==(void *)1. The channels and the checks now embed the buffer's head, and the only pointer is to the storage area. This slightly increases the unallocated buffer size (3 extra ints for the empty buffer) but considerably simplifies dynamic buffer management. It will also later permit to detach unused checks. The way the struct buffer is arranged has proven quite efficient on a number of tests, which makes sense given that size is always accessed and often first, followed by the othe ones.
2018-07-10 11:43:27 -04:00
(cur_read <= ic->buf.size / 2)) {
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->xfer_large = 0;
ic->xfer_small++;
if (ic->xfer_small >= 3) {
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
/* we have read less than half of the buffer in
* one pass, and this happened at least 3 times.
* This is definitely not a streamer.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags &= ~(CF_STREAMER | CF_STREAMER_FAST);
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
else if (ic->xfer_small >= 2) {
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
/* if the buffer has been at least half full twice,
* we receive faster than we send, so at least it
* is not a "fast streamer".
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags &= ~CF_STREAMER_FAST;
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
else if (!(ic->flags & CF_STREAMER_FAST) &&
MAJOR: buffer: finalize buffer detachment Now the buffers only contain the header and a pointer to the storage area which can be anywhere. This will significantly simplify buffer swapping and will make it possible to map chunks on buffers as well. The buf_empty variable was removed, as now it's enough to have size==0 and area==NULL to designate the empty buffer (thus a non-allocated head is the empty buffer by default). buf_wanted for now is indicated by size==0 and area==(void *)1. The channels and the checks now embed the buffer's head, and the only pointer is to the storage area. This slightly increases the unallocated buffer size (3 extra ints for the empty buffer) but considerably simplifies dynamic buffer management. It will also later permit to detach unused checks. The way the struct buffer is arranged has proven quite efficient on a number of tests, which makes sense given that size is always accessed and often first, followed by the othe ones.
2018-07-10 11:43:27 -04:00
(cur_read >= ic->buf.size - global.tune.maxrewrite)) {
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
/* we read a full buffer at once */
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->xfer_small = 0;
ic->xfer_large++;
if (ic->xfer_large >= 3) {
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
/* we call this buffer a fast streamer if it manages
* to be filled in one call 3 consecutive times.
*/
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= (CF_STREAMER | CF_STREAMER_FAST);
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
}
else {
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->xfer_small = 0;
ic->xfer_large = 0;
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->last_read = now_ms;
MEDIUM: stream-int: automatically disable CF_STREAMER flags after idle Disabling the streamer flags after an idle period will help TCP proxies to better adapt to the streams they're forwarding, especially with SSL where this will allow the SSL sender to use smaller records. This is typically used to optimally relay HTTP and derivatives such as SPDY or HTTP/2 in pure TCP mode when haproxy is used as an SSL offloader. This idea was first proposed by Ilya Grigorik on the haproxy mailing list, and his tests seem to confirm the improvement : https://www.mail-archive.com/haproxy@formilux.org/msg12576.html
2014-02-09 11:47:01 -05:00
}
MAJOR: session: only allocate buffers when needed A session doesn't need buffers all the time, especially when they're empty. With this patch, we don't allocate buffers anymore when the session is initialized, we only allocate them in two cases : - during process_session() - during I/O operations During process_session(), we try hard to allocate both buffers at once so that we know for sure that a started operation can complete. Indeed, a previous version of this patch used to allocate one buffer at a time, but it can result in a deadlock when all buffers are allocated for requests for example, and there's no buffer left to emit error responses. Here, if any of the buffers cannot be allocated, the whole operation is cancelled and the session is added at the tail of the buffer wait queue. At the end of process_session(), a call to session_release_buffers() is done so that we can offer unused buffers to other sessions waiting for them. For I/O operations, we only need to allocate a buffer on the Rx path. For this, we only allocate a single buffer but ensure that at least two are available to avoid the deadlock situation. In case buffers are not available, SI_FL_WAIT_ROOM is set on the stream interface and the session is queued. Unused buffers resulting either from a successful send() or from an unused read buffer are offered to pending sessions during the ->wake() callback.
2014-11-25 13:46:36 -05:00
end_recv:
MINOR: connection: make conn_stream users also check for per-stream error flag In a 1:1 connection:stream there's no problem relying on the connection flags alone to check for errors. But in a mux, it will be possible to mark certain streams in error without having to mark all of them. An example is an H2 client sending RST_STREAM frames to abort a long download, or a parse error requiring to abort only this specific stream. This commit ensures that stream-interface and checks properly check for CS_FL_ERROR in cs->flags wherever CO_FL_ERROR was in use. Most likely over the long term, any check for CO_FL_ERROR will have to disappear.
2017-10-16 09:17:17 -04:00
if (conn->flags & CO_FL_ERROR || cs->flags & CS_FL_ERROR)
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
MAJOR: session: only allocate buffers when needed A session doesn't need buffers all the time, especially when they're empty. With this patch, we don't allocate buffers anymore when the session is initialized, we only allocate them in two cases : - during process_session() - during I/O operations During process_session(), we try hard to allocate both buffers at once so that we know for sure that a started operation can complete. Indeed, a previous version of this patch used to allocate one buffer at a time, but it can result in a deadlock when all buffers are allocated for requests for example, and there's no buffer left to emit error responses. Here, if any of the buffers cannot be allocated, the whole operation is cancelled and the session is added at the tail of the buffer wait queue. At the end of process_session(), a call to session_release_buffers() is done so that we can offer unused buffers to other sessions waiting for them. For I/O operations, we only need to allocate a buffer on the Rx path. For this, we only allocate a single buffer but ensure that at least two are available to avoid the deadlock situation. In case buffers are not available, SI_FL_WAIT_ROOM is set on the stream interface and the session is queued. Unused buffers resulting either from a successful send() or from an unused read buffer are offered to pending sessions during the ->wake() callback.
2014-11-25 13:46:36 -05: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 12:30:23 -04:00
if (cs->flags & CS_FL_EOS)
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
/* connection closed */
goto out_shutdown_r;
MINOR: stream-int: use si_rx_blocked()/si_tx_blocked() to check readiness This way we don't limit ourselves to random flags only and the code is more readable and safer for the long term.
2018-11-14 08:07:59 -05:00
/* Subscribe to receive events if we're blocking on I/O */
MEDIUM: stream-int: update the endp polling status only at the end of si_cs_recv() Instead of first indicating that there's more data to read from the conn_stream then re-adjusting this info along the function, we now instead set the status according to the subscription status at the end. It's easier, more accurate, and less sensitive to intermediary changes. This will soon allow to remove all the si_cant_put() calls that were placed in the middle to force a subsequent callback and prevent the function from subscribing to the mux layer.
2018-11-15 10:55:14 -05:00
if (!si_rx_blocked(si)) {
CLEANUP: connection: rename subscription events values and event field The SUB_CAN_SEND/SUB_CAN_RECV enum values have been confusing a few times, especially when checking them on reading. After some discussion, it appears that calling them SUB_RETRY_SEND/SUB_RETRY_RECV more accurately reflects their purpose since these events may only appear after a first attempt to perform the I/O operation has failed or was not completed. In addition the wait_reason field in struct wait_event which carries them makes one think that a single reason may happen at once while it is in fact a set of events. Since the struct is called wait_event it makes sense that this field is called "events" to indicate it's the list of events we're subscribed to. Last, the values for SUB_RETRY_RECV/SEND were swapped so that value 1 corresponds to recv and 2 to send, as is done almost everywhere else in the code an in the shutdown() call.
2018-12-19 07:59:17 -05:00
conn->mux->subscribe(cs, SUB_RETRY_RECV, &si->wait_event);
MEDIUM: stream-int: update the endp polling status only at the end of si_cs_recv() Instead of first indicating that there's more data to read from the conn_stream then re-adjusting this info along the function, we now instead set the status according to the subscription status at the end. It's easier, more accurate, and less sensitive to intermediary changes. This will soon allow to remove all the si_cant_put() calls that were placed in the middle to force a subsequent callback and prevent the function from subscribing to the mux layer.
2018-11-15 10:55:14 -05:00
si_rx_endp_done(si);
} else {
si_rx_endp_more(si);
}
MEDIUM: stream_interface: Make recv() subscribe when more data is needed. Refactor the code so that si_cs_recv() subscribes to receive events.
2018-08-31 11:29:12 -04:00
MINOR: stream-int: use si_rx_blocked()/si_tx_blocked() to check readiness This way we don't limit ourselves to random flags only and the code is more readable and safer for the long term.
2018-11-14 08:07:59 -05:00
return (cur_read != 0) || si_rx_blocked(si);
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
out_shutdown_r:
BUG/MEDIUM: stream_interface: Don't report read0 if we were not connected. In si_cs_recv(), report that arrive at the end of stream only if we were indeed connected, we don't want that if the connection failed and we're about to retry.
2018-12-13 09:38:16 -05:00
if (conn->flags & CO_FL_CONNECTED) {
/* we received a shutdown */
ic->flags |= CF_READ_NULL;
if (ic->flags & CF_AUTO_CLOSE)
channel_shutw_now(ic);
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
stream_int_read0(si);
BUG/MEDIUM: stream_interface: Don't report read0 if we were not connected. In si_cs_recv(), report that arrive at the end of stream only if we were indeed connected, we don't want that if the connection failed and we're about to retry.
2018-12-13 09:38:16 -05:00
}
MEDIUM: stream_interfaces: Starts receiving from the upper layers. Instead of waiting for the connection layer to let us know we can read, attempt to receive as soon as process_stream() is called, and subscribe to receive events if we can't receive yet. Now, except for idle connections, the recv(), send() and wake() methods are no more, all the lower layers do is waking tasklet for anybody waiting for I/O events.
2018-09-11 12:27:21 -04:00
return 1;
REORG: stream-interface: move sock_raw_read() to si_conn_recv_cb() The recv function is now generic and is usable to iterate any connection-to-buf reading function from a stream interface. So let's move it to stream-interface.
2012-08-20 15:41:06 -04:00
}
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
/*
* This function propagates a null read received on a socket-based connection.
* It updates the stream interface. If the stream interface has SI_FL_NOHALF,
CLEANUP: stream-int: remove a redundant clearing of the linger_risk flag In stream_sock_read0(), we used to clear this flag. But the only case where stream_sock_read0() is called is in reaction with a conn_sock_read0() event coming from the lower layers, which already clears this flag. So let's remove this duplicate one and clear one of the few remaining layering violations in this area.
2015-03-12 17:32:27 -04:00
* the close is also forwarded to the write side as an abort.
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
*/
CLEANUP: stream-int: consistently call the si/stream_int functions As long-time changes have accumulated over time, the exported functions of the stream-interface were almost all prefixed "si_<something>" while most private ones (mostly callbacks) were called "stream_int_<something>". There were still a few confusing exceptions, which were addressed to follow this shcme : - stream_sock_read0(), only used internally, was renamed stream_int_read0() and made static - stream_int_notify() is only private and was made static - stream_int_{check_timeouts,report_error,retnclose,register_handler,update} were renamed si_<something>. Now it is clearer when checking one of these if it risks to be used outside or not.
2018-12-19 09:19:27 -05:00
static void stream_int_read0(struct stream_interface *si)
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04: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 12:30:23 -04:00
struct conn_stream *cs = __objt_cs(si->end);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
MAJOR: stream-int: stop using si->conn and use si->end instead The connection will only remain there as a pre-allocated entity whose goal is to be placed in ->end when establishing an outgoing connection. All connection initialization can be made on this connection, but all information retrieved should be applied to the end point only. This change is huge because there were many users of si->conn. Now the only users are those who initialize the new connection. The difficulty appears in a few places such as backend.c, proto_http.c, peers.c where si->conn is used to hold the connection's target address before assigning the connection to the stream interface. This is why we have to keep si->conn for now. A future improvement might consist in dynamically allocating the connection when it is needed.
2013-10-01 04:45:07 -04:00
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si_rx_shut_blk(si);
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (ic->flags & CF_SHUTR)
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
if (si->state != SI_ST_EST && si->state != SI_ST_CON)
return;
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
if (oc->flags & CF_SHUTW)
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
goto do_close;
if (si->flags & SI_FL_NOHALF) {
/* we want to immediately forward this close to the write side */
REORG/MAJOR: session: rename the "session" entity to "stream" With HTTP/2, we'll have to support multiplexed streams. A stream is in fact the largest part of what we currently call a session, it has buffers, logs, etc. In order to catch any error, this commit removes any reference to the struct session and tries to rename most "session" occurrences in function names to "stream" and "sess" to "strm" when that's related to a session. The files stream.{c,h} were added and session.{c,h} removed. The session will be reintroduced later and a few parts of the stream will progressively be moved overthere. It will more or less contain only what we need in an embryonic session. Sample fetch functions and converters will have to change a bit so that they'll use an L5 (session) instead of what's currently called "L4" which is in fact L6 for now. Once all changes are completed, we should see approximately this : L7 - http_txn L6 - stream L5 - session L4 - connection | applet There will be at most one http_txn per stream, and a same session will possibly be referenced by multiple streams. A connection will point to a session and to a stream. The session will hold all the information we need to keep even when we don't yet have a stream. Some more cleanup is needed because some code was already far from being clean. The server queue management still refers to sessions at many places while comments talk about connections. This will have to be cleaned up once we have a server-side connection pool manager. Stream flags "SN_*" still need to be renamed, it doesn't seem like any of them will need to move to the session.
2015-04-02 18:22:06 -04:00
/* force flag on ssl to keep stream in cache */
MINOR: conn_stream: modify cs_shut{r,w} API to pass the desired mode Now we can specify how we want to shutdown (drain vs reset, and normal vs silent), and this propagates to the mux then the transport layer.
2017-10-05 09:25:48 -04:00
cs_shutw(cs, CS_SHW_SILENT);
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
goto do_close;
}
/* otherwise that's just a normal read shutdown */
return;
do_close:
BUG/MAJOR: stream_interface: read0 not always handled since dev12 The connection handling changed introduced in 1.5-dev12 introduced a regression with commit 9bf9c14c. The issue is that the stream_sock_read0() callback must update the channel flags to indicate that the side is closed so that when process_session() is called, it can propagate the close to the other side and terminate the session. The issue only appears in HTTP tunnel mode. It's a bit tricky to trigger the issue, it requires that the request channel is full with data flowing from the client to the server and that both the response and the read0() are received at once so that the flags are not updated, and that the HTTP analyser switches to tunnel mode without being informed that the request write side is closed. After that, process_session() does not know that the connection has to be aborted either, and no more event appears on this side where the connection stays here forever. Many thanks to Igor at owind for testing several snapshots and for providing valuable traces to reproduce and diagnose the issue!
2012-11-21 15:51:53 -05:00
/* OK we completely close the socket here just as if we went through si_shut[rw]() */
MEDIUM: connection: replace conn_full_close() with cs_close() At all call places where a conn_stream is in use, we can now use cs_close() to get rid of a conn_stream and of its underlying connection if the mux estimates it makes sense. This is what is currently being done for the pass-through mux.
2017-10-05 12:52:17 -04:00
cs_close(cs);
BUG/MAJOR: stream_interface: read0 not always handled since dev12 The connection handling changed introduced in 1.5-dev12 introduced a regression with commit 9bf9c14c. The issue is that the stream_sock_read0() callback must update the channel flags to indicate that the side is closed so that when process_session() is called, it can propagate the close to the other side and terminate the session. The issue only appears in HTTP tunnel mode. It's a bit tricky to trigger the issue, it requires that the request channel is full with data flowing from the client to the server and that both the response and the read0() are received at once so that the flags are not updated, and that the HTTP analyser switches to tunnel mode without being informed that the request write side is closed. After that, process_session() does not know that the connection has to be aborted either, and no more event appears on this side where the connection stays here forever. Many thanks to Igor at owind for testing several snapshots and for providing valuable traces to reproduce and diagnose the issue!
2012-11-21 15:51:53 -05:00
CLEANUP: stream-int: limit usage of si_ic/si_oc As much as possible, we copy the result of this function into a local variable to avoid having to check the flag all the time.
2014-11-28 09:46:27 -05:00
oc->flags &= ~CF_SHUTW_NOW;
oc->flags |= CF_SHUTW;
oc->wex = TICK_ETERNITY;
BUG/MAJOR: stream_interface: read0 not always handled since dev12 The connection handling changed introduced in 1.5-dev12 introduced a regression with commit 9bf9c14c. The issue is that the stream_sock_read0() callback must update the channel flags to indicate that the side is closed so that when process_session() is called, it can propagate the close to the other side and terminate the session. The issue only appears in HTTP tunnel mode. It's a bit tricky to trigger the issue, it requires that the request channel is full with data flowing from the client to the server and that both the response and the read0() are received at once so that the flags are not updated, and that the HTTP analyser switches to tunnel mode without being informed that the request write side is closed. After that, process_session() does not know that the connection has to be aborted either, and no more event appears on this side where the connection stays here forever. Many thanks to Igor at owind for testing several snapshots and for providing valuable traces to reproduce and diagnose the issue!
2012-11-21 15:51:53 -05:00
MINOR: stream-int: make use of si_done_{get,put}() in shut{w,r} It's cleaner to use these functions there to properly clear the flags.
2018-11-06 13:23:03 -05:00
si_done_get(si);
BUG/MAJOR: stream_interface: read0 not always handled since dev12 The connection handling changed introduced in 1.5-dev12 introduced a regression with commit 9bf9c14c. The issue is that the stream_sock_read0() callback must update the channel flags to indicate that the side is closed so that when process_session() is called, it can propagate the close to the other side and terminate the session. The issue only appears in HTTP tunnel mode. It's a bit tricky to trigger the issue, it requires that the request channel is full with data flowing from the client to the server and that both the response and the read0() are received at once so that the flags are not updated, and that the HTTP analyser switches to tunnel mode without being informed that the request write side is closed. After that, process_session() does not know that the connection has to be aborted either, and no more event appears on this side where the connection stays here forever. Many thanks to Igor at owind for testing several snapshots and for providing valuable traces to reproduce and diagnose the issue!
2012-11-21 15:51:53 -05:00
BUG/MEDIUM: streams: Don't switch from SI_ST_CON to SI_ST_DIS on read0. When we receive a read0, and we're still in SI_ST_CON state (so on an outgoing conneciton), don't immediately switch to SI_ST_DIS, or, we would never call sess_establish(), and so the analysers will never run. Instead, let sess_establish() handle that case, and switch to SI_ST_DIS if we already have CF_SHUTR on the channel. This should be backported to 1.9.
2019-05-21 11:43:50 -04:00
/* Don't change the state to SI_ST_DIS yet if we're still
* in SI_ST_CON, otherwise it means sess_establish() hasn't
* been called yet, and so the analysers would not run.
*/
if (si->state == SI_ST_EST)
si->state = SI_ST_DIS;
MEDIUM: stream-interface: provide a generic stream_sock_read0() function This function is used by the data layer when a zero has been read over a connection. At the moment it only handles sockets and nothing else. Once the complete split is done between buffers and stream interfaces, it should become possible to work regardless on the connection type.
2012-08-20 09:38:41 -04:00
si->exp = TICK_ETERNITY;
return;
}
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
/* Callback to be used by applet handlers upon completion. It updates the stream
* (which may or may not take this opportunity to try to forward data), then
BUG/MAJOR: applet: fix a freeze if data is immedately forwarded. Introduced regression with 'MAJOR: applet scheduler rework' (1.8-dev only). The fix consist to re-enable the appctx immediatly from the applet wake cb if the process_stream is not pending in runqueue and the applet want perform a put or a get and the WAIT_ROOM flag was removed by stream_int_notify.
2017-06-30 08:11:56 -04:00
* may re-enable the applet's based on the channels and stream interface's final
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
* states.
*/
MINOR: stream-int: rename si_applet_done() to si_applet_wake_cb() This function is a callback made only for calls from the applet handler. Rename it to remove confusion. It's currently called from the Lua code but that's not correct, we should call the notify and update functions instead otherwise it will not enable the applet again.
2015-09-25 05:45:06 -04:00
void si_applet_wake_cb(struct stream_interface *si)
MEDIUM: stream-int: add a new function si_applet_done() This is the equivalent of si_conn_wake() but for applets. It will be called after changes to the stream interface are brought by the applet I/O handler. Ultimately it will release buffers and may be even wake the stream's task up if some important changes are detected. It would be nice to be able to merge it with the connection's wake function since it mostly manipulates the stream interface, but there are minor differences (such as how to enable/disable polling on a fd vs applet) and some specificities to applets (eg: don't wake the applet up until the output is empty) which would require abstract functions which would slow down everything.
2015-04-19 09:16:35 -04:00
{
BUG/MEDIUM: applet: fix reporting of broken write situation If an applet tries to write to a closed connection, it hangs forever. This results in some "get map" commands on the CLI to leave orphaned connections alive. Now the applet wakeup function detects that the applet still wants to write while the channel is closed for reads, which is the equivalent to the common "broken pipe" situation. In this case, an error is reported on the stream interface, just as it happens with connections trying to perform a send() in a similar situation. With this fix the stats socket is properly released.
2015-09-25 13:11:55 -04:00
struct channel *ic = si_ic(si);
/* If the applet wants to write and the channel is closed, it's a
* broken pipe and it must be reported.
*/
MINOR: stream-int: replace SI_FL_WANT_PUT with !SI_FL_RX_WAIT_EP The SI_FL_WANT_PUT flag is used in an awkward way, sometimes it's set by the stream-interface to mean "I have something to deliver", sometimes it's cleared by the channel to say "I don't want you to send what you have", and it has to be set back once CF_DONT_READ is cleared. This will have to be split between SI_FL_RX_WAIT_EP and SI_FL_RXBLK_CHAN. This patch only replaces all uses of the flag with its natural (but negated) replacement SI_FL_RX_WAIT_EP. The code is expected to be strictly equivalent. The now unused flag was completely removed.
2018-11-14 07:43:35 -05:00
if (!(si->flags & SI_FL_RX_WAIT_EP) && (ic->flags & CF_SHUTR))
BUG/MEDIUM: applet: fix reporting of broken write situation If an applet tries to write to a closed connection, it hangs forever. This results in some "get map" commands on the CLI to leave orphaned connections alive. Now the applet wakeup function detects that the applet still wants to write while the channel is closed for reads, which is the equivalent to the common "broken pipe" situation. In this case, an error is reported on the stream interface, just as it happens with connections trying to perform a send() in a similar situation. With this fix the stats socket is properly released.
2015-09-25 13:11:55 -04:00
si->flags |= SI_FL_ERR;
MINOR: stream-int: automatically mark applets as ready if they block on the channel If an applet reports being blocked due to any of the channel-side flags, it's reportedly ready to deliver incoming data. It's better to do this after the return from the applet handler so that applet developers don't have to worry about details related to flags ordering.
2018-11-16 10:18:34 -05:00
/* automatically mark the applet having data available if it reported
* begin blocked by the channel.
*/
if (si_rx_blocked(si))
si_rx_endp_more(si);
MEDIUM: stream-int: use the same stream notification function for applets and conns The code to report completion after a connection update or an applet update was almost the same since applets stole it from the connection. But the differences made them hard to maintain and prevented the creation of new functions doing only one part of the work. This patch replaces the common code from the si_conn_wake_cb() and si_applet_wake_cb() with a single call to stream_int_notify() which only notifies the stream (si+channels+task) from the outside. No functional change was made beyond this.
2015-09-23 14:06:13 -04:00
/* update the stream-int, channels, and possibly wake the stream up */
stream_int_notify(si);
MEDIUM: stream-int: add a new function si_applet_done() This is the equivalent of si_conn_wake() but for applets. It will be called after changes to the stream interface are brought by the applet I/O handler. Ultimately it will release buffers and may be even wake the stream's task up if some important changes are detected. It would be nice to be able to merge it with the connection's wake function since it mostly manipulates the stream interface, but there are minor differences (such as how to enable/disable polling on a fd vs applet) and some specificities to applets (eg: don't wake the applet up until the output is empty) which would require abstract functions which would slow down everything.
2015-04-19 09:16:35 -04:00
MINOR: stream-int: use si_rx_blocked()/si_tx_blocked() to check readiness This way we don't limit ourselves to random flags only and the code is more readable and safer for the long term.
2018-11-14 08:07:59 -05:00
/* stream_int_notify may have passed through chk_snd and released some
* RXBLK flags. Process_stream will consider those flags to wake up the
* appctx but in the case the task is not in runqueue we may have to
* wakeup the appctx immediately.
BUG/MAJOR: applet: fix a freeze if data is immedately forwarded. Introduced regression with 'MAJOR: applet scheduler rework' (1.8-dev only). The fix consist to re-enable the appctx immediatly from the applet wake cb if the process_stream is not pending in runqueue and the applet want perform a put or a get and the WAIT_ROOM flag was removed by stream_int_notify.
2017-06-30 08:11:56 -04:00
*/
BUG/MEDIUM: applets: Don't use task_in_rq(). When deciding if we want to wake the task of an applet up, don't give up if task_in_rq returns 1, as there's a race condition and another thread may run it. Instead, always attempt to task_wakeup(), at worst the task is already in the run queue, and nothing will happen.
2019-04-17 13:29:35 -04:00
if ((si_rx_endp_ready(si) && !si_rx_blocked(si)) ||
(si_tx_endp_ready(si) && !si_tx_blocked(si)))
MAJOR: stream: use a regular ->update for all stream interfaces Now si->update() is used to update any type of stream interface, whether it's an applet, a connection or even nothing. We don't call si_applet_call() anymore at the end of the resync and we don't have the risk that the stream's task is reinserted into the run queue, which makes the code a bit simpler. The stream_int_update_applet() function was simplified to ensure that it remained compatible with this standardized calling convention. It was almost copy-pasted from the update code dedicated to connections. Just like for si_applet_done(), it seems that it should be possible to merge the two functions except that it would require some slow operations, except maybe if the type of end point is tested inside the update function itself.
2015-04-19 12:13:56 -04:00
appctx_wakeup(si_appctx(si));
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
}
/*
* This function performs a shutdown-read on a stream interface attached to an
* applet in a connected or init state (it does nothing for other states). It
* either shuts the read side or marks itself as closed. The buffer flags are
* updated to reflect the new state. If the stream interface has SI_FL_NOHALF,
* we also forward the close to the write side. The owner task is woken up if
* it exists.
*/
static void stream_int_shutr_applet(struct stream_interface *si)
{
struct channel *ic = si_ic(si);
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si_rx_shut_blk(si);
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
if (ic->flags & CF_SHUTR)
return;
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
/* Note: on shutr, we don't call the applet */
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
if (si->state != SI_ST_EST && si->state != SI_ST_CON)
return;
if (si_oc(si)->flags & CF_SHUTW) {
BUG/MEDIUM: stream-int: avoid double-call to applet->release While the SI_ST_DIS state is set *after* doing the close on a connection, it was set *before* calling release on an applet. Applets have no internal flags contrary to connections, so they have no way to detect they were already released. Because of this it happened that applets were closed twice, once via si_applet_release() and once via si_release_endpoint() at the end of a transaction. The CLI applet could perform a double free in this case, though the situation to cause it is quite hard because it requires that the applet is stuck on output in states that produce very few data. In order to solve this, we now assign the SI_ST_DIS state *after* calling ->release, and we refrain from doing so if the state is already assigned. This makes applets work much more like connections and definitely avoids this double release. In the future it might be worth making applets have their own flags like connections to carry their own state regardless of the stream interface's state, especially when dealing with connection reuse. No backport is needed since this issue was caused by the rearchitecture in 1.6.
2015-09-25 14:24:26 -04:00
si_applet_release(si);
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
si->state = SI_ST_DIS;
si->exp = TICK_ETERNITY;
}
else if (si->flags & SI_FL_NOHALF) {
/* we want to immediately forward this close to the write side */
return stream_int_shutw_applet(si);
}
}
/*
* This function performs a shutdown-write on a stream interface attached to an
* applet in a connected or init state (it does nothing for other states). It
* either shuts the write side or marks itself as closed. The buffer flags are
* updated to reflect the new state. It does also close everything if the SI
* was marked as being in error state. The owner task is woken up if it exists.
*/
static void stream_int_shutw_applet(struct stream_interface *si)
{
struct channel *ic = si_ic(si);
struct channel *oc = si_oc(si);
oc->flags &= ~CF_SHUTW_NOW;
if (oc->flags & CF_SHUTW)
return;
oc->flags |= CF_SHUTW;
oc->wex = TICK_ETERNITY;
MINOR: stream-int: make use of si_done_{get,put}() in shut{w,r} It's cleaner to use these functions there to properly clear the flags.
2018-11-06 13:23:03 -05:00
si_done_get(si);
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
BUG/MEDIUM: stream: fix client-fin/server-fin handling A tcp half connection can cause 100% CPU on expiration. First reproduced with this haproxy configuration : global tune.bufsize 10485760 defaults timeout server-fin 90s timeout client-fin 90s backend node2 mode tcp timeout server 900s timeout connect 10s server def 127.0.0.1:3333 frontend fe_api mode tcp timeout client 900s bind :1990 use_backend node2 Ie timeout server-fin shorter than timeout server, the backend server sends data, this package is left in the cache of haproxy, the backend server continue sending fin package, haproxy recv fin package. this time the session information is as follows: time the session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=1s calls=3 rq[f=848000h,i=0,an=00h,rx=14m58s,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=,wx=14m58s,ax=] s0=[7,0h,fd=6,ex=] s1=[7,18h,fd=7,ex=] exp=14m58s rp has set the CF_SHUTR state, next, the client sends the fin package, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=08 age=38s calls=4 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=1m11s,wx=14m21s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=1m11s After waiting 90s, session information is as follows: 0x2373470: proto=tcpv4 src=127.0.0.1:39513 fe=fe_api be=node2 srv=def ts=04 age=4m11s calls=718074391 rq[f=84a020h,i=0,an=00h,rx=,wx=,ax=] rp[f=8004c020h,i=0,an=00h,rx=?,wx=10m49s,ax=] s0=[7,0h,fd=6,ex=] s1=[9,10h,fd=7,ex=] exp=? run(nice=0) cpu information: 6899 root 20 0 112224 21408 4260 R 100.0 0.7 3:04.96 haproxy Buffering is set to ensure that there is data in the haproxy buffer, and haproxy can receive the fin package, set the CF_SHUTR flag, If the CF_SHUTR flag has been set, The following code does not clear the timeout message, causing cpu 100%: stream.c:process_stream: if (unlikely((res->flags & (CF_SHUTR|CF_READ_TIMEOUT)) == CF_READ_TIMEOUT)) { if (si_b->flags & SI_FL_NOHALF) si_b->flags |= SI_FL_NOLINGER; si_shutr(si_b); } If you have closed the read, set the read timeout does not make sense. With or without cf_shutr, read timeout is set: if (tick_isset(s->be->timeout.serverfin)) { res->rto = s->be->timeout.serverfin; res->rex = tick_add(now_ms, res->rto); } After discussion on the mailing list, setting half-closed timeouts the hard way here doesn't make sense. They should be set only at the moment the shutdown() is performed. It will also solve a special case which was already reported of some half-closed timeouts not working when the shutw() is performed directly at the stream-interface layer (no analyser involved). Since the stream interface layer cannot know the timeout values, we'll have to store them directly in the stream interface so that they are used upon shutw(). This patch does this, fixing the problem. An easier reproducer to validate the fix is to keep the huge buffer and shorten all timeouts, then call it under tcploop server and client, and wait 3 seconds to see haproxy run at 100% CPU : global tune.bufsize 10485760 listen px bind :1990 timeout client 90s timeout server 90s timeout connect 1s timeout server-fin 3s timeout client-fin 3s server def 127.0.0.1:3333 $ tcploop 3333 L W N20 A P100 F P10000 & $ tcploop 127.0.0.1:1990 C S10000000 F
2017-03-10 12:41:51 -05:00
if (tick_isset(si->hcto)) {
ic->rto = si->hcto;
ic->rex = tick_add(now_ms, ic->rto);
}
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
/* on shutw we always wake the applet up */
appctx_wakeup(si_appctx(si));
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
switch (si->state) {
case SI_ST_EST:
/* we have to shut before closing, otherwise some short messages
* may never leave the system, especially when there are remaining
* unread data in the socket input buffer, or when nolinger is set.
* However, if SI_FL_NOLINGER is explicitly set, we know there is
* no risk so we close both sides immediately.
*/
if (!(si->flags & (SI_FL_ERR | SI_FL_NOLINGER)) &&
!(ic->flags & (CF_SHUTR|CF_DONT_READ)))
return;
/* fall through */
case SI_ST_CON:
case SI_ST_CER:
case SI_ST_QUE:
case SI_ST_TAR:
/* Note that none of these states may happen with applets */
si_applet_release(si);
BUG/MEDIUM: stream-int: avoid double-call to applet->release While the SI_ST_DIS state is set *after* doing the close on a connection, it was set *before* calling release on an applet. Applets have no internal flags contrary to connections, so they have no way to detect they were already released. Because of this it happened that applets were closed twice, once via si_applet_release() and once via si_release_endpoint() at the end of a transaction. The CLI applet could perform a double free in this case, though the situation to cause it is quite hard because it requires that the applet is stuck on output in states that produce very few data. In order to solve this, we now assign the SI_ST_DIS state *after* calling ->release, and we refrain from doing so if the state is already assigned. This makes applets work much more like connections and definitely avoids this double release. In the future it might be worth making applets have their own flags like connections to carry their own state regardless of the stream interface's state, especially when dealing with connection reuse. No backport is needed since this issue was caused by the rearchitecture in 1.6.
2015-09-25 14:24:26 -04:00
si->state = SI_ST_DIS;
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
default:
MEDIUM: stream-int: use si_rx_shut_blk() to indicate the SI is closed Till now we were using si_done_put() upon shutr, but these flags could be reset upon next activity. Now let's switch to SI_FL_RXBLK_SHUT which doesn't go away. It's also set in stream_int_update() in case a shutr condition is detected. The now unused si_done_put() was removed.
2018-11-14 10:58:52 -05:00
si->flags &= ~SI_FL_NOLINGER;
si_rx_shut_blk(si);
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
ic->flags |= CF_SHUTR;
ic->rex = TICK_ETERNITY;
si->exp = TICK_ETERNITY;
}
}
/* chk_rcv function for applets */
static void stream_int_chk_rcv_applet(struct stream_interface *si)
{
struct channel *ic = si_ic(si);
DPRINTF(stderr, "%s: si=%p, si->state=%d ic->flags=%08x oc->flags=%08x\n",
__FUNCTION__,
si, si->state, ic->flags, si_oc(si)->flags);
MEDIUM: stream-int: Rely only on SI_FL_WAIT_ROOM to stop data receipt This flag is set on the stream interface when we should wait for more space in the channel's buffer to store more incoming data. This means we should wait some outgoing data are sent before retrying to receive more data. But in stream interface functions, at many places, instead of checking this flag, we use the function channel_may_recv to know if we can (re)start reading. This currently works but it is not really consistent. And, it works because only raw data are stored in buffers. But it will be a problem when we start to store structured data in buffers. So to avoid any problems with futur implementations, we now rely only on SI_FL_WAIT_ROOM. The function channel_may_recv can still be called, but only when we are sure to handle raw data (for instance in functions ci_put*). To do so, among other things, we must be sure to unset SI_FL_WAIT_ROOM and offer an opportunity to call chk_rcv() on a stream interface when some data are sent on the other end, which is now granted by the previous patch series.
2018-10-11 07:54:13 -04:00
if (!ic->pipe) {
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
/* (re)start reading */
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
appctx_wakeup(si_appctx(si));
CLEANUP: typo: bad indent A space alignment remains in the stream_interface.c file
2015-09-04 12:40:36 -04:00
}
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
}
/* chk_snd function for applets */
static void stream_int_chk_snd_applet(struct stream_interface *si)
{
struct channel *oc = si_oc(si);
DPRINTF(stderr, "%s: si=%p, si->state=%d ic->flags=%08x oc->flags=%08x\n",
__FUNCTION__,
si, si->state, si_ic(si)->flags, oc->flags);
if (unlikely(si->state != SI_ST_EST || (oc->flags & CF_SHUTW)))
return;
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
/* we only wake the applet up if it was waiting for some data */
if (!(si->flags & SI_FL_WAIT_DATA))
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
return;
if (!tick_isset(oc->wex))
oc->wex = tick_add_ifset(now_ms, oc->wto);
MAJOR: applet: now call si_applet_done() instead of si_update() in I/O handlers The applet I/O handlers now rely on si_applet_done() which itself decides to wake up or sleep the appctx. Now it becomes critical that applte handlers properly call this on every exit path so that the appctx is removed from the active list after I/O have been handled. One such call was added to the Lua socket handler. It used to work without it probably because the main task is woken up by the parent task but now it's needed.
2015-04-19 11:20:03 -04:00
if (!channel_is_empty(oc)) {
/* (re)start sending */
appctx_wakeup(si_appctx(si));
}
REORG: stream-int: create si_applet_ops dedicated to applets These functions are dedicated to applets so that we don't use the default ones anymore in this case.
2015-04-13 10:30:14 -04:00
}
[MAJOR] add a connection error state to the stream_interface Tracking connection status changes was hard, and some code was redundant. A new SI_ST_CER state was added to the stream interface to indicate a past connection error, and an SI_FL_ERR flag was added to report past I/O error. The stream_sock code does not set the connection to SI_ST_CLO anymore in case of I/O error, it's the upper layer which does it. This makes it possible to know exactly when the file descriptors are allocated. The new SI_ST_CER state permitted to split tcp_connection_status() in two parts, one processing SI_ST_CON and the other one SI_ST_CER. Synchronous connection errors now make use of this last state, hence eliminating duplicate code. Some ib<->ob copy paste errors were found and fixed, and all entities setting SI_ST_CLO also shut the buffers down. Some of these stream_interface specific functions and structures have migrated to a new stream_interface.c file. Some types of errors are still not detected by the buffers. For instance, let's assume the following scenario in one single pass of process_session: a connection sits in SI_ST_TAR state during a retry. At TAR expiration, a new connection attempt is made, the connection is obtained and srv->cur_sess is increased. Then the buffer timeout is fires and everything is cleared, the new state becomes SI_ST_CLO. The cleaning code checks that previous state was either SI_ST_CON or SI_ST_EST to release the connection. But that's wrong because last state is still SI_ST_TAR. So the server's connection count does not get decreased. This means that prev_state must not be used, and must be replaced by some transition detection instead of level detection. The following debugging line was useful to track state changes : fprintf(stderr, "%s:%d: cs=%d ss=%d(%d) rqf=0x%08x rpf=0x%08x\n", __FUNCTION__, __LINE__, s->si[0].state, s->si[1].state, s->si[1].err_type, s->req->flags, s-> rep->flags);
2008-11-03 00:26:53 -05:00
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in a new issue Copy permalink