<commit_before>## Connection pooling

### Basics

The driver communicates with Cassandra over TCP, using the Cassandra
binary protocol. This protocol is asynchronous, which allows each TCP
connection to handle multiple simultaneous requests:

* when a query gets executed, a *stream id* gets assigned to it. It is a
  unique identifier on the current connection;
* the driver writes a request containing the stream id and the query on
  the connection, and then proceeds without waiting for the response (if
  you're using the asynchronous API, this is when the driver will send you
  back a [ResultSetFuture][result_set_future]).
  Once the request has been written to the
  connection, we say that it is *in flight*;
* at some point, Cassandra will send back a response on the connection.
  This response also contains the stream id, which allows the driver to
  trigger a callback that will complete the corresponding query (this is
  the point where your `ResultSetFuture` will get completed).

To increase the number of concurrent requests, we use a pool of
connections to each host.  **For each `Session` object, there is one
connection pool per connected host**.

The number of connections per pool is configurable (this will be
described in the next section).  The number of stream ids depends on the
[native protocol version](../native_protocol/):

* protocol v2 or below: 128 stream ids per connection.
* protocol v3 or above: up to 32768 stream ids per connection.

```ditaa<commit_msg>Update connection pooling doc to link to LBP.<commit_after>## Connection pooling

### Basics

The driver communicates with Cassandra over TCP, using the Cassandra
binary protocol. This protocol is asynchronous, which allows each TCP
connection to handle multiple simultaneous requests:

* when a query gets executed, a *stream id* gets assigned to it. It is a
  unique identifier on the current connection;
* the driver writes a request containing the stream id and the query on
  the connection, and then proceeds without waiting for the response (if
  you're using the asynchronous API, this is when the driver will send you
  back a [ResultSetFuture][result_set_future]).
  Once the request has been written to the
  connection, we say that it is *in flight*;
* at some point, Cassandra will send back a response on the connection.
  This response also contains the stream id, which allows the driver to
  trigger a callback that will complete the corresponding query (this is
  the point where your `ResultSetFuture` will get completed).

You don't need to manage connections yourself. You simply interact with a `Session` object, which takes care of it.

**For each `Session`, there is one connection pool per connected host** (a host is connected when it is up and
not ignored by the [load balancing policy](../load_balancing)).

The number of connections per pool is configurable (this will be
described in the next section).  The number of stream ids depends on the
[native protocol version](../native_protocol/):

* protocol v2 or below: 128 stream ids per connection.
* protocol v3 or above: up to 32768 stream ids per connection.

```ditaa
{'fraction_non_alphanumeric': 0.05084207181442644, 'fraction_numerical': 0.006355258976803305, 'mean_word_length': 4.474782608695652, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3361262', 'n_tokens_mistral': 780, 'n_tokens_neox': 740, 'n_words': 476}