upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-04-04 16:46:45 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 6
haproxy/src/connection.c

519 lines
15 KiB
C
Raw Normal View History

MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
/*
* Connection management functions
*
* Copyright 2000-2012 Willy Tarreau <w@1wt.eu>
*
* 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.
*
*/
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
#include <errno.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
#include <common/compat.h>
#include <common/config.h>
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
#include <proto/connection.h>
CLEANUP: includes: fix includes for a number of users of fd.h It appears that fd.h includes a number of unneeded files and was included from standard.h, and as such served as an intermediary to provide almost everything to everyone. By removing its useless includes, a long dependency chain broke but could easily be fixed.
2012-09-02 16:34:23 -04:00
#include <proto/fd.h>
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
#include <proto/frontend.h>
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
#include <proto/proto_tcp.h>
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
#include <proto/session.h>
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
#include <proto/stream_interface.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#ifdef USE_OPENSSL
#include <proto/ssl_sock.h>
#endif
MAJOR: session: detach the connections from the stream interfaces We will need to be able to switch server connections on a session and to keep idle connections. In order to achieve this, the preliminary requirement is that the connections can survive the session and be detached from them. Right now they're still allocated at exactly the same place, so when there is a session, there are always 2 connections. We could soon improve on this by allocating the outgoing connection only during a connect(). This current patch touches a lot of code and intentionally does not change any functionnality. Performance tests show no regression (even a very minor improvement). The doc has not yet been updated.
2012-10-26 14:10:28 -04:00
struct pool_head *pool2_connection;
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
int init_connection()
{
pool2_connection = create_pool("connection", sizeof (struct connection), MEM_F_SHARED);
return pool2_connection != NULL;
}
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
/* I/O callback for fd-based connections. It calls the read/write handlers
MAJOR: make use of conn_{data|sock}_{poll|stop|want}* in connection handlers This is a second attempt at getting rid of FD_WAIT_*. Now the situation is much better since native I/O handlers can directly manipulate the FD using fd_{poll|want|stop}_* and the connection handlers manipulate connection-level flags using the conn_{data|sock}_* equivalent. Proceeding this way ensures that the connection flags always reflect the reality even after data<->handshake switches.
2012-08-09 08:45:22 -04:00
* provided by the connection's sock_ops, which must be valid. It returns 0.
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
*/
int conn_fd_handler(int fd)
{
MINOR: fd: make fdtab->owner a connection and not a stream_interface anymore It is more convenient with a connection here and will abstract stream_interface more easily.
2012-07-06 08:54:49 -04:00
struct connection *conn = fdtab[fd].owner;
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
unsigned int flags;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
if (unlikely(!conn))
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
return 0;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 13:19:13 -05:00
conn_refresh_polling_flags(conn);
flags = conn->flags & ~CO_FL_ERROR; /* ensure to call the wake handler upon error */
BUG/MAJOR: connection: always recompute polling status upon I/O Bryan Berry and Baptiste Assmann both reported some occasional CPU spinning loops where haproxy was still processing I/O but burning CPU for apparently uncaught events. What happens is the following sequence : - proxy is in TCP mode - a connection from a client initiates a connection to a server - the connection to the server does not immediately happen and is polled for - in the mean time, the client speaks and the stream interface calls ->chk_snd() on the peer connection to send the new data - chk_snd() calls send_loop() to send the data. This last one makes the connection succeed and empties the buffer, so it disables polling on the connection and on the FD by creating an update entry. - before the update is processed, poll() succeeds and reports a write event for this fd. The poller does fd_ev_set() on the FD to switch it to speculative mode - the IO handler is called with a connection which has no write flag but an FD which is enabled in speculative mode. - the connection does nothing useful. - conn_update_polling() at the end of conn_fd_handler() cannot disable the FD because there were no changes on this FD. - the handler is left with speculative polling still enabled on the FD, and will be called over and over until a poll event is needed to transfer data. There is no perfectly elegant solution to this. At least we should update the flags indicating the current polling status to reflect what is being done at the FD level. This will allow to detect that the FD needs to be disabled upon exit. chk_snd() also needs minor changes to correctly switch to speculative polling before calling send_loop(), and to reflect this in the connection flags. This is needed so that no event remains stuck there without any polling. In fact, chk_snd() and chk_rcv() should perform the same number of preparations and cleanups as conn_fd_handler().
2012-12-10 10:33:38 -05:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
process_handshake:
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* The handshake callbacks are called in sequence. If either of them is
* missing something, it must enable the required polling at the socket
* layer of the connection. Polling state is not guaranteed when entering
* these handlers, so any handshake handler which does not complete its
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
* work must explicitly disable events it's not interested in. Error
* handling is also performed here in order to reduce the number of tests
* around.
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
*/
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
while (unlikely(conn->flags & (CO_FL_HANDSHAKE | CO_FL_ERROR))) {
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely(conn->flags & CO_FL_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
goto leave;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MAJOR: connection: make the PROXY decoder a handshake handler The PROXY protocol is now decoded in the connection before other handshakes. This means that it may be extracted from a TCP stream before SSL is decoded from this stream.
2012-08-31 11:43:29 -04:00
if (conn->flags & CO_FL_ACCEPT_PROXY)
if (!conn_recv_proxy(conn, CO_FL_ACCEPT_PROXY))
goto leave;
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
if (conn->flags & CO_FL_SEND_PROXY)
if (!conn_si_send_proxy(conn, CO_FL_SEND_PROXY))
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
goto leave;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#ifdef USE_OPENSSL
if (conn->flags & CO_FL_SSL_WAIT_HS)
if (!ssl_sock_handshake(conn, CO_FL_SSL_WAIT_HS))
goto leave;
#endif
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
}
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* Once we're purely in the data phase, we disable handshake polling */
if (!(conn->flags & CO_FL_POLL_SOCK))
__conn_sock_stop_both(conn);
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
MEDIUM: connection: use a generic data-layer init() callback The generic data-layer init callback is now used after the transport layer is complete and before calling the data layer recv/send callbacks. This allows the session to switch from the embryonic session data layer to the complete stream interface data layer, by making conn_session_complete() the data layer's init callback. It sill looks awkwards that the init() callback must be used opon error, but except by adding yet another one, it does not seem to be mergeable into another function (eg: it should probably not be merged with ->wake to avoid unneeded calls during the handshake, though semantically that would make sense).
2012-10-02 19:39:48 -04:00
/* The data layer might not be ready yet (eg: when using embryonic
* sessions). If we're about to move data, we must initialize it first.
* The function may fail and cause the connection to be destroyed, thus
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
* we must not use it anymore and should immediately leave instead.
*/
MEDIUM: connection: use a generic data-layer init() callback The generic data-layer init callback is now used after the transport layer is complete and before calling the data layer recv/send callbacks. This allows the session to switch from the embryonic session data layer to the complete stream interface data layer, by making conn_session_complete() the data layer's init callback. It sill looks awkwards that the init() callback must be used opon error, but except by adding yet another one, it does not seem to be mergeable into another function (eg: it should probably not be merged with ->wake to avoid unneeded calls during the handshake, though semantically that would make sense).
2012-10-02 19:39:48 -04:00
if ((conn->flags & CO_FL_INIT_DATA) && conn->data->init(conn) < 0)
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
return 0;
BUG/MAJOR: connection: risk of crash on certain tricky close scenario In some circumstances, if the connection to the server is aborted while some data were planned to be sent and the poller reported an ability to send, then conn_fd_handler() would still call conn->data->send(), causing the data layer to dereference the now NULL conn->xprt and crash. So we have to check for conn->xprt validity before calling the data layer. This issue was introduced after 1.5-dev12 so it does not need any backport and does not affect any released version. Special thanks go to Cristian Ditoiu who once again provided amazing help to troubleshoot this bug !
2012-10-22 16:47:55 -04:00
/* The data transfer starts here and stops on error and handshakes. Note
* that we must absolutely test conn->xprt at each step in case it suddenly
* changes due to a quick unexpected close().
*/
MEDIUM: connection: no need to recheck FD state We already have everything in the connection flags using the CO_FL_DATA_*_ENA bits combined with the fd's ready state, so we do not need to check fdtab[fd].ev anymore. This considerably simplifies the connection handling logic since it doesn't have to mix connection flags with past polling states.
2014-01-21 05:01:08 -05:00
if (conn->xprt && fd_recv_ready(fd) &&
((conn->flags & (CO_FL_DATA_RD_ENA|CO_FL_WAIT_ROOM|CO_FL_ERROR|CO_FL_HANDSHAKE)) == CO_FL_DATA_RD_ENA)) {
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
/* force detection of a flag change : it's impossible to have both
* CONNECTED and WAIT_CONN so we're certain to trigger a change.
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
*/
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
flags = CO_FL_WAIT_L4_CONN | CO_FL_CONNECTED;
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
conn->data->recv(conn);
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
}
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MEDIUM: connection: no need to recheck FD state We already have everything in the connection flags using the CO_FL_DATA_*_ENA bits combined with the fd's ready state, so we do not need to check fdtab[fd].ev anymore. This considerably simplifies the connection handling logic since it doesn't have to mix connection flags with past polling states.
2014-01-21 05:01:08 -05:00
if (conn->xprt && fd_send_ready(fd) &&
((conn->flags & (CO_FL_DATA_WR_ENA|CO_FL_WAIT_DATA|CO_FL_ERROR|CO_FL_HANDSHAKE)) == CO_FL_DATA_WR_ENA)) {
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
/* force detection of a flag change : it's impossible to have both
* CONNECTED and WAIT_CONN so we're certain to trigger a change.
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
*/
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
flags = CO_FL_WAIT_L4_CONN | CO_FL_CONNECTED;
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
conn->data->send(conn);
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
}
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
/* It may happen during the data phase that a handshake is
* enabled again (eg: SSL)
*/
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
if (unlikely(conn->flags & (CO_FL_HANDSHAKE | CO_FL_ERROR)))
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
goto process_handshake;
MEDIUM: connection: add check for readiness in I/O handlers The recv/send callbacks must check for readiness themselves instead of having their callers do it. This will strengthen the test and will also ensure we never refrain from calling a handshake handler because a direction is being polled while the other one is ready.
2014-01-20 09:13:07 -05:00
if (unlikely(conn->flags & CO_FL_WAIT_L4_CONN)) {
MEDIUM: connection: only call tcp_connect_probe when nothing was attempted yet It was observed that after a failed send() on EAGAIN, a second connect() would still be attempted in tcp_connect_probe() because there was no way to know that a send() had failed. By checking the WANT_WR status flag, we know if a previous write attempt failed on EAGAIN, so we don't try to connect again if we know this has already failed. With this simple change, the second connect() has disappeared.
2012-09-01 11:59:22 -04:00
/* still waiting for a connection to establish and nothing was
* attempted yet to probe the connection. Then let's retry the
* connect().
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
*/
MEDIUM: stream_interface: pass connection instead of fd in sock_ops The sock_ops I/O callbacks made use of an FD till now. This has become inappropriate and the struct connection is much more useful. It also fixes the race condition introduced by previous change.
2012-07-23 12:53:03 -04:00
if (!tcp_connect_probe(conn))
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
goto leave;
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -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
leave:
MEDIUM: connection: make it possible for data->wake to return an error Just like ->init(), ->wake() may now be used to return an error and abort the connection. Currently this is not used but will be with embryonic sessions.
2012-10-03 15:12:16 -04:00
/* The wake callback may be used to process a critical error and abort the
* connection. If so, we don't want to go further as the connection will
* have been released and the FD destroyed.
*/
if ((conn->flags & CO_FL_WAKE_DATA) &&
((conn->flags ^ flags) & CO_FL_CONN_STATE) &&
conn->data->wake(conn) < 0)
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
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
/* Last check, verify if the connection just established */
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
if (unlikely(!(conn->flags & (CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN | 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
conn->flags |= CO_FL_CONNECTED;
MEDIUM: connection: remove the FD_POLL_* flags only once It's inappropriate to remove FD_POLL_IN and FD_POLL_OUT in the IO callback handlers, first because they shouldn't care about this, and second because it will make it harder to chain multiple callers. So let's flush these flags only once for all in the connection handler. Right now, the HUP and ERR flags are still flushed in each IO handler to avoid multiple calls. This will probably have to be fixed later.
2012-07-23 06:14:26 -04:00
/* remove the events before leaving */
BUG/MAJOR: polling: do not set speculative events on ERR nor HUP Errors and Hangups are sticky events, which means that once they're detected, we never clear them, allowing them to be handled later if needed. Till now when an error was reported, it used to register a speculative I/O event for both recv and send. Since the connection had not requested such events, it was not able to detect a change and did not clear them, so the events were called in loops until a timeout caused their owner task to die. So this patch does two things : - stop registering spec events when no I/O activity was requested, so that we don't end up with non-disablable polling state ; - keep the sticky polling flags (ERR and HUP) when leaving the connection handler so that an error notification doesn't magically become a normal recv() or send() report once the event is converted to a spec event. It is normally not needed to make the connection handler emit an error when it detects POLL_ERR because either a registered data handler will have done it, or the event will be disabled by the wake() callback.
2012-12-06 18:09:43 -05:00
fdtab[fd].ev &= FD_POLL_STICKY;
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* commit polling changes */
conn_cond_update_polling(conn);
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;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
}
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the data layer expectations indicated by CO_FL_DATA_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 16:21:15 -04:00
* operation. Polling is totally disabled if an error was reported.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
*/
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
void conn_update_data_polling(struct connection *c)
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
{
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
unsigned int f = c->flags;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(c))
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
return;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
/* update read status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_DATA_RD_ENA)) == CO_FL_DATA_RD_ENA)) {
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
fd_want_recv(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_RD_ENA;
}
else if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_DATA_RD_ENA)) == CO_FL_CURR_RD_ENA)) {
fd_stop_recv(c->t.sock.fd);
f &= ~CO_FL_CURR_RD_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
/* update write status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_DATA_WR_ENA)) == CO_FL_DATA_WR_ENA)) {
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
fd_want_send(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_WR_ENA;
}
else if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_DATA_WR_ENA)) == CO_FL_CURR_WR_ENA)) {
fd_stop_send(c->t.sock.fd);
f &= ~CO_FL_CURR_WR_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
c->flags = f;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the sock layer expectations indicated by CO_FL_SOCK_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 16:21:15 -04:00
* operation. Polling is totally disabled if an error was reported.
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
*/
void conn_update_sock_polling(struct connection *c)
{
unsigned int f = c->flags;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(c))
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
return;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
/* update read status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_SOCK_RD_ENA)) == CO_FL_SOCK_RD_ENA)) {
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
fd_want_recv(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_RD_ENA;
}
else if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_SOCK_RD_ENA)) == CO_FL_CURR_RD_ENA)) {
fd_stop_recv(c->t.sock.fd);
f &= ~CO_FL_CURR_RD_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
/* update write status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_SOCK_WR_ENA)) == CO_FL_SOCK_WR_ENA)) {
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
fd_want_send(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_WR_ENA;
}
else if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_SOCK_WR_ENA)) == CO_FL_CURR_WR_ENA)) {
fd_stop_send(c->t.sock.fd);
f &= ~CO_FL_CURR_WR_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
c->flags = f;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* This handshake handler waits a PROXY protocol header at the beginning of the
* raw data stream. The header looks like this :
*
* "PROXY" <SP> PROTO <SP> SRC3 <SP> DST3 <SP> SRC4 <SP> <DST4> "\r\n"
*
* There must be exactly one space between each field. Fields are :
* - PROTO : layer 4 protocol, which must be "TCP4" or "TCP6".
* - SRC3 : layer 3 (eg: IP) source address in standard text form
* - DST3 : layer 3 (eg: IP) destination address in standard text form
* - SRC4 : layer 4 (eg: TCP port) source address in standard text form
* - DST4 : layer 4 (eg: TCP port) destination address in standard text form
*
* This line MUST be at the beginning of the buffer and MUST NOT wrap.
*
* The header line is small and in all cases smaller than the smallest normal
* TCP MSS. So it MUST always be delivered as one segment, which ensures we
* can safely use MSG_PEEK and avoid buffering.
*
* Once the data is fetched, the values are set in the connection's address
* fields, and data are removed from the socket's buffer. The function returns
* zero if it needs to wait for more data or if it fails, or 1 if it completed
* and removed itself.
*/
int conn_recv_proxy(struct connection *conn, int flag)
{
char *line, *end;
/* we might have been called just after an asynchronous shutr */
if (conn->flags & CO_FL_SOCK_RD_SH)
goto fail;
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -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 fail;
MEDIUM: connection: add check for readiness in I/O handlers The recv/send callbacks must check for readiness themselves instead of having their callers do it. This will strengthen the test and will also ensure we never refrain from calling a handshake handler because a direction is being polled while the other one is ready.
2014-01-20 09:13:07 -05:00
if (!fd_recv_ready(conn->t.sock.fd))
return 0;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
do {
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
trash.len = recv(conn->t.sock.fd, trash.str, trash.size, MSG_PEEK);
if (trash.len < 0) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (errno == EINTR)
continue;
if (errno == EAGAIN) {
MEDIUM: connection: remove conn_{data,sock}_poll_{recv,send} We simply remove these functions and replace their calls with the appropriate ones : - if we're in the data phase, we can simply report wait on the FD - if we're in the socket phase, we may also have to signal the desire to read/write on the socket because it might not be active yet.
2014-01-22 14:02:06 -05:00
fd_cant_recv(conn->t.sock.fd);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
return 0;
}
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto recv_abort;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
}
} while (0);
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
if (!trash.len) {
/* client shutdown */
conn->err_code = CO_ER_PRX_EMPTY;
goto fail;
}
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
if (trash.len < 6)
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto missing;
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
line = trash.str;
end = trash.str + trash.len;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* Decode a possible proxy request, fail early if it does not match */
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
if (strncmp(line, "PROXY ", 6) != 0) {
conn->err_code = CO_ER_PRX_NOT_HDR;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto fail;
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
line += 6;
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
if (trash.len < 18) /* shortest possible line */
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto missing;
if (!memcmp(line, "TCP4 ", 5) != 0) {
u32 src3, dst3, sport, dport;
line += 5;
src3 = inetaddr_host_lim_ret(line, end, &line);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dst3 = inetaddr_host_lim_ret(line, end, &line);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
sport = read_uint((const char **)&line, end);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dport = read_uint((const char **)&line, end);
if (line > end - 2)
goto missing;
if (*line++ != '\r')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (*line++ != '\n')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in *)&conn->addr.from)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.from)->sin_addr.s_addr = htonl(src3);
((struct sockaddr_in *)&conn->addr.from)->sin_port = htons(sport);
((struct sockaddr_in *)&conn->addr.to)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.to)->sin_addr.s_addr = htonl(dst3);
((struct sockaddr_in *)&conn->addr.to)->sin_port = htons(dport);
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
else if (!memcmp(line, "TCP6 ", 5) != 0) {
u32 sport, dport;
char *src_s;
char *dst_s, *sport_s, *dport_s;
struct in6_addr src3, dst3;
line += 5;
src_s = line;
dst_s = sport_s = dport_s = NULL;
while (1) {
if (line > end - 2) {
goto missing;
}
else if (*line == '\r') {
*line = 0;
line++;
if (*line++ != '\n')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
break;
}
if (*line == ' ') {
*line = 0;
if (!dst_s)
dst_s = line + 1;
else if (!sport_s)
sport_s = line + 1;
else if (!dport_s)
dport_s = line + 1;
}
line++;
}
if (!dst_s || !sport_s || !dport_s)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
sport = read_uint((const char **)&sport_s,dport_s - 1);
if (*sport_s != 0)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dport = read_uint((const char **)&dport_s,line - 2);
if (*dport_s != 0)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (inet_pton(AF_INET6, src_s, (void *)&src3) != 1)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (inet_pton(AF_INET6, dst_s, (void *)&dst3) != 1)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in6 *)&conn->addr.from)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.from)->sin6_addr, &src3, sizeof(struct in6_addr));
((struct sockaddr_in6 *)&conn->addr.from)->sin6_port = htons(sport);
((struct sockaddr_in6 *)&conn->addr.to)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.to)->sin6_addr, &dst3, sizeof(struct in6_addr));
((struct sockaddr_in6 *)&conn->addr.to)->sin6_port = htons(dport);
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
else {
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
/* The protocol does not match something known (TCP4/TCP6) */
conn->err_code = CO_ER_PRX_BAD_PROTO;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto fail;
}
/* remove the PROXY line from the request. For this we re-read the
* exact line at once. If we don't get the exact same result, we
* fail.
*/
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
trash.len = line - trash.str;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
do {
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
int len2 = recv(conn->t.sock.fd, trash.str, trash.len, 0);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (len2 < 0 && errno == EINTR)
continue;
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
if (len2 != trash.len)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto recv_abort;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
} while (0);
conn->flags &= ~flag;
return 1;
missing:
/* Missing data. Since we're using MSG_PEEK, we can only poll again if
* we have not read anything. Otherwise we need to fail because we won't
* be able to poll anymore.
*/
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
conn->err_code = CO_ER_PRX_TRUNCATED;
goto fail;
bad_header:
/* This is not a valid proxy protocol header */
conn->err_code = CO_ER_PRX_BAD_HDR;
goto fail;
recv_abort:
conn->err_code = CO_ER_PRX_ABORT;
MEDIUM: connection: set the socket shutdown flags on socket errors When we get a hard error from a syscall indicating the socket is dead, it makes sense to set the CO_FL_SOCK_WR_SH and CO_FL_SOCK_RD_SH flags to indicate that the socket may not be used anymore. It will ease the error processing in health checks where the state of socket is very important. We'll also be able to avoid some setsockopt(nolinger) after an error. For now, the rest of the code is not impacted because CO_FL_ERROR is always tested prior to these flags.
2013-12-04 17:44:10 -05:00
conn->flags |= CO_FL_SOCK_RD_SH | CO_FL_SOCK_WR_SH;
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto fail;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
fail:
BUG/MINOR: connection: remove a few synchronous calls to polling updates There were a few synchronous calls to polling updates in some functions called from the connection handler. These ones are not needed and should be replaced by more efficient and more debugable asynchronous calls.
2012-12-10 11:03:52 -05:00
__conn_sock_stop_both(conn);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
conn->flags |= CO_FL_ERROR;
return 0;
}
/* Makes a PROXY protocol line from the two addresses. The output is sent to
* buffer <buf> for a maximum size of <buf_len> (including the trailing zero).
* It returns the number of bytes composing this line (including the trailing
* LF), or zero in case of failure (eg: not enough space). It supports TCP4,
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
* TCP6 and "UNKNOWN" formats. If any of <src> or <dst> is null, UNKNOWN is
* emitted as well.
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
*/
int make_proxy_line(char *buf, int buf_len, struct sockaddr_storage *src, struct sockaddr_storage *dst)
{
int ret = 0;
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
ret = snprintf(buf + ret, buf_len - ret, "PROXY TCP4 ");
if (ret >= buf_len)
return 0;
/* IPv4 src */
if (!inet_ntop(src->ss_family, &((struct sockaddr_in *)src)->sin_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
buf[ret++] = ' ';
/* IPv4 dst */
if (!inet_ntop(dst->ss_family, &((struct sockaddr_in *)dst)->sin_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
/* source and destination ports */
ret += snprintf(buf + ret, buf_len - ret, " %u %u\r\n",
ntohs(((struct sockaddr_in *)src)->sin_port),
ntohs(((struct sockaddr_in *)dst)->sin_port));
if (ret >= buf_len)
return 0;
}
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
else if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET6) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
ret = snprintf(buf + ret, buf_len - ret, "PROXY TCP6 ");
if (ret >= buf_len)
return 0;
/* IPv6 src */
if (!inet_ntop(src->ss_family, &((struct sockaddr_in6 *)src)->sin6_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
buf[ret++] = ' ';
/* IPv6 dst */
if (!inet_ntop(dst->ss_family, &((struct sockaddr_in6 *)dst)->sin6_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
/* source and destination ports */
ret += snprintf(buf + ret, buf_len - ret, " %u %u\r\n",
ntohs(((struct sockaddr_in6 *)src)->sin6_port),
ntohs(((struct sockaddr_in6 *)dst)->sin6_port));
if (ret >= buf_len)
return 0;
}
else {
/* unknown family combination */
ret = snprintf(buf, buf_len, "PROXY UNKNOWN\r\n");
if (ret >= buf_len)
return 0;
}
return ret;
}
Reference in a new issue Copy permalink