Willy Tarreau 53a4766e40 MEDIUM: connection: start to introduce a mux layer between xprt and data ... For HTTP/2 and QUIC, we'll need to deal with multiplexed streams inside a connection. After quite a long brainstorming, it appears that the connection interface to the existing streams is appropriate just like the connection interface to the lower layers. In fact we need to have the mux layer in the middle of the connection, between the transport and the data layer. A mux can exist on two directions/sides. On the inbound direction, it instanciates new streams from incoming connections, while on the outbound direction it muxes streams into outgoing connections. The difference is visible on the mux->init() call : in one case, an upper context is already known (outgoing connection), and in the other case, the upper context is not yet known (incoming connection) and will have to be allocated by the mux. The session doesn't have to create the new streams anymore, as this is performed by the mux itself. This patch introduces this and creates a pass-through mux called "mux_pt" which is used for all new connections and which only calls the data layer's recv,send,wake() calls. One incoming stream is immediately created when init() is called on the inbound direction. There should not be any visible impact. Note that the connection's mux is purposely not set until the session is completed so that we don't accidently run with the wrong mux. This must not cause any issue as the xprt_done_cb function is always called prior to using mux's recv/send functions.		2017-10-31 18:03:23 +01:00
..
common	MINOR: threads: add a portable barrier for threads and non-threads	2017-10-31 18:01:18 +01:00
import	MINOR: threads: Add atomic-ops and plock includes in import dir	2017-10-31 11:36:13 +01:00
proto	MEDIUM: connection: start to introduce a mux layer between xprt and data	2017-10-31 18:03:23 +01:00
types	MEDIUM: connection: start to introduce a mux layer between xprt and data	2017-10-31 18:03:23 +01:00