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

30 ../../exercises/sockets.rst:272
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``domain`` parameter specifies the address family that we will use to concretely perform the communication. For an IPv6 socket, the ``domain`` parameter will be set to the value ``AF_INET6``, telling the operating system that we plan to communicate using IPv6 addresses. The ``type`` parameter specifies the communication guarantees that we need. For now, we will use the type ``SOCK_DGRAM`` which allows us to send *unreliable messages*. This means that each data that we send at each call of ``sendto`` will either be completely received or not received at all. The last parameter will be set to ``0``. The following line creates a socket, telling the operating system that we want to communicate using IPv6 addresses and that we want to send unreliable messages. 769/10000 · 769
31 ../../exercises/sockets.rst:282
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Sending a message to a remote peer using its IPv6 address 57/10000 · 57
32 ../../exercises/sockets.rst:286
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now that we created an IPv6 socket, we can use it to reach another program if we know its IPv6 address. IPv6 addresses have a human-readable format that can be represented as a string of characters. The details of IPv6 addresses are out of scope of this section but here are some examples : 290/10000 · 290
33 ../../exercises/sockets.rst:285
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``::1`` IPv6 address identifies the computer on which the current program is running. 89/10000 · 89
34 ../../exercises/sockets.rst:286
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The ``2001:6a8:308f:9:0:82ff:fe68:e520`` IPv6 address identifies the computer serving the ``https://beta.computer-networking.info`` website. 140/10000 · 140
35 ../../exercises/sockets.rst:290
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — An IPv6 address often identifies a computer and not a program running on the computer. In order to identify a specific program running on a specific computer, we use a *port number* in addition to the IPv6 address. A program using an IPv6 socket is this identified using : 272/10000 · 272
36 ../../exercises/sockets.rst:289
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The IPv6 address of the computer 32/10000 · 32
37 ../../exercises/sockets.rst:290
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The port number identifying the program running on the computer 63/10000 · 63
38 ../../exercises/sockets.rst:292
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — A program can use the ``struct sockaddr_in6`` to represent IPv6 socket addresses. The following program creates a ``struct sockaddr_in6`` that identifies the program that reserved the port number ``55555`` on the computer identified by the ``::1`` IPv6 address. 261/10000 · 261
39 ../../exercises/sockets.rst:303
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Now, we have built everything we need to send a message to the remote program. The ``create_socket_and_send_message`` function below assembles all the building blocks we created until now in order to send the message ``"hello"`` to the program running on port ``55555`` on the computer identified by the ``::1`` IPv6 address. 325/10000 · 325
40 ../../exercises/sockets.rst:324
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Note that we can reuse our ``send_hello_to_peer`` function without any modification as we wrote it to handle any kind of sockets, including sockets using the IPv6 network protocol. 180/10000 · 180
41 ../../exercises/sockets.rst:328
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Endianness: exchanging integers between different computers 59/10000 · 59
42 ../../exercises/sockets.rst:330
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides character strings, some applications also need to exchange 16 bits and 32 bits fields such as integers. A naive solution would have been to send the 16- or 32-bits field as it is encoded in the host's memory. Unfortunately, there are different methods to store 16- or 32-bits fields in memory. Some CPUs store the most significant byte of a 16-bits field in the first address of the field while others store the least significant byte at this location. When networked applications running on different CPUs exchange 16 bits fields, there are two possibilities to transfer them over the transport service : 613/10000 · 613
43 ../../exercises/sockets.rst:332
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — send the most significant byte followed by the least significant byte 69/10000 · 69
44 ../../exercises/sockets.rst:333
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — send the least significant byte followed by the most significant byte 69/10000 · 69
45 ../../exercises/sockets.rst:335
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The first possibility was named `big-endian` in a note written by Cohen [Cohen1980]_ while the second was named `little-endian`. Vendors of CPUs that used `big-endian` in memory insisted on using `big-endian` encoding in networked applications while vendors of CPUs that used `little-endian` recommended the opposite. Several studies were written on the relative merits of each type of encoding, but the discussion became almost a religious issue [Cohen1980]_. Eventually, the Internet chose the `big-endian` encoding, i.e. multi-byte fields are always transmitted by sending the most significant byte first, :rfc:`791` refers to this encoding as the :term:`network-byte order`. Most libraries [#fhtonl]_ used to write networked applications contain functions to convert multi-byte fields from memory to the network byte order and the reverse. 844/10000 · 844
46 ../../exercises/sockets.rst:337
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Besides 16 and 32 bit words, some applications need to exchange data structures containing bit fields of various lengths. For example, a message may be composed of a 16 bits field followed by eight, one bit flags, a 24 bits field and two 8 bits bytes. Internet protocol specifications will define such a message by using a representation such as the one below. In this representation, each line corresponds to 32 bits and the vertical lines are used to delineate fields. The numbers above the lines indicate the bit positions in the 32-bits word, with the high order bit at position `0`. 587/10000 · 587
47 ../../exercises/sockets.rst:343
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Message format 14/10000 · 14
48 ../../exercises/sockets.rst:345
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — The message mentioned above will be transmitted starting from the upper 32-bits word in network byte order. The first field is encoded in 16 bits. It is followed by eight one bit flags (`A-H`), a 24 bits field whose high order byte is shown in the first line and the two low order bytes appear in the second line followed by two one byte fields. This ASCII representation is frequently used when defining binary protocols. We will use it for all the binary protocols that are discussed in this book. 499/10000 · 499
49 ../../exercises/sockets.rst:348
	English ↹ ↵ NBS … “ ” ‘ ’ ﹙-﹚ ‐ – — Exercises 9/10000 · 9