2. cnp3-ebook
3. exercises/tcp-2
4. English
5. Zen

11 ../../exercises/tcp-2.rst:57
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us start with the execution of a system call. A simple example is shown below. 82/10000 · 82
12 ../../exercises/tcp-2.rst:63
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``0`` indicates that the system call must be issued immediately. packetdrill_ then executes the system call and verifies that it returns ``3```. If yes, the processing continues. Otherwise the script stops and indicates an error. 234/10000 · 234
13 ../../exercises/tcp-2.rst:65
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — For this first example, we program packetdrill_ to inject the segments that a client would send. The first step is thus to prepare a :manpage:`socket` that can be used to accept this connection. This socket can be created by using the four system calls below. 259/10000 · 259
14 ../../exercises/tcp-2.rst:80
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — At this point, the socket is ready to accept incoming TCP connections. packetdrill_ needs to inject a TCP segment in the instrumented Linux stack. This can be done with the line below. 184/10000 · 184
15 ../../exercises/tcp-2.rst:86
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Each line of a packetdrill_ script starts with a `timing` parameter that indicates at what time the event specified on this line should happen. packetdrill_ supports absolute and relative timings. An absolute timing is simply a number that indicates the delay in seconds between the start of the script and the event. A relative timing is indicated by using ``+`` followed by a number. This number is then the delay in seconds between the previous event and the current line. Additional information may be found in [CCB+2013]_. 528/10000 · 528
16 ../../exercises/tcp-2.rst:88
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The description of TCP packets in packetdrill_ uses a syntax that is very close to the tcpdump_ one. The ``+0`` timing indicates that the line is executed immediately after the previous event. The ``<`` sign indicates that packetdrill_ injects a TCP segment and the ``S`` character indicates that the ``SYN`` flag must be set. Like tcpdump_, packetdrill_ uses sequence numbers that are relative to initial sequence number. The three numbers that follow are the sequence number of the first byte of the payload of the segment (``0``), the sequence number of the last byte of the payload of the segment (``0`` after the semi-column) and the length of the payload (``0`` between brackets) of the ``SYN`` segment. This segment does not contain a valid acknowledgment but advertises a window of 1000 bytes. All ``SYN`` segments must also include the ``MSS`` option. In this case, we set the MSS to 1000 bytes. The next line of the packetdrill_ script verifies the reply sent by the instrumented Linux kernel. 1003/10000 · 1003
17 ../../exercises/tcp-2.rst:95
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — This TCP segment is sent immediately by the stack. The ``SYN`` flag is set and the dot next to the ``S`` character indicates that the ACK flag is also set. The SYN+ACK segment does not contain any data but its acknowledgment number is set to 1 (relative to the initial sequence number). For outgoing packets, packetdrill_ does not verify the value of the advertised window. In this line, it also accepts any TCP options (``<...>``). 432/10000 · 432
18 ../../exercises/tcp-2.rst:98
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The third segment of the three-way handshake is sent by packetdrill_ after a delay of 0.1 seconds. The connection is now established and the accept system call will succeed. 173/10000 · 173
19 ../../exercises/tcp-2.rst:105
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The :manpage:`accept` system call returns a new file descriptor, in this case value ``4``. At this point, packetdrill_ can write data on the socket or inject packets. 166/10000 · 166
20 ../../exercises/tcp-2.rst:113
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ writes 10 bytes of data through the :manpage:`write` system call. The stack immediately sends these 10 bytes inside a segment whose ``Push`` flag is set [#fpush]_. The payload starts at sequence number ``1`` and ends at sequence number ``10``. packetdrill_ replies by injecting an acknowledgment for the entire data after 100 milliseconds. 352/10000 · 352
21 ../../exercises/tcp-2.rst:115
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ can also inject data that will be read by the stack as shown by the lines below. 93/10000 · 93
22 ../../exercises/tcp-2.rst:123
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — In the example above, packetdrill_ injects a segment containing two bytes. This segment is acknowledged and after that the :manpage:`read` system call succeeds and reads the available data with a buffer of 1000 bytes. It returns the amount of read bytes, i.e. ``2``. 266/10000 · 266
23 ../../exercises/tcp-2.rst:125
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — We can now close the connection gracefully. Let us first issue inject a segment with the ``FIN`` flag set. 106/10000 · 106
24 ../../exercises/tcp-2.rst:133
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — packetdrill_ injects the ``FIN`` segment and the instrumented kernel returns an acknowledgment. If packetdrill_ issues the :manpage:`close` system call, the kernel will send a ``FIN`` segment to terminate the connection. packetdrill_ injects an acknowledgment to confirm the end of the connection. 297/10000 · 297
25 ../../exercises/tcp-2.rst:142
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The complete packetdrill_ script is available from :download:`/exercises/packetdrill_scripts/connect.pkt`. 106/10000 · 106
26 ../../exercises/tcp-2.rst:145
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another interesting features of packetdrill_ is that it is possible to inspect the state maintained by the Linux kernel for the underlying connection using the ``TCP_INFO`` socket option. This makes it possible to retrieve the value of some variables of the TCP control block. 276/10000 · 276
27 ../../exercises/tcp-2.rst:147
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Let us first explore how a TCP connection can be established. In the previous script, we have injected the segments that a client would send to a server. We can also use the Linux stack as a client and inject the segments that a server would return. Such a client process would first create its :manpage:`socket`` and then issue the :manpage:`connect` system call. At this point, the stack sends a ``SYN`` segment. To simplify the scripts, we have configured the stack to use a ``MSS`` of 1000 bytes and disabled the TCP extensions (the details of this configuration may be found at the beginning of the script). The server replies with a ``SYN+ACK`` and the stack sends acknowledges it to finish the three-way-handshake. 721/10000 · 721
28 ../../exercises/tcp-2.rst:165
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``tcpi_state`` variable used in this script is returned by ``TCP_INFO`` [#ftcpinfo]_. It tracks the state of the TCP connection according to TCP's finite state machine [#fstates]_. This script is available from :download:`/exercises/packetdrill_scripts/client.pkt`. 269/10000 · 269
29 ../../exercises/tcp-2.rst:167
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another example is the simultaneous establishment of a TCP connection. The TCP stack sends a ``SYN`` and receives a ``SYN`` in response instead of a ``SYN+ACK``. It then acknowledges the received ``SYN`` and retransmits its own ``SYN``. The connection becomes established upon reception of the fourth segment. This script is available from :download:`/exercises/packetdrill_scripts/dual.pkt`. 392/10000 · 392
30 ../../exercises/tcp-2.rst:191
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Another usage of packetdrill_ is to explore how a TCP connection ends. The scripts below show how a TCP stack closes a TCP connection. The first example shows a local host that connects to a remote host and then closes the connection. The remote host acknowledges the ``FIN`` and later closes its direction of data transfer. This script is available from :download:`/exercises/packetdrill_scripts/local-close.pkt`. 414/10000 · 414