The main program 87 Note For simplicity, we use the index the event will have in the streams collection as its ID. This ID will be the same as the i variable in our loop. For example, in the first loop, i will be 0; it will also be the first stream to be pushed to our streams collection, so the index will be 0 as well. We therefore use 0 as the identification for this stream/event throughout since retrieving the Tcp Stream associated with this event will be as simple as indexing to that location in the streams collection. The next line, format!("/{delay}/request-{i}"), formats the path for our GET request. We set the timeout as described previously, and we also set a message where we store the identifier for this event, i, so we can track this event on the server side as well. Next up is creating a Tcp Stream. Y ou've probably noticed that the Tcp Stream in Rust doesn't accept &str but an argument that implements the To Socket Addrs trait. This trait is implemented for &str already, so that's why we can simply write it like we do in this example. Before Tcpstream::connect actually opens a socket, it will try to parse the address we pass in as an IP address. If it fails, it will parse it as a domain address and a port number, and then ask the operating system to do a DNS lookup for that address, which it then can use to actually connect to our server. So, you see, there is potentially quite a bit going on when we do a simple connection. Y ou probably remember that we discussed some of the nuances of the DNS lookup earlier and the fact that such a call could either be very fast since the operating system already has the information stored in memory or block while waiting for a response from the DNS server. This is a potential downside if you use Tcp Stream from the standard library if you want full control over the entire process. Tcp Stream in Rust and Nagle's algorithm Here is a little fact for you (I originally intended to call it a “fun fact, ” but realized that's stretching the concept of “fun” just a little too far!). In Rust's Tcp Stream, and, more importantly, most APIs that aim to mimic the standard library's Tcp Stream such as mio or Tokio, the stream is created with the TCP_NODELAY flag set to false. In practice, this means that Nagle's algorithm is used, which can cause some issues with latency outliers and possibly reduced throughput on some workloads. Nagle's algorithm is an algorithm that aims to reduce network congestion by pooling small network packages together. If you look at non-blocking I/O implementations in other languages, many, if not most, disable this algorithm by default. This is not the case in most Rust implementations and is worth being aware of. Y ou can disable it by simply calling Tcp Stream::set_ nodelay(true). If you try to create your own async library or rely on Tokio/mio, and observe lower throughput than expected or latency problems, it's worth checking whether this flag is set to true or not.