Translation

(itstool) path: imageobject/imagedata This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the file.
_
external ref='sockets/serv2' md5='__failed__'
45/450
Context English Portuguese (Brazil) State
/*
* daytime.c
*
* Programmed by G. Adam Stanislav
* 19 June 2001
*/
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

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)) < 0) {
perror("socket");
return 1;
}

bzero(&sa, sizeof sa);

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

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

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

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

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

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

close(s);
return 0;
}

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

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)) < 0) {
perror("socket");
return 1;
}

bzero(&sa, sizeof sa);

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

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

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

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

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

while ((bytes = read(s, buf, BUFSIZ)) > 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
IPv6/IPsec Implementation Implementação de IPv6 / IPsec
<personname> <firstname>Yoshinobu</firstname> <surname>Inoue</surname> </personname> <contrib>Contributed by </contrib> <personname><firstname> Yoshinobu </firstname><surname> Inoue </surname></personname><contrib> Contribuíram por </contrib>
This section should explain IPv6 and IPsec related implementation internals. These functionalities are derived from <link xlink:href="http://www.kame.net/">KAME project</link> Esta seção deve explicar os aspectos internos de implementação relacionados ao IPv6 e ao IPsec. Essas funcionalidades derivam <link xlink:href="http://www.kame.net/"> Projeto KAME </link>
IPv6 IPv6
Conformance Conformidade
The IPv6 related functions conforms, or tries to conform to the latest set of IPv6 specifications. For future reference we list some of the relevant documents below (<emphasis>NOTE</emphasis>: this is not a complete list - this is too hard to maintain...). As funções relacionadas ao IPv6 estão em conformidade ou tentam se adequar ao conjunto mais recente de especificações do IPv6. Para referência futura, listamos alguns dos documentos relevantes abaixo ( <emphasis> NOTA </emphasis> : esta não é uma lista completa - isso é muito difícil de manter ...).

Loading…

New source string a year ago
Browse all component changes

Things to check

Unchanged translation

Source and translation are identical

Reset

Glossary

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

Source information

Context
_
Source string comment
(itstool) path: imageobject/imagedata This is a reference to an external file such as an image or video. When the file changes, the md5 hash will change to let you know you need to update your localized copy. The msgstr is not used at all. Set it to whatever you like once you have updated your copy of the file.
Source string location
book.translate.xml:6508
String age
a year ago
Source string age
a year ago
Translation file
books/pt_BR/developers-handbook.po, string 1050