Translation

(itstool) path: sect2/para
Had we not known the correct port for the <emphasis>daytime</emphasis> service, we could have found it this way:
126/1120
Context English Portuguese (Brazil) State
FreeBSD C library contains many helper functions for sockets programming. For example, in our sample client we hard coded the <systemitem class="fqdomainname">time.nist.gov</systemitem> <acronym>IP</acronym> address. But we do not always know the <acronym>IP</acronym> address. Even if we do, our software is more flexible if it allows the user to enter the <acronym>IP</acronym> address, or even the domain name. A biblioteca C do FreeBSD contém muitas funções auxiliares para a programação de sockets. Por exemplo, em nosso cliente de amostra nós codificamos <systemitem class="fqdomainname"> time.nist.gov </systemitem> Endereço <acronym>IP</acronym> . Mas nem sempre sabemos o endereço <acronym>IP</acronym> . Mesmo se o fizermos, nosso software será mais flexível se permitir que o usuário insira o endereço <acronym>IP</acronym> ou até mesmo o nome do domínio.
<function>gethostbyname</function> <function> gethostbyname </function>
While there is no way to pass the domain name directly to any of the sockets functions, the FreeBSD C library comes with the <citerefentry><refentrytitle>gethostbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry> and <citerefentry><refentrytitle>gethostbyname2</refentrytitle><manvolnum>3</manvolnum></citerefentry> functions, declared in <filename>netdb.h</filename>. Enquanto não há como passar o nome de domínio diretamente para qualquer uma das funções dos sockets, a biblioteca C do FreeBSD vem com <citerefentry><refentrytitle> gethostbyname </refentrytitle><manvolnum> 3 </manvolnum></citerefentry> e <citerefentry><refentrytitle> gethostbyname2 </refentrytitle><manvolnum> 3 </manvolnum></citerefentry> funções declaradas em <filename> netdb.h </filename>
struct hostent * gethostbyname(const char *name);
struct hostent * gethostbyname2(const char *name, int af);

struct hostent * gethostbyname(const char *name);
struct hostent * gethostbyname2(const char *name, int af);
Both return a pointer to the <varname>hostent</varname> structure, with much information about the domain. For our purposes, the <varname>h_addr_list[0]</varname> field of the structure points at <varname>h_length</varname> bytes of the correct address, already stored in the <emphasis>network byte order</emphasis>. Ambos retornam um ponteiro para o <varname> hostent </varname> estrutura, com muita informação sobre o domínio. Para nossos propósitos, o <varname> h_addr_list [0] </varname> campo da estrutura aponta para <varname> h_length </varname> bytes do endereço correto, já armazenados no <emphasis> ordem de bytes de rede </emphasis>
This allows us to create a much more flexible—and much more useful—version of our <application>daytime</application> program: Isso nos permite criar uma versão muito mais flexível - e muito mais útil - do nosso <application> dia </application> programa:
/*
* daytime.c
*
* Programmed by G. Adam Stanislav
* 19 June 2001
*/
#include &lt;stdio.h&gt;
#include &lt;string.h&gt;
#include &lt;sys/types.h&gt;
#include &lt;sys/socket.h&gt;
#include &lt;netinet/in.h&gt;
#include &lt;netdb.h&gt;

int main(int argc, char *argv[]) {
register int s;
register int bytes;
struct sockaddr_in sa;
struct hostent *he;
char buf[BUFSIZ+1];
char *host;

if ((s = socket(PF_INET, SOCK_STREAM, 0)) &lt; 0) {
perror("socket");
return 1;
}

bzero(&amp;sa, sizeof sa);

sa.sin_family = AF_INET;
sa.sin_port = htons(13);

host = (argc &gt; 1) ? (char *)argv[1] : "time.nist.gov";

if ((he = gethostbyname(host)) == NULL) {
herror(host);
return 2;
}

bcopy(he-&gt;h_addr_list[0],&amp;sa.sin_addr, he-&gt;h_length);

if (connect(s, (struct sockaddr *)&amp;sa, sizeof sa) &lt; 0) {
perror("connect");
return 3;
}

while ((bytes = read(s, buf, BUFSIZ)) &gt; 0)
write(1, buf, bytes);

close(s);
return 0;
}

/*
* daytime.c
*
* Programmed by G. Adam Stanislav
* 19 June 2001
*/
#include &lt;stdio.h&gt;
#include &lt;string.h&gt;
#include &lt;sys/types.h&gt;
#include &lt;sys/socket.h&gt;
#include &lt;netinet/in.h&gt;
#include &lt;netdb.h&gt;

int main(int argc, char *argv[]) {
register int s;
register int bytes;
struct sockaddr_in sa;
struct hostent *he;
char buf[BUFSIZ+1];
char *host;

if ((s = socket(PF_INET, SOCK_STREAM, 0)) &lt; 0) {
perror("socket");
return 1;
}

bzero(&amp;sa, sizeof sa);

sa.sin_family = AF_INET;
sa.sin_port = htons(13);

host = (argc &gt; 1) ? (char *)argv[1] : "time.nist.gov";

if ((he = gethostbyname(host)) == NULL) {
herror(host);
return 2;
}

bcopy(he-&gt;h_addr_list[0],&amp;sa.sin_addr, he-&gt;h_length);

if (connect(s, (struct sockaddr *)&amp;sa, sizeof sa) &lt; 0) {
perror("connect");
return 3;
}

while ((bytes = read(s, buf, BUFSIZ)) &gt; 0)
write(1, buf, bytes);

close(s);
return 0;
}
We now can type a domain name (or an <acronym>IP</acronym> address, it works both ways) on the command line, and the program will try to connect to its <emphasis>daytime</emphasis> server. Otherwise, it will still default to <systemitem class="fqdomainname">time.nist.gov</systemitem>. However, even in this case we will use <function>gethostbyname</function> rather than hard coding <systemitem class="ipaddress">192.43.244.18</systemitem>. That way, even if its <acronym>IP</acronym> address changes in the future, we will still find it. Agora podemos digitar um nome de domínio (ou um endereço <acronym>IP</acronym> , funciona nos dois sentidos) na linha de comando, e o programa tentará se conectar à sua <emphasis> dia </emphasis> servidor. Caso contrário, ainda será padrão para <systemitem class="fqdomainname"> time.nist.gov </systemitem> . No entanto, mesmo neste caso, vamos usar <function> gethostbyname </function> em vez de codificação rígida <systemitem class="ipaddress"> 192.43.244.18 </systemitem> . Dessa forma, mesmo que seu endereço <acronym>IP</acronym> mude no futuro, ainda vamos encontrá-lo.
Since it takes virtually no time to get the time from your local server, you could run <application>daytime</application> twice in a row: First to get the time from <systemitem class="fqdomainname">time.nist.gov</systemitem>, the second time from your own system. You can then compare the results and see how exact your system clock is: Como não é preciso tempo para aproveitar o tempo do seu servidor local, você pode executar <application> dia </application> duas vezes seguidas: primeiro para obter o tempo de <systemitem class="fqdomainname"> time.nist.gov </systemitem> , a segunda vez do seu próprio sistema. Você pode então comparar os resultados e ver como o relógio do sistema é exato:
<prompt>%</prompt> <userinput>daytime ; daytime localhost</userinput>


52080 01-06-20 04:02:33 50 0 0 390.2 UTC(NIST) *
2001-06-20T04:02:35Z
<prompt>%</prompt>
<prompt>%</prompt> <userinput>daytime ; daytime localhost</userinput>


52080 01-06-20 04:02:33 50 0 0 390.2 UTC(NIST) *
2001-06-20T04:02:35Z
<prompt>%</prompt>
As you can see, my system was two seconds ahead of the <acronym>NIST</acronym> time. Como você pode ver, o meu sistema estava dois segundos adiantado do tempo do <acronym>NIST</acronym> .
<function>getservbyname</function> <function> getservbyname </function>
Sometimes you may not be sure what port a certain service uses. The <citerefentry><refentrytitle>getservbyname</refentrytitle><manvolnum>3</manvolnum></citerefentry> function, also declared in <filename>netdb.h</filename> comes in very handy in those cases: Às vezes você pode não ter certeza de qual porta um determinado serviço usa. <citerefentry><refentrytitle> getservbyname </refentrytitle><manvolnum> 3 </manvolnum></citerefentry> função, também declarada em <filename> netdb.h </filename> é muito útil nesses casos:
struct servent * getservbyname(const char *name, const char *proto);
struct servent * getservbyname(const char *name, const char *proto);
The <varname>servent</varname> structure contains the <varname>s_port</varname>, which contains the proper port, already in <emphasis>network byte order</emphasis>. O <varname> servo </varname> estrutura contém o <varname> esporte </varname> , que contém a porta adequada, já em <emphasis> ordem de bytes de rede </emphasis>
Had we not known the correct port for the <emphasis>daytime</emphasis> service, we could have found it this way: Se não tivéssemos conhecido a porta correta para o <emphasis> dia </emphasis> serviço, poderíamos ter encontrado desta forma:
struct servent *se;
...
if ((se = getservbyname("daytime", "tcp")) == NULL {
fprintf(stderr, "Cannot determine which port to use.\n");
return 7;
}
sa.sin_port = se-&gt;s_port;

struct servent *se;
...
if ((se = getservbyname("daytime", "tcp")) == NULL {
fprintf(stderr, "Cannot determine which port to use.\n");
return 7;
}
sa.sin_port = se-&gt;s_port;
You usually do know the port. But if you are developing a new protocol, you may be testing it on an unofficial port. Some day, you will register the protocol and its port (if nowhere else, at least in your <filename>/etc/services</filename>, which is where <function>getservbyname</function> looks). Instead of returning an error in the above code, you just use the temporary port number. Once you have listed the protocol in <filename>/etc/services</filename>, your software will find its port without you having to rewrite the code. Você normalmente conhece a porta. Mas se você está desenvolvendo um novo protocolo, você pode testá-lo em uma porta não oficial. Algum dia, você registrará o protocolo e sua porta (se em nenhum outro lugar, pelo menos em sua porta). <filename> / etc / services </filename> , que é onde <function> getservbyname </function> parece). Em vez de retornar um erro no código acima, basta usar o número da porta temporária. Depois de ter listado o protocolo em <filename> / etc / services </filename> , seu software encontrará sua porta sem que você tenha que reescrever o código.
Concurrent Servers Servidores Simultâneos
Unlike a sequential server, a <emphasis>concurrent server</emphasis> has to be able to serve more than one client at a time. For example, a <emphasis>chat server</emphasis> may be serving a specific client for hours—it cannot wait till it stops serving a client before it serves the next one. Ao contrário de um servidor sequencial, um <emphasis> servidor concorrente </emphasis> tem que ser capaz de servir mais de um cliente de cada vez. Por exemplo, um <emphasis> servidor de bate-papo </emphasis> pode estar servindo um cliente específico por horas - ele não pode esperar até parar de servir um cliente antes de servir o próximo.
This requires a significant change in our flowchart: Isso requer uma mudança significativa em nosso fluxograma:
_ external ref='sockets/serv2' md5='__failed__' external ref='sockets/serv2' md5='__failed__'
+-----------------+
| Create Socket |
+-----------------+
|
+-----------------+
| Bind Port | Daemon Process
+-----------------+
| +--------+
+-------------+--&gt;| Init |
| | +--------+
+-----------------+ | |
| Exit | | +--------+
+-----------------+ | | Listen |
| +--------+
| |
| +--------+
| | Accept |
| +--------+
| | +------------------+
| +------&gt;| Close Top Socket |
| | +------------------+
| +--------+ |
| | Close | +------------------+
| +--------+ | Serve |
| | +------------------+
|&lt;--------+ |
+------------------+
| Close Acc Socket |
+--------+ +------------------+
| Signal | |
+--------+ +------------------+
| Exit |
+------------------+
+-----------------+
| Create Socket |
+-----------------+
|
+-----------------+
| Bind Port | Daemon Process
+-----------------+
| +--------+
+-------------+--&gt;| Init |
| | +--------+
+-----------------+ | |
| Exit | | +--------+
+-----------------+ | | Listen |
| +--------+
| |
| +--------+
| | Accept |
| +--------+
| | +------------------+
| +------&gt;| Close Top Socket |
| | +------------------+
| +--------+ |
| | Close | +------------------+
| +--------+ | Serve |
| | +------------------+
|&lt;--------+ |
+------------------+
| Close Acc Socket |
+--------+ +------------------+
| Signal | |
+--------+ +------------------+
| Exit |
+------------------+
<imageobject> <imagedata fileref="sockets/serv2"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Concurrent Server</phrase> </textobject> <imageobject><imagedata fileref="sockets/serv2"/></imageobject><textobject> &lt;_: literallayout-1 /&gt; </textobject><textobject><phrase> Servidor Concorrente </phrase></textobject>
We moved the <emphasis>serve</emphasis> from the <emphasis>daemon process</emphasis> to its own <emphasis>server process</emphasis>. However, because each child process inherits all open files (and a socket is treated just like a file), the new process inherits not only the <emphasis><quote>accepted handle,</quote></emphasis> i.e., the socket returned by the <function>accept</function> call, but also the <emphasis>top socket</emphasis>, i.e., the one opened by the top process right at the beginning. Nós mudamos o <emphasis> servir </emphasis> de <emphasis> processo daemon </emphasis> para o seu próprio <emphasis> processo do servidor </emphasis> . No entanto, como cada processo filho herda todos os arquivos abertos (e um soquete é tratado como um arquivo), o novo processo herda não apenas <emphasis><quote> aceito alça, </quote></emphasis> isto é, o soquete retornado pelo <function> aceitar </function> chamar, mas também o <emphasis> soquete superior </emphasis> , ou seja, aquele aberto pelo processo superior logo no início
However, the <emphasis>server process</emphasis> does not need this socket and should <function>close</function> it immediately. Similarly, the <emphasis>daemon process</emphasis> no longer needs the <emphasis>accepted socket</emphasis>, and not only should, but <emphasis>must</emphasis> <function>close</function> it—otherwise, it will run out of available <emphasis>file descriptors</emphasis> sooner or later. No entanto, o <emphasis> processo do servidor </emphasis> não precisa deste soquete e deve <function> fechar </function> isso imediatamente. Da mesma forma, <emphasis> processo daemon </emphasis> não precisa mais do <emphasis> soquete aceito </emphasis> , e não só deveria, mas <emphasis> devo </emphasis><function> fechar </function> ele - caso contrário, ficará sem disponível <emphasis> descritores de arquivos </emphasis> cedo ou tarde.
After the <emphasis>server process</emphasis> is done serving, it should close the <emphasis>accepted socket</emphasis>. Instead of returning to <function>accept</function>, it now exits. Depois de <emphasis> processo do servidor </emphasis> é feito servindo, ele deve fechar o <emphasis> soquete aceito </emphasis> . Em vez de voltar para <function> aceitar </function> , agora sai.
Under <trademark class="registered">UNIX</trademark>, a process does not really <emphasis>exit</emphasis>. Instead, it <emphasis>returns</emphasis> to its parent. Typically, a parent process <function>wait</function>s for its child process, and obtains a return value. However, our <emphasis>daemon process</emphasis> cannot simply stop and wait. That would defeat the whole purpose of creating additional processes. But if it never does <function>wait</function>, its children will become <emphasis>zombies</emphasis>—no longer functional but still roaming around. Sob <trademark class="registered"> UNIX </trademark> , um processo realmente não <emphasis> Saída </emphasis> . Em vez disso, <emphasis> retorna </emphasis> para o seu pai. Normalmente, um processo pai <function> esperar </function> s para seu processo filho e obtém um valor de retorno. No entanto, nossa <emphasis> processo daemon </emphasis> não pode simplesmente parar e esperar. Isso derrotaria todo o propósito de criar processos adicionais. Mas se isso nunca acontecer <function> esperar </function> , seus filhos se tornarão <emphasis> zumbis </emphasis> —Não mais funcional, mas ainda vagando por aí.
For that reason, the <emphasis>daemon process</emphasis> needs to set <emphasis>signal handlers</emphasis> in its <emphasis>initialize daemon</emphasis> phase. At least a <symbol>SIGCHLD</symbol> signal has to be processed, so the daemon can remove the zombie return values from the system and release the system resources they are taking up. Por essa razão, o <emphasis> processo daemon </emphasis> precisa definir <emphasis> manipuladores de sinal </emphasis> na sua <emphasis> inicializar daemon </emphasis> Estágio. Pelo menos um <symbol> SIGCHLD </symbol> sinal tem que ser processado, então o daemon pode remover os valores de retorno zumbis do sistema e liberar os recursos do sistema que eles estão usando.
That is why our flowchart now contains a <emphasis>process signals</emphasis> box, which is not connected to any other box. By the way, many servers also process <symbol>SIGHUP</symbol>, and typically interpret as the signal from the superuser that they should reread their configuration files. This allows us to change settings without having to kill and restart these servers. É por isso que o nosso fluxograma contém agora <emphasis> sinais de processo </emphasis> caixa, que não está conectada a nenhuma outra caixa. By the way, muitos servidores também processam <symbol> SIGHUP </symbol> e normalmente interpretam como o sinal do superusuário que devem reler seus arquivos de configuração. Isso nos permite alterar as configurações sem ter que matar e reiniciar esses servidores.
IPv6 Internals Internos IPv6

Loading…

New source string a year ago
Browse all component changes

Things to check

Mismatched colon

Source and translation do not both end with a colon

Reset

Trailing space

Source and translation do not both end with a space

Fix string

Reset

Glossary

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

Source information

Source string comment
(itstool) path: sect2/para
Source string location
book.translate.xml:6511
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/developers-handbook.po, string 1054