Hoje olho para o aspecto restante último de TCP/IP este curso coberturas: a interface de tomada de programação. Esta informação destina-se para transmitir o processo tinha de integrar uma aplicação a TCP/IP e como tal implica algumas funções de programação básicas. Não é necessário entender a programação para entender esta informação. As funções implicadas na tomada programando a interface ajudam-no a entender os passos que TCP/IP atravessa criando conexões e enviando dados.
Entender a interface de tomada é útil mesmo se nunca pretender escrever uma linha do código de TCP/IP, porque todas as aplicações trabalhará com o uso estes princípios e procedimentos. Depurar ou investigar um problema são muito mais fáceis quando entende o que está acontecendo atrás da interface de usuário. Hoje não tento mostrar a interface de tomada completa. Em vez disso só trato com as funções primárias necessárias para criar e manter uma conexão. Este capítulo não se destina para ser um guia de programação, também.
Como a interface de tomada original se desenvolveu para sistemas UNIX, o texto de hoje tem uma orientação decididamente baseada em UNIX. Contudo, os mesmos princípios aplicam à maior parte de outros sistemas operacionais aquele suporte TCP/IP.
TCP/IP tem sorte porque tem uma interface de programação de aplicação (API) bem definida, que dita como uma aplicação usa TCP/IP. Isto resolve um problema básico que ocorreu em muitos outros protocolos de comunicações, que têm várias aproximações do mesmo problema, cada um incompatível com o outro. O TCP/IP API é portátil (trabalha através de todos os sistemas operacionais e hardware que apoiam TCP/IP), independente da língua (não importa que língua usa para escrever a aplicação), e relativamente sem complicação.
A Tomada API desenvolveu-se na universidade da Califórnia em Berkeley como parte do seu BSD 4.1c versão de UNIX. Desde então o API modificou-se e realçou-se mas ainda conserva o seu sabor BSD. Não se exceder, AT&T (o rival de BSD no mercado UNIX) introduziu Transport Layer Interface (TLI) de TCP e vários outros protocolos. Uma das forças da Tomada que API e TLI são que não se desenvolveram exclusivamente para TCP/IP mas se destinam para o uso com vários protocolos de comunicações. A interface de Tomada permanece o API mais comum no uso atual, embora várias mais novas interfaces se estejam desenvolvendo.
A estrutura básica de todas as ordens de programação de tomada está com a estrutura única da entrada-saída UNIX. Com UNIX, tanto entrada e saída tratam-se como oleodutos simples, onde a entrada pode ser de algo como a produção pode ir em qualquer lugar. O sistema de entrada-saída UNIX é referido às vezes como o aberto lido escrevem fechar o sistema, porque aqueles são os passos que se executam para cada operação de entrada-saída, se implica um arquivo, um dispositivo ou um porto de comunicações.
Sempre que um arquivo se implique, o sistema operacional UNIX dá ao arquivo um descritor de arquivo, um pequeno número que unicamente identifica o arquivo. Um programa pode usar este descritor de arquivo para identificar o arquivo em qualquer momento. (O mesmo mantém-se verdadeiro para um dispositivo; o processo é o mesmo.) Uma operação de arquivo usa uma função aberta para devolver o descritor de arquivo, que se usa para o lido (dados de transferência ao processo do usuário) ou escreva (dados de transferência do processo de usuário ao arquivo) que a funções, seguidas de uma função fechada terminem a operação de arquivo. A função aberta toma um nome de arquivo como um argumento. Os lidos e escrevem que a funções usem o número descritivo de arquivo, o endereço do buffer no qual ler ou escrever a informação e o número de bytes implicados. A função fechada usa o descritor de arquivo. O sistema é fácil usar e simples trabalhar com.
TCP/IP usa a mesma ideia, confiando em números para identificar unicamente um ponto final de comunicações (uma tomada). Sempre que o número de tomada se use, o sistema operacional pode resolver o número de tomada ao conector físico. Uma diferença essencial entre um descritor de arquivo e um número de tomada é que a tomada necessita que algumas funções se executem antes do estabelecimento da tomada (como inicialização). Em techno-falam, "um descritor de arquivo ata a um arquivo específico ou dispositivo quando a função aberta se chama, mas a tomada pode criar-se sem atá-los a um destino específico em absoluto (necessário para UDP) ou atá-los depois (para TCP quando o endereço remoto se fornece)". O mesmo abre-se lido escrevem fechar o procedimento usa-se com tomadas.
O processo usou-se de fato literalmente com as primeiras versões de TCP/IP. Um arquivo especial chamou/dev/tcp usou-se como o motorista de dispositivo. A complexidade acrescentada transmitindo em rede fez esta aproximação desajeitada, entretanto, portanto uma biblioteca de funções especiais (o API) se desenvolveu. Os passos essenciais do aberto, leia, escreva, e perto ainda se seguem no protocolo API.
Há três tipos de interfaces de tomada definidas no TCP/IP API. Uma tomada pode usar-se para comunicações de corrente TCP, nas quais uma conexão entre duas máquinas se cria. Pode usar-se para comunicações de datagrama UDP, um método connectionless da informação passante entre máquinas usando pacotes de um formato predestinado. Ou pode usar-se como um processo de datagrama cru, no qual os datagramas dão volta à camada TCP/UDP e vão diretamente a IP. O último tipo resulta do fato que a tomada API não se desenvolveu exclusivamente para TCP/IP.
A presença dos três tipos de interfaces pode levar a problemas com alguns parâmetros que dependem exclusivamente do tipo da interface. Sempre deve ter em mente ou TCP ou UDP usa-se.
Há seis comunicações básicas ordena que a tomada API se dirija pela camada TCP:
As seis operações são lógicas e usadas como esperaria. Os detalhes de cada passo podem implicar-se bastante, mas a operação básica permanece o mesmo. Muitas das funções viram-se durante prévios dias tratando com protocolos específicos em algum detalhe. Algumas funções (tal tão aberto) compreendem várias outras funções que estão disponíveis se necessário (como estabelecimento de cada fim da conexão em vez de ambos os fins ao mesmo tempo).
Apesar da definição formal das funções dentro das especificações API, nenhum método formal se dá para como implementá-los. Há duas escolhas lógicas: síncrono, ou bloqueio, no qual a aplicação espera pela ordem de concluir antes da execução que continua; e assíncrono, ou não-bloqueio, no qual a aplicação continua realizando enquanto a função de API se processa. No último caso, uma chamada da função além disso na execução da aplicação pode verificar o êxito das funções API e códigos de retorno.
O problema com o método síncrono ou que bloqueia consiste em que a aplicação deve esperar pela chamada da função concluir. Se os intervalos se implicarem, isto pode causar um atraso perceptível do usuário.
Transmission Control Block (TCB) é uma estrutura de dados complexa que contém detalhes sobre uma conexão. O TCB cheio tem mais de cinquenta campos nele. O leiaute exato e os conteúdos do TCB não são necessários para o material de hoje, mas a existência do TCB e a natureza da informação que mantém são-chave ao comportamento da interface de tomada.
O API deixa um usuário criar uma tomada sempre que necessário com uma chamada da função simples. A função necessita que a família do protocolo se use com a tomada (portanto o sistema operacional sabe que tipo da tomada destinar e como decifrar a informação), o tipo da comunicação necessitada, e o protocolo específico. Tal chamada da função escreve-se como se segue:
socket(family, type, protocol)
A família do protocolo de fato especifica como os endereços se interpretam. Os exemplos de famílias são TCP/IP (codificado como AF_INET), AppleTalk de Apple (AF_APPLETALK) e sistemas de arquivos UNIX (AF_UNIX). O protocolo exato dentro da família especifica-se como o parâmetro de protocolo. Quando usado, especificamente indica o tipo do serviço que deve usar-se.
O parâmetro de tipo indica o tipo de comunicações usadas. Pode ser um serviço de datagrama connectionless (codificado como SOCK_DGRAM), um serviço de entrega de corrente (SOCK_STREAM) ou tipo cru (SOCK_RAW). O resultado da chamada da função é um número inteiro que pode destinar-se a uma variável da nova verificação.
Como uma tomada pode criar-se sem qualquer atadura a um endereço, deve haver uma chamada da função concluir este processo e estabelecer a conexão cheia. Com o protocolo TCP/IP, a função de tomada não fornece ao número de porto local, o porto de destino ou o endereço IP do destino. A função atar chama-se para estabelecer o endereço de porto local da conexão.
Algumas aplicações (especialmente em um servidor) querem usar um porto específico para uma conexão. Outras aplicações são contentes de deixar o software de protocolo destinar um porto. Um porto específico pode solicitar-se na função atar. Se estiver disponível, o software aloca-o e devolve a informação sobre porto. Se o porto não pode alocar-se (poderia estar no uso), um código de retorno indica um erro na nomeação de porto.
A função atar tem o seguinte formato:
bind(socket, local_address, address_length)
a tomada é o número de número inteiro da tomada à qual atar se conclui; o local_address é o endereço local ao qual atar se executa; e o address_length é um número inteiro que dá o comprimento do endereço em bytes. O endereço não se devolve como um número simples mas manda mostrar a estrutura na Figura 14.1.
A figura 14.1. Estrutura de endereço usada pela tomada API.
A estrutura de dados de endereço (que se chama sockaddr normalmente chamado do endereço de tomada) tem um campo de Família de Endereço de 16 bits que identifica a família de protocolo do endereço. A entrada neste campo determina o formato do endereço no seguinte campo (que poderia conter outra informação do que o endereço, dependendo de como o protocolo definiu o campo). O campo de Endereço pode estar à altura de 14 bytes no comprimento, embora a maior parte de protocolos não precisem deste montante do espaço.
O uso de uma estrutura de dados em vez de um endereço simples tem as suas raízes no sistema operacional UNIX e a linguagem de programação C estreitamente aliada. A estrutura formal do endereço de tomada permite a programas C usar uma união de estruturas de todas as famílias de endereço possíveis. Isto salva um montante considerável da codificação em aplicações.
TCP/IP tem um endereço de família de 2, depois do qual o campo de Endereço contém tanto um número de porto de protocolo (16 bits) como o endereço IP (32 bits). O resto oito bytes é não usado. Isto mostra-se na Figura 14.2. Como a família de endereço define como o campo de Endereço se decifra, não deve haver problema com aplicações TCP/IP entendendo as duas partes da informação no campo de Endereço.
A figura 14.2. A estrutura de endereço de TCP/IP.
Depois que um endereço de tomada local e o número de porto destinaram-se, a tomada de destino pode unir-se. Uma conexão uma terminada menciona-se como estar em um estado desconexo, ao passo que uma conexão duas terminada (completa) está em um estado ligado. Depois de uma função atar, um estado desconexo existe. Para ficar unida, a tomada de destino deve acrescentar-se para concluir a conexão.
Os protocolos de Connectionless como UDP não necessitam que um estado ligado funcione. Podem, contudo, unir-se para permitir a transferência entre as duas tomadas sem ter necessidade de especificar o endereço de destino cada vez. Os protocolos baseados na conexão como TCP necessitam que ambos os fins da conexão se especifiquem.
Para estabelecer uma conexão a uma tomada remota, a função unir usa-se. O formato da função unir é
connect(socket, destination_address, address_length)
A tomada é o número de número inteiro da tomada à qual unir-se; o destination_address é a estrutura de dados de endereço de tomada do endereço de destino (usando o mesmo formato que mostrado na Figura 14.1); e o address_length é o comprimento do endereço de destino em bytes.
A maneira na qual unem funções é dependente do protocolo. Para TCP, una-se estabelece a conexão entre os dois endpoints e devolve a informação sobre a tomada remota à aplicação. Se uma conexão não puder estabelecer-se, uma mensagem de erro gera-se. Para um protocolo connectionless como UDP, a função unir ainda é necessária mas só guarda o endereço de destino da aplicação.
A ordem aberta prepara um porto de comunicações para comunicações. Isto é uma alternativa para a combinação das funções mostradas anteriormente, usadas por aplicações com objetivos específicos. Há realmente três espécies de ordens abertas, duas das quais fazem que um servidor receba pedidos de entrada e o terceiro usado por um cliente para iniciar um pedido. Com cada ordem aberta, um TCB cria-se para aquela conexão.
Três ordens abertas são um aberto passivo não especificado (que permite a um servidor esperar por um pedido de conexão de qualquer cliente), totalmente especificado passivo aberto (que permite a um servidor esperar por um pedido de conexão de um cliente específico), e um aberto ativo (que inicia uma conexão com um servidor). A entrada e saída esperada de cada ordem mostra-se na Tabela 14.1.
|
Datilografar |
Entrada |
Produção |
|
Não especificado |
porto local |
nome de conexão local |
|
passivo aberto |
Opcional: intervalo, precedência, segurança, tamanho de segmento máximo |
nome de conexão local |
|
Totalmente especificado passivo aberto |
porto local, endereço IP remoto, porto remoto Opcional: intervalo, precedência, segurança, tamanho de segmento máximo |
nome de conexão local |
|
Ativo aberto |
porto local, endereço IP de destino, porto de destino Opcional: intervalo, precedência, segurança, tamanho de segmento máximo |
nome de conexão local |
Quando uma ordem aberta se emite por uma aplicação, o grupo de funções dentro da interface de tomada realiza-se para fundar o TCB, iniciar o número de tomada e estabelecer valores preliminares das variáveis usadas no TCB e a aplicação.
A ordem aberta passiva emite-se por um servidor para esperar por pedidos de entrada. Com o TCP protocolo (baseado na conexão), as questões abertas passivas as seguintes chamadas da função:
A ordem aberta ativa emite-se por um cliente. Para TCP, emite duas funções:
Se o porto exato para usar se especificar como parte da ordem aberta, uma chamada da função atar substitui a função unir.
Há cinco funções dentro da Tomada API para enviar dados por uma tomada. Estes são enviam, sendto, sendmsg, escrevem, e writev. Não surpreendentemente, todas estas funções enviam dados da aplicação a TCP. Fazem isto por um buffer criado pela aplicação (por exemplo, poderia ser um endereço de memória ou uma cadeia de caráter), passando o buffer inteiro a TCP. Enviar, escreva, e trabalho de funções de writev só com uma tomada ligada porque não têm provisão para especificar um endereço de destino dentro da sua chamada da função.
O formato da função enviar é simples. Toma o número de conexão de tomada local, o endereço de buffers da mensagem a enviar-se, o comprimento da mensagem em bytes, uma bandeira de Empurrão e uma bandeira Urgente como parâmetros. Um intervalo opcional poderia especificar-se. Nada se devolve como produção da função enviar. O formato é
send(socket, buffer_address, length, flags)
O sendto e as funções de sendmsg são semelhantes exceto permitem a uma aplicação enviar uma mensagem por uma tomada desconexa. Ambos eles necessitam o endereço de destino como parte da sua chamada da função. A função de sendmsg é mais simples no formato do que a função de sendto, principalmente porque outra estrutura de dados se usa para manter a informação. A função de sendmsg muitas vezes usa-se quando o formato da função de sendto seria desajeitado e ineficiente no código da aplicação. Os seus formatos são
sendto(socket, buffer_address, length, flags, destination, address_length) sendmsg(socket, message_structure, flags)
Dois parâmetros últimos na função de sendto são o endereço de destino e o comprimento do endereço de destino. O endereço especifica-se usando o formato mostrado na Figura 14.1. O message_structure da função de sendmsg contém a informação deixada de fora da chamada da função sendto. O formato da estrutura de mensagem mostra-se na Figura 14.3.
A figura 14.3. A estrutura de mensagem usa-se por sendmsg.
Os campos na estrutura de mensagem sendmsg dão o endereço de tomada, o tamanho do endereço de tomada, um ponteiro para o iovector, que contém a informação sobre a mensagem a enviar-se, o comprimento do iovector, o endereço de destino e o comprimento do endereço de destino.
A função de sendmsg usa a estrutura de mensagem para simplificar a chamada da função. Também tem outra vantagem: a função de recvmsg usa a mesma estrutura, simplificando o código de uma aplicação.
O iovector é um endereço de uma tabela que aponta para a mensagem a enviar-se. A tabela é grupo de ponteiros para os bytes que compreendem a mensagem. O formato do iovector é simples. Para cada endereço de 32 bits a uma posição de memória com um pedaço da mensagem, um campo de 32 bits correspondente mantém o comprimento da mensagem naquela posição de memória. Este formato repete-se até que a mensagem inteira se especifique. Isto mostra-se na Figura 14.4. O formato de iovector permite a uma mensagem não-contígua enviar-se. Em outras palavras, a primeira parte da mensagem pode estar em uma posição na memória, e o resto separa-se por outra informação. Isto pode ser útil porque salva a aplicação de copiar mensagens longas em uma posição contígua.
A figura 14.4. O formato de iovector.
A função escrever toma três argumentos: o número de tomada, o endereço de buffers da mensagem a enviar-se, e o comprimento da mensagem para enviar. O formato da chamada da função é
write(socket, buffer_address, length)
A função de writev é semelhante para escrever exceto ele usa o iovector para manter a mensagem. Isto deixa-o enviar uma mensagem sem copiá-lo em outro endereço de memória. O formato de writev é
writev(socket, iovector, length)
onde o comprimento é o número de entradas em iovector.
O tipo da função escolhida para enviar dados por uma tomada depende do tipo da conexão usada e o nível da complexidade da aplicação. Até um grau considerável, também é uma escolha pessoal do programador.
Não surpreendentemente, porque há cinco funções para enviar dados por uma tomada, há cinco funções correspondentes para receber dados: leia, readv, recv, recvfrom, e recvmsg. Todos eles aceitam dados de entrada de uma tomada em um buffer de recepção. O buffer receber então pode transferir-se de TCP para a aplicação.
A função lida é a mais simples e pode usar-se só quando uma tomada se une. O seu formato é
read(socket, buffer, length)
O primeiro parâmetro é o número da tomada ou um descritor de arquivo no qual ler os dados, seguidos do endereço de memória no qual guardar os dados de entrada e o número máximo de bytes a ler-se.
Como com writev, a ordem de readv permite a mensagens de entrada colocar-se em posições de memória não-contíguas por meio do uso de um iovector. O formato de readv é
readv(socket, iovector, length)
o comprimento é o número de entradas no iovector. O formato do iovector é o mesmo como mencionado anteriormente e mostrado na Figura 14.4.
A função de recv também pode usar-se com tomadas ligadas. Tem o formato
recv(socket, buffer_address, length, flags)
que corresponde aos argumentos da função enviar.
O recvfrom e as funções de recvmsg permitem a dados ler-se em uma tomada desconexa. Os seus formatos incluem o endereço do remetente:
recvfrom(socket, buffer_address, length, flags, source_address, address_length) recvmsg(socket, message_structure, flags)
A estrutura de mensagem na função de recvmsg corresponde à estrutura em sendmsg. (Ver a Figura 14.3.)
Uma aplicação de servidor que espera que clientes lhe entrem tem de criar uma tomada (usando tomada), atá-lo a um porto (com atam), logo espere por pedidos de entrada em dados. A função escutar trata problemas que podem ocorrer com este tipo do comportamento estabelecendo uma fila de pedidos de conexão de entrada. A fila previne gargalos e choques, tal como quando um novo pedido chega antes que um prévio se tenha completamente tratado, ou dois pedidos chegam simultaneamente.
A função escutar estabelece um buffer para fazer fila pedidos de entrada, por meio disso evitando perdas. A função deixa a tomada aceitar pedidos de conexão de entrada, que se enviam todos à fila do futuro processamento. O formato da função é
listen(socket, queue_length)
onde queue_length é o tamanho do buffer de entrada. Se o buffer tiver o quarto, os pedidos de entrada em conexões acrescentam-se ao buffer e a aplicação pode tratar com eles na ordem da recepção. Se o buffer for cheio, o pedido de conexão rejeita-se.
Depois que o servidor usou escutam para fundar a fila de pedido de conexão de entrada, a função aceitar usa-se para esperar de fato por uma conexão. O formato da função é
accept(socket, address, length)
a tomada é a tomada na qual aceitar pedidos; o endereço é um ponteiro para uma estrutura semelhante à Figura 14.1; e o comprimento é um ponteiro para um número inteiro mostrando o comprimento do endereço.
Quando um pedido de conexão se recebe, o protocolo coloca o endereço do cliente na posição de memória indicada pelo parâmetro de endereço e o comprimento daquele endereço na posição de comprimento. Então cria uma nova tomada que tem o cliente e servidor unido em conjunto, retornando a descrição de tomada ao cliente. A tomada na qual o pedido se recebeu permanece aberta para outros pedidos de conexão. Isto permite a múltiplos pedidos em uma conexão processar-se, ao passo que se aquela tomada se fechou com cada pedido de conexão, só um processo de cliente/servidor pode tratar-se de uma vez.
Uma ocorrência especial possível deve tratar-se em sistemas UNIX. É possível para um processo único esperar por um pedido de conexão em múltiplas tomadas. Isto reduz o número de processos que controlam tomadas, por meio disso abaixando o montante de em cima os usos de máquina. Para prover este tipo do processo, a função escolhida usa-se. O formato da função é
select(num_desc, in_desc, out_desc, excep_desc, timeout)
o num_desc é o número de tomadas ou descritores que se controlam; o in_desc e out_desc são ponteiros para um bocado a máscara que indica as tomadas ou descritores de arquivo para controlar para a entrada e saída, respectivamente; o excep_desc é um ponteiro para um bocado a máscara que especifica as tomadas ou descritores de arquivo para verificar condições de exceção; e o intervalo é um ponteiro para um número inteiro que indica quanto tempo esperar (um valor de 0 indica para sempre). Para usar a função escolhida, um servidor cria todas as tomadas necessárias primeiro, então chama escolhido para determinar quais são para entrada, produção e exceções.
Várias funções de posição usam-se para obter a informação sobre uma conexão. Podem usar-se em qualquer momento, embora se usem tipicamente para estabelecer a integridade de uma conexão em caso de problemas ou controlar o comportamento da tomada.
As funções de posição necessitam o nome da conexão local, e devolvem o grupo de informação, que poderia incluir os nomes de tomada locais e remotos, nome de conexão local, receber e enviar estados de janela, número de buffers que esperam por um reconhecimento, o número de buffers que esperam por dados e valores atuais do estado urgente, precedência, segurança e variáveis de intervalo. A maioria desta informação lê-se em Transmission Control Block (TCB). O formato da informação e os conteúdos exatos varia ligeiramente, dependendo da implementação.
A função getsockopt permite a uma aplicação questionar a tomada da informação. O formato de função é
getsockopt(socket, level, option_id, option_result, length)
a tomada é o número da tomada; o nível indica se a função se refere à própria tomada ou o protocolo que o usa; o option_id é um número inteiro único que identifica o tipo da informação solicitada; o option_result é um ponteiro para uma posição de memória onde a função deve colocar o resultado da pergunta; e o comprimento é o comprimento do resultado.
A função de setsockopt correspondente deixa a aplicação estabelecer um valor da tomada. O formato da função é o mesmo como getsockopt exceto que option_result aponta para o valor que deve estabelecer-se, e o comprimento é o comprimento do valor.
Duas funções fornecem a informação sobre o endereço local de uma tomada. A função de getpeername devolve o endereço do fim remoto. A função de getsockname devolve o endereço local de uma tomada. Têm os seguintes formatos:
getpeername(socket, destination_address, address_length) getsockname(socket, local_address, address_length)
Os endereços em ambas as funções são ponteiros para uma estrutura do formato mostrado na Figura 14.1.
Duas funções de nome do host de BSD UNIX são gethostname e sethostname, que permitem a uma aplicação obter o nome do anfitrião e estabelecer o nome do host (se as permissões permitirem). Os seus formatos são como se segue:
sethostname(name, length) gethostname(name, length)
O nome é o endereço de uma tabela que mantém o nome, e o comprimento é um número inteiro que dá o comprimento do nome.
Um jogo semelhante de funções provê nomes de domínio. As funções setdomainname e getdomainname permitem a uma aplicação obter ou estabelecer os nomes de domínio. Os seus formatos são
setdomainname(name, length) getdomainname(name, length)
Os parâmetros são o mesmo como com o sethostname e funções de gethostname, exceto o formato do nome (que reflete o formato de nome de domínio).
A função fechada fecha uma conexão. Só necessita que ao nome de conexão local conclua o processo. Também cuida do TCB e lança qualquer variável criada pela conexão. Nenhuma produção se gera.
A função fechada inicia-se com a chamada
close(socket)
onde o nome de tomada se necessita. Se uma aplicação terminar anormalmente, o sistema operacional fecha todas as tomadas que estiveram abertas antes da terminação.
A função de aborto instrui TCP para descartar todos os dados que atualmente residem em enviam e recebem buffers e fecham a conexão. Toma o nome de conexão local como introduzido. Nenhuma produção se gera. Esta função pode usar-se em caso de rotinas de paralisação de emergência, ou em caso de um fracasso fatal da conexão ou software associado.
A função de aborto implementa-se normalmente pelo fim () chamada, embora algumas instruções especiais pudessem estar disponíveis com implementações diferentes.
UNIX tem duas chamadas de sistema que podem afetar tomadas: garfo e exec. Ambos usam-se frequentemente por desenvolvedores UNIX por causa do seu poder. (De fato, os garfos são um dos instrumentos mais potentes ofertas de UNIX e aquela de que a maior parte de outros sistemas operacionais necessitam.) Para a simplicidade, trato com as duas funções como se executem a mesma tarefa.
Uma chamada de garfo cria uma cópia da aplicação existente como um novo processo e começa a realizá-la. O novo processo tem descritores de arquivo de todo o original e informação sobre tomada. Isto pode causar um problema se o programador aplicado não considerou o fato que dois (ou mais) os processos tentam usar a mesma tomada (ou arquivo) simultaneamente. Por isso, as aplicações que podem bifurcar-se têm de considerar conflitos potenciais e código em volta deles verificando a posição de tomadas compartilhadas.
O próprio sistema operacional guarda uma mesa de cada tomada e quantos processos têm o acesso a ele. Um balcão interno incrementa-se ou decremented com a chamada da função aberta ou fechada de cada processo da tomada. Quando o processo último usando uma tomada se termina, a tomada fecha-se permanentemente. Isto impede aquele processo forcado de fechar uma tomada quando o seu original ainda o usa.
Hoje viu as funções básicas executadas pela tomada API durante o estabelecimento da chamada de UDP ou um TCP. Também viu as funções que estão disponíveis para programadores aplicados. Embora o tratamento tenha estado em um alto nível, deve ser capaz de ver que o trabalho com tomadas não é uma tarefa complexa, confusa. De fato, a programação de tomada é surpreendentemente fácil uma vez que a tentou.
Não todo o mundo quer escrever TCP ou aplicações UDP, naturalmente. Contudo, entendendo os fundamentos da tomada API ajuda em compreensão do protocolo e resolução de problemas. Se se interessar na programação de tomadas, um dos melhores livros sobre o sujeito é a Programação de Rede UNIX, por W. Richard Stevens (Macmillan).
Para que a interface de tomada se usa?
A interface de tomada permite-lhe escrever aplicações que fazem o ótimo uso da família TCP/IP de protocolos. Sem ele, precisaria de outra camada da aplicação para traduzir chamadas do seu programa a chamadas de TCP/IP.
Qual é a diferença entre bloqueio e não-bloqueio de funções?
Uma função de bloqueio espera pela função para terminar antes de permitir a aplicação continuar. Uma função de não-bloqueio permite à aplicação continuar realizando enquanto a função se executa. Ambos têm usos importantes em aplicações.
O que faz a atadura fazem?
A atadura faz uma conexão lógica entre uma tomada e a aplicação. Sem ele, a aplicação não pode acessar a tomada.
O que acontece quando uma ordem aberta ativa se realiza?
Uma ordem aberta ativa cria uma tomada e ata-a, então as questões a unem a chamada de identificar o endereço IP e porto. A ordem aberta ativa então tenta estabelecer comunicações.
Qual é a diferença entre um aborto e uma operação fechada?
Uma operação fechada fecha uma conexão. Um aborto abandona quaisquer comunicações estão atualmente em andamento e fecha a conexão. Com um aborto, qualquer informação em recebe buffers descarta-se.
