<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
  <file original="NoName" source-language="en" datatype="plaintext" target-language="en">
    <body>
      <trans-unit xml:space="preserve" approved="no" id="67416c59dec14a48" weblate-flags="read-only">
        <source>Using sockets for inter-process communication</source>
        <target state="translated">Using sockets for inter-process communication</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">4</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c3555dc22aa4662d" weblate-flags="read-only">
        <source>Popular operating systems allow isolating different programs by executing them in separate `processes`. A :term:`socket` is a tool provided by the operating system that enables two separated processes to communicate with each other. A socket takes the form of a file descriptor and can be seen as a communication pipe through which the communicating processes can exchange arbitrary information. In order to receive a message, a process must be attached to a specific :term:`address` that the peer can use to reach it.</source>
        <target state="translated">Popular operating systems allow isolating different programs by executing them in separate `processes`. A :term:`socket` is a tool provided by the operating system that enables two separated processes to communicate with each other. A socket takes the form of a file descriptor and can be seen as a communication pipe through which the communicating processes can exchange arbitrary information. In order to receive a message, a process must be attached to a specific :term:`address` that the peer can use to reach it.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">7</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1e3aed4b2bb76632" weblate-flags="read-only">
        <source>The socket is a powerful abstraction as it allows processes to communicate even if they are located on different computers. In this specific cases, the inter-processes communication will go through a network.</source>
        <target state="translated">The socket is a powerful abstraction as it allows processes to communicate even if they are located on different computers. In this specific cases, the inter-processes communication will go through a network.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">52</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f35191c2ae558416" weblate-flags="read-only">
        <source>Networked applications were usually implemented by using the :term:`socket` :term:`API`. This API was designed when TCP/IP was first implemented in the `Unix BSD`_ operating system [Sechrest]_ [LFJLMT]_, and has served as the model for many APIs between applications and the networking stack in an operating system. Although the socket API is very popular, other APIs have also been developed. For example, the STREAMS API has been added to several Unix System V variants [Rago1993]_. The socket API is supported by most programming languages and several textbooks have been devoted to it. Users of the C language can consult [DC2009]_, [Stevens1998]_, [SFR2004]_ or [Kerrisk2010]_. The Java implementation of the socket API is described in [CD2008]_ and in the `Java tutorial &lt;http://java.sun.com/docs/books/tutorial/networking/sockets/index.html&gt;`_. In this section, we will use the C socket API to illustrate the key concepts.</source>
        <target state="translated">Networked applications were usually implemented by using the :term:`socket` :term:`API`. This API was designed when TCP/IP was first implemented in the `Unix BSD`_ operating system [Sechrest]_ [LFJLMT]_, and has served as the model for many APIs between applications and the networking stack in an operating system. Although the socket API is very popular, other APIs have also been developed. For example, the STREAMS API has been added to several Unix System V variants [Rago1993]_. The socket API is supported by most programming languages and several textbooks have been devoted to it. Users of the C language can consult [DC2009]_, [Stevens1998]_, [SFR2004]_ or [Kerrisk2010]_. The Java implementation of the socket API is described in [CD2008]_ and in the `Java tutorial &lt;http://java.sun.com/docs/books/tutorial/networking/sockets/index.html&gt;`_. In this section, we will use the C socket API to illustrate the key concepts.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">96</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5433eee457d420c5" weblate-flags="read-only">
        <source>The socket API is quite low-level and should be used only when you need a complete control of the network access. If your application simply needs, for instance, to retrieve data from a web server, there are much simpler and higher-level APIs.</source>
        <target state="translated">The socket API is quite low-level and should be used only when you need a complete control of the network access. If your application simply needs, for instance, to retrieve data from a web server, there are much simpler and higher-level APIs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">98</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="998718b36ec83072" weblate-flags="read-only">
        <source>A detailed discussion of the socket API is outside the scope of this section and the references cited above provide a detailed discussion of all the  details of the socket API. As a starting point, it is interesting to compare the socket API with the service primitives that we have discussed in the previous chapter. Let us first consider the connectionless service that consists of the following two primitives :</source>
        <target state="translated">A detailed discussion of the socket API is outside the scope of this section and the references cited above provide a detailed discussion of all the  details of the socket API. As a starting point, it is interesting to compare the socket API with the service primitives that we have discussed in the previous chapter. Let us first consider the connectionless service that consists of the following two primitives :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">100</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e6d703d4e39745c7" weblate-flags="read-only">
        <source>`DATA.request(destination,message)` is used to send a message to a specified destination. In this socket API, this corresponds to the ``send`` method.</source>
        <target state="translated">`DATA.request(destination,message)` is used to send a message to a specified destination. In this socket API, this corresponds to the ``send`` method.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">102</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="582917b34ceb98ef" weblate-flags="read-only">
        <source>`DATA.indication(message)` is issued by the transport service to deliver a message to the application. In the socket API, this corresponds to the return of the ``recv`` method that is called by the application.</source>
        <target state="translated">`DATA.indication(message)` is issued by the transport service to deliver a message to the application. In the socket API, this corresponds to the return of the ``recv`` method that is called by the application.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">103</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6cb1f497b95c2e57" weblate-flags="read-only">
        <source>The `DATA` primitives are exchanged through a service access point. In the socket API, the equivalent to the service access point is the `socket`. A `socket` is a data structure which is maintained by the networking stack and is used by the application every time it needs to send or receive data through the networking stack.</source>
        <target state="translated">The `DATA` primitives are exchanged through a service access point. In the socket API, the equivalent to the service access point is the `socket`. A `socket` is a data structure which is maintained by the networking stack and is used by the application every time it needs to send or receive data through the networking stack.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">105</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7ff7d89caec89a6e" weblate-flags="read-only">
        <source>Sending data to a peer using a socket</source>
        <target state="translated">Sending data to a peer using a socket</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">108</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="29f5b750a1d45fcd" weblate-flags="read-only">
        <source>In order to reach a peer, a process must know its :term:`address`. An address is a value that identifies a peer in a given network. There exists many different kinds of address families. For example, some of them allow reaching a peer using the file system on the computer. Some others enable communicating with a remote peer through a network. The socket API provides generic functions: the peer address is taken as a ``struct sockaddr *``, which can point to any family of address. This is partly why sockets are a powerful abstraction.</source>
        <target state="translated">In order to reach a peer, a process must know its :term:`address`. An address is a value that identifies a peer in a given network. There exists many different kinds of address families. For example, some of them allow reaching a peer using the file system on the computer. Some others enable communicating with a remote peer through a network. The socket API provides generic functions: the peer address is taken as a ``struct sockaddr *``, which can point to any family of address. This is partly why sockets are a powerful abstraction.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">110</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="6bcc0cc4ab3f2445" weblate-flags="read-only">
        <source>The ``sendto`` system call allows to send data to a peer identified by its socket address through a given socket.</source>
        <target state="translated">The ``sendto`` system call allows to send data to a peer identified by its socket address through a given socket.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">112</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f438056cd01380df" weblate-flags="read-only">
        <source>The first argument is the file descriptor of the socket that we use to perform the communication. ``buf`` is a buffer of length ``len`` containing the bytes to send to the peer. The usage of ``flags`` argument is out of the scope of this section and can be set to 0. ``dest_addr`` is the socket address of the destination to which we want to send the bytes, its length is passed using the ``addrlen`` argument.</source>
        <target state="translated">The first argument is the file descriptor of the socket that we use to perform the communication. ``buf`` is a buffer of length ``len`` containing the bytes to send to the peer. The usage of ``flags`` argument is out of the scope of this section and can be set to 0. ``dest_addr`` is the socket address of the destination to which we want to send the bytes, its length is passed using the ``addrlen`` argument.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">118</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9bfa6b913ea3259b" weblate-flags="read-only">
        <source>In the following example, a C program is sending the bytes ``'h'``, ``'e'``, ``'l'``, ``'l'`` and ``'o'`` to a remote process located at address ``peer_addr``, using the already created socket ``sock``.</source>
        <target state="translated">In the following example, a C program is sending the bytes ``'h'``, ``'e'``, ``'l'``, ``'l'`` and ``'o'`` to a remote process located at address ``peer_addr``, using the already created socket ``sock``.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">120</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="921395b99aa764c6" weblate-flags="read-only">
        <source>As the ``sendto`` function is generic, this function will work correctly independently from the fact that the peer's address is defined as a path on the computer filesystem or a network address.</source>
        <target state="translated">As the ``sendto`` function is generic, this function will work correctly independently from the fact that the peer's address is defined as a path on the computer filesystem or a network address.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">133</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="25e0023fc2ff38a0" weblate-flags="read-only">
        <source>Receiving data from a peer using a socket</source>
        <target state="translated">Receiving data from a peer using a socket</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">137</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1fe94e5fbf6e0419" weblate-flags="read-only">
        <source>Operating systems allow assigning an address to a socket using the ``bind`` system call. This is useful when you want to receive messages from another program to which you announced your socket address. Once the address is assigned to the socket, the program can receive data from others using system calls such as ``recv`` and ``read``. Note that we can use the ``read`` system call as the operating system provides a socket as a file descriptor.</source>
        <target state="translated">Operating systems allow assigning an address to a socket using the ``bind`` system call. This is useful when you want to receive messages from another program to which you announced your socket address. Once the address is assigned to the socket, the program can receive data from others using system calls such as ``recv`` and ``read``. Note that we can use the ``read`` system call as the operating system provides a socket as a file descriptor.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">139</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="692633ebd0be5672" weblate-flags="read-only">
        <source>The following program binds its socket to a given socket address and then waits for receiving new bytes, using the already created socket ``sock``.</source>
        <target state="translated">The following program binds its socket to a given socket address and then waits for receiving new bytes, using the already created socket ``sock``.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">142</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="dd96c52a60101b94" weblate-flags="read-only">
        <source>Depending on the socket address family, the operating system might implicitly assign an address to an unbound socket upon a call to ``write``, ``send`` or ``sendto``. While this is a useful behavior, describing it precisely is out of the scope of this section.</source>
        <target state="translated">Depending on the socket address family, the operating system might implicitly assign an address to an unbound socket upon a call to ``write``, ``send`` or ``sendto``. While this is a useful behavior, describing it precisely is out of the scope of this section.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">171</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5e576eb998a00fcd" weblate-flags="read-only">
        <source>While the provided examples show the usage of a `char` array as the data buffer, implementers should **never** assume that it contains a string. C programs rely on the `char` type to refer to a 8-bit long value, and arbitrary binary values can be exchanged over the network (i.e., the ``\0`` value does not delimit the end of the data).</source>
        <target state="translated">While the provided examples show the usage of a `char` array as the data buffer, implementers should **never** assume that it contains a string. C programs rely on the `char` type to refer to a 8-bit long value, and arbitrary binary values can be exchanged over the network (i.e., the ``\0`` value does not delimit the end of the data).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">175</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="66b44e13a26cc3bd" weblate-flags="read-only">
        <source>Using this code, the program will read and print an arbitrary message received from an arbitrary peer who knows the program's socket address. If we want to know the address of the peer that sent us the message, we can use the ``recvfrom`` system call. This is what a modified version of ``bind_and_receive_from_peer`` is doing below.</source>
        <target state="translated">Using this code, the program will read and print an arbitrary message received from an arbitrary peer who knows the program's socket address. If we want to know the address of the peer that sent us the message, we can use the ``recvfrom`` system call. This is what a modified version of ``bind_and_receive_from_peer`` is doing below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">177</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="bf44287298154e17" weblate-flags="read-only">
        <source>This function is now using the ``recvfrom`` system call that will also provide the address of the peer who sent the message. As addresses are generic and can have different sizes, ``recvfrom`` also tells us the size of the address that it has written.</source>
        <target state="translated">This function is now using the ``recvfrom`` system call that will also provide the address of the peer who sent the message. As addresses are generic and can have different sizes, ``recvfrom`` also tells us the size of the address that it has written.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">215</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="a89874bb72f9f0f5" weblate-flags="read-only">
        <source>``connect``: connecting a socket to a remote address</source>
        <target state="translated">``connect``: connecting a socket to a remote address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">218</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="384195cf188782e1" weblate-flags="read-only">
        <source>Operating systems enable linking a socket to a remote address so that every information sent through the socket will only be sent to this remote address, and the socket will only receive messages sent by this remote address. This can be done using the ``connect`` system call shown below.</source>
        <target state="translated">Operating systems enable linking a socket to a remote address so that every information sent through the socket will only be sent to this remote address, and the socket will only receive messages sent by this remote address. This can be done using the ``connect`` system call shown below.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">220</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4c7563a9931b4bf6" weblate-flags="read-only">
        <source>This system call will assign the socket ``sockfd`` to the ``addr`` remote socket address. The process can then use the ``send`` and ``write`` system calls that do not to specify the destination socket address. Furthermore, the calls to ``recv`` and ``read`` will only deliver messages sent by this remote address. This is useful when we only care about the other peer messages.</source>
        <target state="translated">This system call will assign the socket ``sockfd`` to the ``addr`` remote socket address. The process can then use the ``send`` and ``write`` system calls that do not to specify the destination socket address. Furthermore, the calls to ``recv`` and ``read`` will only deliver messages sent by this remote address. This is useful when we only care about the other peer messages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">226</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="3034e1d31af2855f" weblate-flags="read-only">
        <source>The following program connects a socket to a remote address, sends a message and waits for a reply.</source>
        <target state="translated">The following program connects a socket to a remote address, sends a message and waits for a reply.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">229</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e114c7dff1f421b0" weblate-flags="read-only">
        <source>Creating a new socket to communicate through a network</source>
        <target state="translated">Creating a new socket to communicate through a network</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">261</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="96d75e9a7821e6fc" weblate-flags="read-only">
        <source>Until now, we learned how to use sockets that were already created. When writing a whole program, you will have to create you own sockets and choose the concrete technology that it will use to communicate with others. In this section, we will create new sockets and allow a program to communicate with processes located on another computer using a network. The most recent standardized technology used to communicate through a network is the :term:`IPv6` network protocol. In the IPv6 protocol, hosts are identified using *IPv6 addresses*. Modern operating systems allow IPv6 network communications between programs to be done using the socket API, just as we did in the previous sections.</source>
        <target state="translated">Until now, we learned how to use sockets that were already created. When writing a whole program, you will have to create you own sockets and choose the concrete technology that it will use to communicate with others. In this section, we will create new sockets and allow a program to communicate with processes located on another computer using a network. The most recent standardized technology used to communicate through a network is the :term:`IPv6` network protocol. In the IPv6 protocol, hosts are identified using *IPv6 addresses*. Modern operating systems allow IPv6 network communications between programs to be done using the socket API, just as we did in the previous sections.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">263</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="f631810b4b403d1f" weblate-flags="read-only">
        <source>A program can use the ``socket`` system call to create a new socket.</source>
        <target state="translated">A program can use the ``socket`` system call to create a new socket.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">266</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1c2768766aad7d01" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">272</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="89539605e090d6ba" weblate-flags="read-only">
        <source>Sending a message to a remote peer using its IPv6 address</source>
        <target state="translated">Sending a message to a remote peer using its IPv6 address</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">282</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1fac008d9e3c6d9f" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">286</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="199753e710655230" weblate-flags="read-only">
        <source>The ``::1`` IPv6 address identifies the computer on which the current program is running.</source>
        <target state="translated">The ``::1`` IPv6 address identifies the computer on which the current program is running.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">285</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="ee16232a4f890ed1" weblate-flags="read-only">
        <source>The ``2001:6a8:308f:9:0:82ff:fe68:e520`` IPv6 address identifies the computer serving the ``https://beta.computer-networking.info`` website.</source>
        <target state="translated">The ``2001:6a8:308f:9:0:82ff:fe68:e520`` IPv6 address identifies the computer serving the ``https://beta.computer-networking.info`` website.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">286</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e162f4537fbef1f6" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">290</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="7da18d68e0836c9c" weblate-flags="read-only">
        <source>The IPv6 address of the computer</source>
        <target state="translated">The IPv6 address of the computer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">289</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="05225fc927c98fe1" weblate-flags="read-only">
        <source>The port number identifying the program running on the computer</source>
        <target state="translated">The port number identifying the program running on the computer</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">290</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e620addf3499fa9e" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">292</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="476a7272e27c2b7d" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">303</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5c1dfa3a1aee8c6c" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">324</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="0b6360fc3bdbf984" weblate-flags="read-only">
        <source>Endianness: exchanging integers between different computers</source>
        <target state="translated">Endianness: exchanging integers between different computers</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">328</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4a75b8c23510b4b2" weblate-flags="read-only">
        <source>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 :</source>
        <target state="translated">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 :</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">330</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="9fdb15f53e21d8a2" weblate-flags="read-only">
        <source>send the most significant byte followed by the least significant byte</source>
        <target state="translated">send the most significant byte followed by the least significant byte</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">332</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="aad38db36c1ba7a7" weblate-flags="read-only">
        <source>send the least significant byte followed by the most significant byte</source>
        <target state="translated">send the least significant byte followed by the most significant byte</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">333</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="538694314486c122" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">335</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="8075c4f87ad9450b" weblate-flags="read-only">
        <source>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`.</source>
        <target state="translated">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`.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">337</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="fe731472fbfd92c3" weblate-flags="read-only">
        <source>Message format</source>
        <target state="translated">Message format</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">343</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="4b8bf19a4231e8b1" weblate-flags="read-only">
        <source>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.</source>
        <target state="translated">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.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">345</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1d97688b164b9577" weblate-flags="read-only">
        <source>Exercises</source>
        <target state="translated">Exercises</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">348</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="e7c1749e4f4aaab7" weblate-flags="read-only">
        <source>Here are some exercises that will help you to learn how to use sockets.</source>
        <target state="translated">Here are some exercises that will help you to learn how to use sockets.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">350</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="b3c9f63cd4687f5c" weblate-flags="read-only">
        <source>During this course, you will be asked to implement a transport protocol running on Linux devices. To prepare yourself, try to implement the protocol described in the above tasks on your Linux personal machine. If you did these exercises correctly, most of your answers can be used as it (do not forget to include the required header files). In addition to the previously produced code, you will need</source>
        <target state="translated">During this course, you will be asked to implement a transport protocol running on Linux devices. To prepare yourself, try to implement the protocol described in the above tasks on your Linux personal machine. If you did these exercises correctly, most of your answers can be used as it (do not forget to include the required header files). In addition to the previously produced code, you will need</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">367</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="99ca638fc7141c25" weblate-flags="read-only">
        <source>to wrap the ``create_and_send_message`` in a ``client`` executable that can parse user arguments (the ``getopt(3)`` function might help) and appropriately call the wrapped function;</source>
        <target state="translated">to wrap the ``create_and_send_message`` in a ``client`` executable that can parse user arguments (the ``getopt(3)`` function might help) and appropriately call the wrapped function;</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">369</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="5fc7f2001665a216" weblate-flags="read-only">
        <source>to wrap the ``recv_and_handle_message`` server function in a ``server`` executable, similarly to what you have done with the ``client`` executable.</source>
        <target state="translated">to wrap the ``recv_and_handle_message`` server function in a ``server`` executable, similarly to what you have done with the ``client`` executable.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">370</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="1318ca77561f65da" weblate-flags="read-only">
        <source>As an example, here is what you could have to invoke your programs.</source>
        <target state="translated">As an example, here is what you could have to invoke your programs.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">372</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="244a3b379f901d60" weblate-flags="read-only">
        <source>If you want to observe the packets exchanged over the network, use a packet dissector such as `wireshark`_ or `tcpdump`_, listen the loopback interface (``lo``) and filter UDP packets using port 10000 (``udp.port==10000`` in `wireshark`_, ``udp port 10000`` with `tcpdump`_).</source>
        <target state="translated">If you want to observe the packets exchanged over the network, use a packet dissector such as `wireshark`_ or `tcpdump`_, listen the loopback interface (``lo``) and filter UDP packets using port 10000 (``udp.port==10000`` in `wireshark`_, ``udp port 10000`` with `tcpdump`_).</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">385</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="c463aea6549199a2" weblate-flags="read-only">
        <source>Footnotes</source>
        <target state="translated">Footnotes</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">389</context>
        </context-group>
      </trans-unit>
      <trans-unit xml:space="preserve" approved="no" id="63970ea9ff610d77" weblate-flags="read-only">
        <source>For example, the ``htonl(3)`` (resp. ``ntohl(3)``) function the standard C library converts a 32-bits unsigned integer from the byte order used by the CPU to the network byte order (resp. from the network byte order to the CPU byte order). Similar functions exist in other programming languages.</source>
        <target state="translated">For example, the ``htonl(3)`` (resp. ``ntohl(3)``) function the standard C library converts a 32-bits unsigned integer from the byte order used by the CPU to the network byte order (resp. from the network byte order to the CPU byte order). Similar functions exist in other programming languages.</target>
        <context-group name="" purpose="location">
          <context context-type="sourcefile">../../exercises/sockets.rst</context>
          <context context-type="linenumber">390</context>
        </context-group>
      </trans-unit>
    </body>
  </file>
</xliff>
