Translation

(itstool) path: sect4/mediaobject
<imageobject> <imagedata fileref="sockets/sainlsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>sockaddr_in on an Intel system</phrase> </textobject>
197/1900
Context English Portuguese (Brazil) State
Now, let us try to fill it out. Let us assume we are trying to write a client for the <emphasis>daytime</emphasis> protocol, which simply states that its server will write a text string representing the current date and time to port 13. We want to use <acronym>TCP/IP</acronym>, so we need to specify <constant>AF_INET</constant> in the address family field. <constant>AF_INET</constant> is defined as <constant>2</constant>. Let us use the <acronym>IP</acronym> address of <systemitem class="ipaddress">192.43.244.18</systemitem>, which is the time server of US federal government (<systemitem class="fqdomainname">time.nist.gov</systemitem>). Agora, vamos tentar preenchê-lo. Vamos supor que estamos tentando escrever um cliente para o <emphasis> dia </emphasis> protocolo, que simplesmente afirma que seu servidor irá escrever uma seqüência de texto que representa a data e hora atuais para a porta 13. Queremos usar <acronym>TCP / IP</acronym> , por isso precisamos especificar <constant> AF_INET </constant> no campo da família de endereços. <constant> AF_INET </constant> é definido como <constant> 2 </constant> . Vamos usar o endereço <acronym>IP</acronym> de <systemitem class="ipaddress"> 192.43.244.18 </systemitem> , que é o servidor de horário do governo federal dos EUA ( <systemitem class="fqdomainname"> time.nist.gov </systemitem> )
_ external ref='sockets/sainfill' md5='__failed__' external ref='sockets/sainfill' md5='__failed__'
0 1 2 3
+--------+--------+-----------------+
0 | 0 | 2 | 13 |
+-----------------+-----------------+
4 | 192.43.244.18 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
0 1 2 3
+--------+--------+-----------------+
0 | 0 | 2 | 13 |
+-----------------+-----------------+
4 | 192.43.244.18 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
<imageobject> <imagedata fileref="sockets/sainfill"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Specific example of sockaddr_in</phrase> </textobject> <imageobject><imagedata fileref="sockets/sainfill"/></imageobject><textobject> &lt;_: literallayout-1 /&gt; </textobject><textobject><phrase> Exemplo específico de sockaddr_in </phrase></textobject>
By the way the <varname>sin_addr</varname> field is declared as being of the <varname>struct in_addr</varname> type, which is defined in <filename>netinet/in.h</filename>: A propósito, o <varname> sin_addr </varname> campo é declarado como sendo do <varname> struct in_addr </varname> tipo, que é definido em <filename> netinet / in.h </filename> :
/*
* Internet address (a structure for historical reasons)
*/
struct in_addr {
in_addr_t s_addr;
};

/*
* Internet address (a structure for historical reasons)
*/
struct in_addr {
in_addr_t s_addr;
};
In addition, <varname>in_addr_t</varname> is a 32-bit integer. Além do que, além do mais, <varname> in_addr_t </varname> é um inteiro de 32 bits.
The <systemitem class="ipaddress">192.43.244.18</systemitem> is just a convenient notation of expressing a 32-bit integer by listing all of its 8-bit bytes, starting with the <emphasis>most significant</emphasis> one. O <systemitem class="ipaddress"> 192.43.244.18 </systemitem> é apenas uma notação conveniente de expressar um inteiro de 32 bits, listando todos os seus bytes de 8 bits, começando com o <emphasis> mais significante </emphasis> 1.
So far, we have viewed <varname>sockaddr</varname> as an abstraction. Our computer does not store <varname>short</varname> integers as a single 16-bit entity, but as a sequence of 2 bytes. Similarly, it stores 32-bit integers as a sequence of 4 bytes. Até agora, vimos <varname> sockaddr </varname> como uma abstração. Nosso computador não armazena <varname> curto </varname> inteiros como uma única entidade de 16 bits, mas como uma sequência de 2 bytes. Da mesma forma, armazena números inteiros de 32 bits como uma seqüência de 4 bytes.
Suppose we coded something like this: Suponha que codificássemos algo assim:
sa.sin_family = AF_INET;
sa.sin_port = 13;
sa.sin_addr.s_addr = (((((192 &lt;&lt; 8) | 43) &lt;&lt; 8) | 244) &lt;&lt; 8) | 18;
sa.sin_family = AF_INET;
sa.sin_port = 13;
sa.sin_addr.s_addr = (((((192 &lt;&lt; 8) | 43) &lt;&lt; 8) | 244) &lt;&lt; 8) | 18;
What would the result look like? Como seria o resultado?
Well, that depends, of course. On a <trademark class="registered">Pentium</trademark>, or other x86, based computer, it would look like this: Bem, isso depende, claro. Em um <trademark class="registered"> Pentium </trademark> , ou outro computador baseado em x86, ficaria assim:
_ external ref='sockets/sainlsb' md5='__failed__' external ref='sockets/sainlsb' md5='__failed__'
0 1 2 3
+--------+--------+--------+--------+
0 | 0 | 2 | 13 | 0 |
+--------+--------+--------+--------+
4 | 18 | 244 | 43 | 192 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
0 1 2 3
+--------+--------+--------+--------+
0 | 0 | 2 | 13 | 0 |
+--------+--------+--------+--------+
4 | 18 | 244 | 43 | 192 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
<imageobject> <imagedata fileref="sockets/sainlsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>sockaddr_in on an Intel system</phrase> </textobject> <imageobject><imagedata fileref="sockets/sainlsb"/></imageobject><textobject> &lt;_: literallayout-1 /&gt; </textobject><textobject><phrase> sockaddr_in em um sistema Intel </phrase></textobject>
On a different system, it might look like this: Em um sistema diferente, pode ser assim:
_ external ref='sockets/sainmsb' md5='__failed__' external ref='sockets/sainmsb' md5='__failed__'
0 1 2 3
+--------+--------+--------+--------+
0 | 0 | 2 | 0 | 13 |
+--------+--------+--------+--------+
4 | 192 | 43 | 244 | 18 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
0 1 2 3
+--------+--------+--------+--------+
0 | 0 | 2 | 0 | 13 |
+--------+--------+--------+--------+
4 | 192 | 43 | 244 | 18 |
+-----------------------------------+
8 | 0 |
+-----------------------------------+
12 | 0 |
+-----------------------------------+
<imageobject> <imagedata fileref="sockets/sainmsb"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>sockaddr_in on an MSB system</phrase> </textobject> <imageobject><imagedata fileref="sockets/sainmsb"/></imageobject><textobject> &lt;_: literallayout-1 /&gt; </textobject><textobject><phrase> sockaddr_in em um sistema MSB </phrase></textobject>
And on a PDP it might look different yet. But the above two are the most common ways in use today. E em um PDP pode parecer diferente ainda. Mas os dois acima são as formas mais comuns em uso hoje.
Ordinarily, wanting to write portable code, programmers pretend that these differences do not exist. And they get away with it (except when they code in assembly language). Alas, you cannot get away with it that easily when coding for sockets. Normalmente, querendo escrever códigos portáveis, os programadores fingem que essas diferenças não existem. E eles se safam (exceto quando eles codificam na linguagem assembly). Infelizmente, você não pode se safar tão facilmente quando codifica para sockets.
Why? Por quê?
Because when communicating with another computer, you usually do not know whether it stores data <emphasis>most significant byte</emphasis> (<acronym>MSB</acronym>) or <emphasis>least significant byte</emphasis> (<acronym>LSB</acronym>) first. Porque quando se comunica com outro computador, você geralmente não sabe se ele armazena dados <emphasis> byte mais significativo </emphasis> ( <acronym>MSB</acronym> ) ou <emphasis> byte menos significativo </emphasis> ( <acronym>LSB</acronym> ) primeiro.
You might be wondering, <emphasis><quote>So, will sockets not handle it for me?</quote></emphasis> Você pode estar se perguntando, <emphasis><quote> Então, soquetes não vão lidar com isso para mim? </quote></emphasis>
It will not. Não vai.
While that answer may surprise you at first, remember that the general sockets interface only understands the <varname>sa_len</varname> and <varname>sa_family</varname> fields of the <varname>sockaddr</varname> structure. You do not have to worry about the byte order there (of course, on FreeBSD <varname>sa_family</varname> is only 1 byte anyway, but many other <trademark class="registered">UNIX</trademark> systems do not have <varname>sa_len</varname> and use 2 bytes for <varname>sa_family</varname>, and expect the data in whatever order is native to the computer). Embora essa resposta possa surpreendê-lo a princípio, lembre-se de que a interface geral de soquetes apenas compreende <varname> sa_len </varname> e <varname> sa_family </varname> campos do <varname> sockaddr </varname> estrutura. Você não precisa se preocupar com a ordem de bytes lá (é claro, no FreeBSD <varname> sa_family </varname> é apenas 1 byte, mas muitos outros <trademark class="registered"> UNIX </trademark> sistemas não têm <varname> sa_len </varname> e use 2 bytes para <varname> sa_family </varname> e espere que os dados em qualquer ordem sejam nativos para o computador).
But the rest of the data is just <varname>sa_data[14]</varname> as far as sockets goes. Depending on the <emphasis>address family</emphasis>, sockets just forwards that data to its destination. Mas o resto dos dados é apenas <varname> sa_data [14] </varname> tanto quanto os soquetes vão. Dependendo do <emphasis> família de endereço </emphasis> , soquetes apenas encaminha esses dados para o seu destino
Indeed, when we enter a port number, it is because we want the other computer to know what service we are asking for. And, when we are the server, we read the port number so we know what service the other computer is expecting from us. Either way, sockets only has to forward the port number as data. It does not interpret it in any way. De fato, quando inserimos um número de porta, é porque queremos que o outro computador saiba qual serviço estamos pedindo. E, quando somos o servidor, lemos o número da porta para sabermos qual serviço o outro computador está esperando De qualquer forma, os soquetes só precisam encaminhar o número da porta como dados. Ele não o interpreta de forma alguma.
Similarly, we enter the <acronym>IP</acronym> address to tell everyone on the way where to send our data to. Sockets, again, only forwards it as data. Da mesma forma, nós entramos no endereço <acronym>IP</acronym> para informar a todos no caminho para onde enviar nossos dados. Sockets, novamente, apenas o encaminha como dados.
That is why, we (the <emphasis>programmers</emphasis>, not the <emphasis>sockets</emphasis>) have to distinguish between the byte order used by our computer and a conventional byte order to send the data in to the other computer. É por isso que nós (o <emphasis> programadores </emphasis> , não o <emphasis> tomadas </emphasis> ) tem que distinguir entre a ordem de byte usada pelo nosso computador e uma ordem de byte convencional para enviar os dados para o outro computador.

Loading…

New source string a year ago
Browse all component changes

Things to check

Trailing space

Source and translation do not both end with a space

Fix string

Reset

Starting spaces

Source and translation do not both start with same number of spaces

Fix string

Reset

Glossary

English Portuguese (Brazil)
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect4/mediaobject
Source string location
book.translate.xml:5517
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/developers-handbook.po, string 916