Prof V Vargas, I S T Pg 1/97

Transcrição

1 Prof V Vargas, I S T Pg 1/97

2 Prof V Vargas, I S T Pg 2/97

3 Prof V Vargas, I S T Pg 3/97 Introdução a TCP / UDP {TCPIntroduction.doc} O objectivo da infra-estrutura da Internet é viabilizar aplicações distribuídas entre computadores e outros dispositivos - interligados por uma rede ou por várias redes interligadas entre si. Entre essas aplicações, contam-se: o Correio Electrónico, o acesso a Documentos da Web, a Transferência de ficheiros, o acesso a Máquinas remotas, a Compra em lojas electrónicas, etc A generalidade dessas aplicações manifesta requisitos comuns, como sejam: a robustez contra eventuais falhas da Rede, a sua disponibilidade mesmo aquando de elevado tráfego na Rede... Já outras aplicações, como seja a comunicação de áudio ou vídeo em tempo real, têm outras exigências Há que evitar aos desenhadores dessas aplicações o gastar tempo a reinventar a roda como seja conceber e codificar procedimentos de recuperação de eventuais erros nos Dados recebidos; pelo que, logo nos primórdios da comunicação entre computadores, foram concebidos dois protocolos, a saber: - TCP (Transmission Control Protocol, cfr RFC Sep 1981); - UDP (Unreliable Data Protocol, cfr RFC 768). Eles constituem a plataforma de base da Internet: o desenhador de uma aplicação distribuída sabe que já existe uma biblioteca de procedimentos (library) que, em particular, o liberta quase plenamente da preocupação com eventuais falhas. Pelo que faz sentido dedicar algum tempo àqueles dois protocolos. E exactamente o que será feito nas linhas seguintes. Designando de Entidade-TCP/UDP (ou, mais abreviadamente, Entidade) o hardware/software que em cada máquina materializa essa plataforma, a questão a abordar é: como funciona ela? como é o diálogo entre duas Entidades, sejam W e E, recorrendo a tais protocolos? e quais as interacções, em cada máquina, com os níveis adjacentes Superior/Utilizador(Aplicação) e Inferior/Nível-Rede(IP)? Sumário das características de TCP e UDP: São, ambos, protocolos do nível transporte (host-to-host, end-to-end) - no sentido de que providenciam uma plataforma de comunicação entre processos correndo entre máquinas distintas. A comunicação de Dados é feita através do encapsulamento dos respectivos octetos em Segmentos; que são enviados em ambas as direcções, eventualmente em simultâneo. Em ordem a proporcionar o acesso concorrente à Rede por parte dos vários processos correndo na máquina, ambos providenciam a multiplexagern da comunicação de Dados através do, em geral, único endereço-ip que lhe foi atribuído. Para tal, ambos providenciam um conjunto de Portos. Alguns deles estão pré-reservados para Aplicações específicas - mormente aquelas que mais frequentemente são usadas; ao menos para algumas delas (ex.: Correio Electrónico, Acesso à Web), eles são públicos. Cada par endereço-ip/porto é designado de socket. Um processo de Aplicação que queira aceder à Rede (através de TCP e/ou UDP) fá-lo sempre através de um socket. Nem TCP nem IIDP são picuinhas nos requisitos ao nível inferior: ambos aceitam um serviço de transporte de datagramas, isto é: susceptível a erros, perdas, duplicados e falhas na sequencialidade. Mas existem diferenças entre TCP e UDP... TCP providencia a comunicação de um fluxo contínuo de octetos de Dados que o transmissor encapsula em Segmentos a seu bel-prazer. TCP providencia uma comunicação robusta contra eventuais erros nas Redes; isto é, recupera de eventuais erros, incluindo perdas, duplicados ou falhas na sequencialidade nos Segmentos recebidos; e providencia controlo de fluxo, isto é: permite ao destino limitar o ritmo a que a fonte lhe envia Dados. No sentido de lograr tais controlos, TCP e orientado à conexão, isto é, subentende um princípio, um meio e um fim; no entrementes, inicializa e actualiza as variáveis de estado pertinentes a esses controlos. Uma conexão-tcp (ou, mais abreviadamente, conexão) é identificada por um par de sockets, um em cada máquina. Pelo que, através de um dado socket e ancorando-se em sockets remotos distintos! - poderão estar estabelecidas várias conexões. UDP, ao invés, é um protocolo não-orientado à conexão; procura servir o pedido de entrega de dados o melhor que lhe for possível, mas não providencia nem controlo de erro nem controlo de fluxo nem controlo de congestão.

4 Prof V Vargas, I S T Pg 4/97

5 Prof V Vargas, I S T Pg 5/97 Berkeley Sockets {BerkeleySockets.doc} Considere o leitor dois Programas de Aplicação, correndo em duas máquinas distintas, em vias de trocar dados entre si. A um deles, cabe a responsabilidade de iniciar a comunicação; ao outro, a de lhe responder favoravelmente; após o que trocarão os dados que entenderem Dados os papéis relativos assumidos no começo da conversação, e sem perda de generalização, será pacífico designá-los, respectivamente, de Cliente e Servidor. Que estratégia seguir em ordem a proporcionar a comunicação entre ambos? Eis uma constatação inicial: vista do interior de um qualquer daqueles Programas, a operação de enviar dados ao parceiro remoto assemelha-se à escrita em um ficheiro local: em ambos os casos, trata-se de "pegar" em dados no espaço RAM coberto pelo Programa e de os exportar para o exterior - para um ficheiro em disco ou para uma máquina remota Esta semelhança sugere naturalmente o seguinte: 1) tal como a escrita em um ficheiro envolve um descritor (obtido por fp=fopen()), assim será expectável associar à comunicação de dados um descritor para acompanhar a sua evolução; 2) e tal como, para designar esse ficheiro, se requere um pathname, assim para caracterizar o destino remoto se torna imprescindível uma identificação apropriada. Que "tijolos" deverão fazer parte dessa identificação "de um destino remoto"? Em primeiro lugar, é claro, o endereço-ip da máquina em que ele reside: a Rede precisa dele para encaminhar os dados até ela Mas ele nem sempre chega: poderão co-existir naquela máquina-destino vários processos correndo em simultâneo - e é preciso identificar com precisão a qual deles se destinam os dados que vão chegando da Rede: deverão os dados ser passados ao Servidor de Páginas-Web, ou ao Servidor de Correio-Electrónico, ou ao Servidor de Transferência-de- Ficheiros, ou a quê mais? Convirá então, ao menos, ter em conta também a qual desses Programas devem os dados ser entregues. O software maioritariamente usado na Internet para materializar estes conceitos dá pelo nome de Berkeley: o desenhador de uma aplicação distribuída sabe que já existe uma biblioteca de procedimentos (library) do Sistema Operativo que, em particular, o liberta quase totalmente da preocupação com eventuais falhas. Neste, o identificador dos recursos de comunicação (do nível Transporte) dá pelo nome de socket; e a discriminação, no seio de uma máquina, da fonte/destino dos dados, é um número inteiro que dá pelo nome de Porto. Considerados dois Programas em vias de comunicação, há naturalmente que ter em conta dois pares endereço- IP/Porto: - o par endereço-ip/porto que identifica o Cliente; - o par endereço-ip/porto que identifica o Servidor. Os endereços-ip tornam possível à Rede encaminhar os dados até à máquina onde reside o destino (Cliente ou Servidor) dos dados enviados; quanto aos Portos, eles discriminam, no seio da máquina onde aportarem esses dados, ao menos qual o Processo a que enfim devem ser entregues. Um Processo poderá, pelo mesmo Porto, comunicar com mais que um Processo remoto correndo na mesma máquina ou em máquinas distintas. Chegados a este ponto, é hora de generalizar o horizonte de reflexão: tal como um mesmo Programa pode aceder a vários ficheiros em simultâneo, cada qual com o seu descritor, assim ele pode comunicar com vários parceiros remotos "em simultâneo", através de vários sockets: 1) Por um lado, um mesmo Servidor poderá estar sendo acedido "em simultâneo" por vários Clientes (por exemplo, vários PCs geograficamente dispersos acedendo a uma Caixa-de-Correio comum). É óbvio que o par endereço-ip/porto do Cliente proporciona ao Servidor o conhecimento de qual a origem da informação submetida e, portanto, e se fôr caso disso, a quem, entre todos aqueles Clientes, devolver a subsequente réplica 2) Por outro lado, poderá um mesmo Cliente estar acedendo a vários Servidores "em simultâneo" (por exemplo, um computador acedendo, por difusão, aos Agentes de um Sistema-de-Informação distribuído). É óbvio que o par endereço-ip/porto do Servidor proporciona ao Cliente o conhecimento de qual o Servidor responsável pela réplica recebida.

6 Prof V Vargas, I S T Pg 6/97

7 Prof V Vargas, I S T Pg 7/97 Sockets UDP {UDPSockets.doc} Um serviço providenciado pela biblioteca de primitivas Berkeley-Sockets é o assim denominado UDP. No que se segue, abordam-se as etapas a cumprir na troca da informação entre dois parceiros suportada em sockets- Berkeley UDP; isso será feito acompanhando o diagrama temporal da figura Como se patenteia, ela envolve cinco primitivas, a saber: socket, bind, sendto, recvfrom e close. Socket: Previamente ao envio/recepção de dados, ambos - Programas Cliente e Servidor - têm que reservar (temporariamente) os recursos precisos. Fá-lo-ão invocando socket. Eis o modo comum de o fazer: UDPSock = socket ( PF_INET, SOCK_DGRAM, 0 ) ; Em caso de sucesso, é devolvido um valor inteiro, dito socket-udp, que identifica tais recursos - e, por conseguinte, a ser usado nas subsequentes primitivas. Note-se que (ao invés de fopen, que abre um ficheiro para escrita ou leitura) socket remete para um recurso que é full-duplex, isto é: que serve tanto para envio como para recepção de dados; e note-se também que (ao invés de fopen ("w"), que abre um ficheiro para escrita exclusiva por um Programa) a um Programa basta um único socket-udp para envio/recepção "em simultâneo" para/de quaisquer outros sockets-udp na Rede. Bind: Considere-se o caso particular do Servidor invocando a primitiva socket O valor de retorno é conhecido apenas dele mesmo: ninguém mais o conhece! Isso levanta uma questão: como pode o Cliente aceder-lhe, isto é: como pode ele indicar à infra-estrutura das comunicações o destino preciso dos dados que envia? Eis a resposta: o Servidor tem que tornar público, como que em uma lista telefónica, um identificador que o caracterize com exactidão (concretamente, o par endereço-ip/porto que o identifica); ademais, necessita associar dinâmicamente, ao socket previamente logrado, esse identificador. Para tal, deverá invocar bind. Simbolicamente, eis como: struct sockaddr_in Name = { AF_INET, INADDR_ANY, Port ) ; RetVal = Bind ( UDPSock, & Name, ) ; Em caso de sucesso (RetVal 0), subsequentes Dados recebidos na máquina, que venham endereçados ao Port referido, são passados, através de UDPSock, ao Programa em causa. SendTo: Para enviar dados, bastará verter em um buffer os dados a enviar e invocar sendto, passando como parâmetros: um apontador para esse Buffer, o respectivo comprimento útil e ainda o par endereço-ip/porto que identifica o destino desses dados. Simbolicamente, eis como: struct sockaddr_in Destin = { AF_INET, endereço-ip, Port ) ; /* Preenchimento de Data, resultando um comprimento total de DataSize octetos */ RetVal = sendto ( UDPSock, Data, DataSize, 0, & Destin, ) ; Em caso de sucesso, a Rede encarregar-se-á de transportar esses dados até à máquina com o endereço-ip assinalado; aí, serão entregues ao Programa que executou Bind com o Porto assinalado. RecvFrom: Para receber dados que cheguem da Rede, o Programa deve invocar recvfrom, passando como parâmetros: apontadores para um Buffer de recepção e para uma área, Source, a ser preenchida com o par endereço-ip/porto que identifica a fonte desses dados. Simbolicamente, eis como: RetVal = recvfrom ( UDPSock, Buffer, UbBufferSize, 0, & Source, ) ; O Programa pode aguardar uma interrupção apropriada (mediante a qual a máquina notifica o Programa de que tem dados a passar através do socket destino), para, só então, invocar recvfrom. Close: Enfim, o Programa deverá libertar os recursos envolvidos, invocando close.

8 Prof V Vargas, I S T Pg 8/97

9 Prof V Vargas, I S T Pg 9/97 Segmentos UDP {UDPSegments.doc} A figura esquematiza o formato de um Segmento-UDP, cfr RFC 768. Dele, constam, sucessivamente: um Cabeçalho de quatro pares de octetos e um campo final de Dados "do utilizador". Eis os campos que compõem o cabeçalho: PortoDestino (um par de octetos): Destina-se a viabilizar, à Entidade-UDP remota - à qual é entregue o Segmento -, o encaminhar o Segmento até ao processo (mais precisamente, socket) a que ele de facto ultimamente se destina. Porto Fonte (um par de octetos): O campo pode ser posto a zeros. Se o não estiver, visa proporcionar, ao processo destino do Segmento, a identificação da origem deste; e, por conseguinte, e na ausência de outra informação, o processo (mais precisamente, socket) a que, se fôr o caso, deverá ser devolvida alguma eventual réplica a esse Segmento. Comprimento do Segmento (um par de octetos): Contém o comprimento total do Segmento, isto é: incluindo Cabeçalho e Dados. Check-Sum (um par de octetos): Visa proporcionar algum grau de fiabilidade à comunicação (cfr. RFC 1071). Eis a forma de cálculo (a seguir na origem): determinar o complemento-para-1 da soma em complemento-para-1 de todas as palavras de 16 bit do Segmento, prefixado por um Pseudo-Cabeçalho (cfr. adiante); se o resultado der 0..0, é considerado ser Na Entidade destino, a soma em complemento-para-1 de todas as palavras do Segmento (e Pseudo-Cabeçalho) deve resultar em 1 1. Se não der este resultado, o Segmento é considerado estando errado; todavia, a Entidade não procede a nenhuma recuperação de erro (por ex., via solicitação da retransmissão desse Segmento): o que fazer em semelhante ocorrência, cabe à Aplicação decidir O Pseudo-cabeçalho, que visa prevenir a entrega errada dos Segmentos, é extraído do Cabeçalho do Datagrama-IP: inclui os endereços fonte e destino, o campo Protocolo (por ex., 21 8 ) e o Comprimento do Segmento UDP. Se o Segmento não contiver um múltiplo de palavras de 16 bits, é, para efeitos de cálculo da CheckSum, acrescentado (padded) com zeros no fim do Segmento. Conforme aos requesitos da Aplicação em causa, a Entidade pode colocar a Check-Sum a Apreciação final: Como se patenteia, UDP reduz-se, grosso modo, a IP com dois Portos para prover a função de multiplexagem. Pelo que os Segmentos têm uma estrutura muito simples, o overhead reduz-se ao mínimo indispensável: em particular, não existem, no seu formato, campos de numeração: quer dizer que, na definição do serviço a prestar, não se teve em mente levar por diante recuperação de erros e proceder a controlo de fluxo e congestão. Na prática, os Segmentos poderão chegar ao destinatário por ordem diferente daquela por que foram transmitidos; poderão chegar duplicados ou até nem chegar e, a acontecer tais eventualidades, não há qualquer obrigação em disso alertar os Processos de Aplicação! Existem Aplicações que toleram esta Qualidade de Serviço mínima. Exemplos, são-no: a Gestão de Redes de Computadores, o Domain-Name-System, Aplicações em tempo real (como sejam Audio e Video, unicast ou multicast onde o acento é o tempo). Mas a esmagadora maioria das Aplicações requere níveis de Qualidade de Serviço bem maiores. Pense o leitor em Aplicações Financeiras, em Correio Electrónico, Transferência de Ficheiros, Navegação na Web Para estas e outras Aplicações, o ideal seria: que aquilo que é transmitido para a Rede seja recebido tal e qual, sem quaisquer erros Para elas, existe um outro Serviço, e um outro Protocolo, a saber: TCP, Transmission Control Protocol. É a ele que serão dedicadas as páginas seguintes deste texto.

10 Prof V Vargas, I S T Pg 10/97

11 Prof V Vargas, I S T Pg 11/97 Sockets TCP - I {TCPSockets.doc} Um serviço providenciado pela biblioteca de primitivas Berkeley-Sockets é o assim denominado TCP (cfr RFCs 793, 854, 1106, 1122, 1323, 2018, 2581, 3168). No que se segue, abordam-se as etapas a cumprir na troca da informação entre dois parceiros suportada em sockets-berkeley TCP; isso será feito acompanhando o diagrama temporal da figura Constata-se que ela envolve oito primitivas: socket, bind, listen, connect, accept, write, read e close. Antes, todavia, de avançar, quiçá valha a pena um relance ao acesso telefónico ao IST: quando alguém longíquo deseja telefonar a alguém no interior do IST, começa, primeiro, por marcar o número telefónico geral do IST ( ); quando a simpática telefonista o atender, "soletra-lhe" o número da extensão com que pretende falar; a telefonista procede então ao re-encaminhamento da chamada; doravante, os telefones exterior e interior ao IST estão directamente conectados: no que lhes diz respeito, está concluído o papel da telefonista. Quer dizer: no IST, há um telefone (o da telefonista), para uma função especial: aguardar por sinais vindos de algum telefone exterior ao IST, e proceder à sua conexão com a extensão requerida. Prevendo a eventualidade de vários Clientes pretenderem comunicar em simultâneo com um dado Servidor, o software Berkeley para TCP recorre a um funcionamento análogo: no Servidor, existe um socket especial dedicado a uma função especial: aguardar pedidos provenientes da Rede, e proceder ao estabelecimento da correspondente conexão Entre cada Cliente e o Servidor, a comunicação desenrola-se então em três fases: uma primeira de estabelecimento de conexão (handshake), uma segunda de transferência de dados, e uma terceira de terminação da conexão. Socket: Previamente ao envio/recepção de dados, ambos - Programas Cliente e Servidor - têm que reservar (temporariamente) os recursos precisos. Fá-lo-ão, invocando socket. Eis o modo comum de o fazer: TCPSock = socket ( PF_INET, SOCK_STREAM, 0 ) ; Em caso de sucesso, é devolvido um valor inteiro, dito socket-tcp, que identifica tais recursos - e, por conseguinte, a ser usado nas subsequentes primitivas. Tal como ocorre com sockets-udp, os socket-tcp são fullduplex, isto é: servem tanto para envio como para recepção de dados. Bind: Como já se discutiu a propósito de sockets-udp, e para que potenciais Clientes lhe possam aceder, o Servidor deve invocar bind: struct sockaddr_in Name = { AF_INET, INADDR_ANY, Port ) ; RetVal = Bind ( TCPSock, & Name, ) ; Em caso de sucesso (RetVal 0), subsequentes Dados recebidos na máquina, que venham endereçados ao Port referido, são passados ao Programa em causa. Listen: No Servidor, o socket assim criado e associado a um Porto é reservado para a utilização especial já acima mencionada: aguardar por pedidos de conexão provenientes da rede. Para o efeito, o Servidor deve invocar listen. Eis como: RetVal = listen ( TCPSock, ) ; Em caso de sucesso (RetVal 0), subsequentes pedidos de conexão recebidos na máquina, que venham endereçados ao Port referido, são passados, através de TCPSock, ao Programa em causa.

12 Prof V Vargas, I S T Pg 12/97

13 Prof V Vargas, I S T Pg 13/97 Sockets TCP - II {TCPSockets.doc} Eis o cenário a que arribaram as etapas precedentes: - no Cliente, existe um socket, que se poderá designar de ClientSock; - no Servidor, existe um socket, que, dado a sua função especial, se poderá designar de ListenSock. Está tudo pronto para se proceder ao estabelecimento de uma conexão entre ambos, se trocarem dados e enfim terminarem a conexão. Connect: Previamente ao envio de dados, um Cliente necessita estabelecer uma conexão com o Servidor. Fá-lo invocando connect, passando como parâmetro o par endereço-ip/porto que identifica o Servidor: struct sockaddr_in Destin = { AF_INET, endereço-ip, Port ) ; RetVal = connect ( ClientSock, & Destin, ) ; A Rede encarregar-se-á de transportar o pedido de conexão até à máquina com o endereço-ip referido; aí, são entregues ao Servidor pelo ListenSock. Se o pedido fôr aceite, a Rede encarregar-se-á de o assinalar ao Cliente, mais precisamente no ClientSock. Só então o connect assinalará sucesso (Se o Servidor não houver ainda executado listen, ele devolve Nack podendo eventualmente aguardar um pouco antes de se decidir a fazê-lo) Accept: O pedido de conexão pode, ou não, ser aceite pelo Servidor. Ele manifesta a sua disposição em o aceitar invocando, em tempo oportuno, accept. Eis como: UserSock = accept ( ListenSock ) ; Um eventual pedido de conexão que chegue ulteriormente será aceite. Em termos práticos, é criado um novo socket-tcp, dito UserSock; e, fica estabelecida uma conexão entre esse UserSock e o ClientSocket do Cliente responsável do connect que o Servidor está aceitando. Realce-se: entre os dois sockets, ClientSock e UserSock, pode, num dado momento, estar em curso uma e uma só conexão; mas, ancoradas a um mesmo socket, poderão estar decorrendo várias conexões simultâneas. Após a sequência de primitivas connect/accept, ambos os Programas - Cliente e Servidor - podem trocar dados; fazem-no, um e outro, através das primitivas Write e Read: Write: Para enviar dados, bastará verter em um buffer os dados a enviar e invocar write, passando como parâmetros (além de Sock): um apontador para esse Buffer e o respectivo comprimento útil. Simbolicamente, eis como: /* Preenchimento de Data, resultando um comprimento total de DataSize octetos */ RetVal = write ( TCPSock, Data, DataSize) ; em que TCPSock se volve em UserSock ou ClientSock, conforme respectivamente write esteja sendo invocado no Servidor ou no Cliente; a Rede encarregar-se-á de transportar esses dados até, respectivamente, ClientSock e UserSock. Read: Para receber dados que cheguem da Rede, um Programa deve invocar read, passando como parâmetro um apontador para um Buffer de recepção. Simbolicamente, eis como: RetVal = read ( TCPSock, Buffer, UbBufferSize ) ; Em que de novo TCPSock se volve em UserSock ou ClientSock. O Programa pode aguardar um sinal apropriado (mediante o qual a máquina notifica o Programa de que tem dados a passar através do TCPSock), para, só então, invocar read. Close: Enfim, ambos os Programas deverão libertar os recursos envolvidos, invocando close ( TCPSock ) sobre os sockets que não mais sejam necessários: sobre UserSock ou ClientSock quando a conexão findar, e sobre o ListenSock quando não mais estiver disposto a aceitar pedidos de conexão.

14 Prof V Vargas, I S T Pg 14/97

15 Prof V Vargas, I S T Pg 15/97 Segmentos TCP {TCPSegments.doc} A figura esquematiza o formato de um Segmento TCP. Dele, constam um Cabeçalho, de ao menos 20 octetos, e um campo Dados, para veicular até um máximo de MessageSegmentSize (MSS) octetos "do-utilizador/da- Aplicação". Eis os campos que compõem o cabeçalho: PortoDestino (um par de octetos): Destina-se a viabilizar, à entidade TCP destino - a que a Rede entrega o Segmento -, o encaminhar o Segmento até ao processo (mais precisamente, socket) a que ele de facto ultimamente se destina. Porto Fonte (um par de octetos): Visa proporcionar, ao processo destino do Segmento, a identificação da origem do Segmento; e, por conseguinte, o processo (mais precisamente, socket) a que, se fôr o caso, deverá ser devolvida alguma eventual réplica a esse Segmento. Número de Sequência e Acknowledge de bytes (quatro octetos cada): Visa proporcionar recuperação de erros de transmissão, cfr páginas adiante. Comprimento do Cabeçalho-TCP, em palavras de 32 bit (um par de octetos): Flags (seis bit: URG, PSH, ACK, SYN, FIN e RST), cfr páginas adiante: São em geral postas a '0', as excepções são as seguintes: - SYN '1': apenas nos dois primeiros Segmentos trocados no estabelecimento da conexão; no que segue, tais Segmentos serão simbolicamente representados por Syn; - ACK '1' (significando que o campo Acknowledge é válido): a partir do segundo Segmento trocado numa conexão; no que segue, e se não contiverem quaisquer octetos de Dados, tais Segmentos - ditos vazios - serão simbolicamente representados por Ack; - FIN '1': apenas nos dois últimos Segmentos trocados na terminação da conexão; no que segue, serão simbolicamente representados por Fin) - RST '1': para indicar o reset de uma conexão, ou a rejeição de uma tentativa de estabelecimento de uma conexão, ou a recepção de um Segmento inválido; no que segue, tais Segmentos serão simbolicamente representados por Rst; Crédito / Janela de recepção (dois octetos): Visa proporcionar controlo de fluxo, cfr páginas adiante. Check-Sum (um par de octetos): Visa proporcionar algum grau de fiabilidade à comunicação entre ambas as entidades TCP. A forma de cálculo é a mesma seguida a propósito dos Segmentos UDP. Apontador à cauda dos Dados Urgentes (dois octetos) Adicionado ao Número de Sequência do primeiro octeto, designa o Número de Sequência do octeto a seguir aos Dados Urgentes ; é válido se URG=1. Opções (n octetos, cfr páginas adiante) Padding (sucessâo de 0 s para garantir que o comprimento do cabeçalho é múltiplo de 32-bit) Apreciação final: Como se patenteia, existem, no formato dos Segmentos TCP, campos de numeração: isso significa que, na definição do serviço a prestar, se teve em mente levar por diante recuperação de erros e proceder a controlo de fluxo (e congestão).

16 Prof V Vargas, I S T Pg 16/97

17 Prof V Vargas, I S T Pg 17/97 "Stream" de Octetos {OctetStream.doc} UDP é um protocolo orientado à Transacção: um dos interlocutores envia para a Rede um Segmento e, no destino, o Bloco de Octetos em que se volve o seu conteúdo "Dados" é entregue ao utilizador de-uma-vez-só. Ainda que, antes ou depois, aquele tenha transmitido algum outro Segmento UDP, são preservadas as fronteiras desses Blocos: as Entidades-UDP jamais procedem à concatenação de Segmentos-UDP consecutivos. Em poucas palavras: por cada sendto na origem, é necessário e suficiente um único recvfrom no destino Já TCP, por seu turno, é um protocolo orientado ao "Stream" de Octetos: o interlocutor fonte envia para a Rede um fluxo de Octetos, agregados em um ou vários Segmentos e, no destino, e à medida que aí aportam os Segmentos, o seu conteúdo "Dados" fica disponível para ser recolhido. Nem sempre existe uma correspondência um-a-um entre writes e Segmentos! Um Segmento pode resultar de um ou vários write Com o que um write da fonte pode volver-se em vários read no destino e vice-versa: para vários write na fonte poderá ser bastante um único read no destino Na figura, encontram-se esquematizadas algumas destas possibilidades: A) W invoca um único write, que dá origem a um único Segmento que se propaga até E e aí é recolhido com um único read B-E) W invoca vários write; a Entidade-TCP local concatena-os a todos em um único Segmento que se propaga até E e aí é recolhido com um único read Nota: a querer-se lograr uma maior eficiência no uso dos recurso da Rede, a concatenação figurada torna-se uma candidata natural; o custo é, é claro, o maior tempo de resposta ao nível da Aplicação F-J) W invoca vários write, que dão origem a outros tantos Segmentos que se propagam até E; quando o primeiro aí chega, vem a ser recolhido com um read; mas, quando chega a altura de invocar de novo read, já os restantes Segmentos chegaram: o seu conteúdo é lido de uma vez só Nota: a vantagem desta filosofia é clara: minimiza as interrupções exercidas sobre o Utilizador Isso ainda é mais notório se a Entidade-TCP fizer o seguinte: alerta o Utilizador para a disponibilidade de Dados somente após ter recebido um número "significativo" deles; o custo é, é claro, o maior tempo de resposta ao nível da Aplicação K) W invoca um único write, que dá origem a dois Segmentos que se propagam até E e aí são recolhidos com outros tantos read L-M) W invoca dois write; que dão origem a outros tantos Segmentos que se propagam até E - onde chegam por ordem diferente da inicial; a Entidade-TCP em E espera que chegue o primeiro, para só então sinalizar o utilizador, pelo que a ele basta um único read para recolher o conteúdo "Dados" emitido por W Resumidamente, TCP permite a comunicação unicast (entre dois pontos da Rede): não proporciona multicast nem broadcast. As fronteiras entre os Blocos em que a fonte fornece os Dados não são sempre preservadas. E o tempo de trânsito é variável, imprevisível, maior ou menor E realce-se que, por mor de simplicidade, não se entrou em linha de conta com a eventualidade de erros ou perdas na Rede Na vida real, isso acontece, é claro - mas, a este respeito, TCP traz boas notícias para as Aplicações: ele tem em curso medidas para a recuperação dessas anomalias Elas envolvem números de sequência, acknowledges, timeouts e retransmissões - e, portanto, mais tempo ainda A Dimensão dos Segmentos: Não se pode perder de vista a eficiência com que se usam recursos: computadores terminais, linhas e nós/gateways da Rede. A este respeito, convém reparar: Segmentos muito grandes originam fragmentação (e correspondente complexidade) ao nível-ip de outra parte, Segmentos pequenos levam a um desempenho assaz baixo: os protocolos IP-e-TCP acarretam um cabeçalho conjunto de pelo menos 40 octetos por cada conteúdo "Dados da Aplicação" Além de que é maior o tempo gasto pela CPU com cada Segmento. Daí o ocorrido aquando da invocação das operações K (uma fragmentação em vários Segmentos) e B-E ( uma concatenação em um único Segmento).

18 Prof V Vargas, I S T Pg 18/97

19 Prof V Vargas, I S T Pg 19/97 Push e Dados Urgentes {PushAndUrgent.doc} O diagrama temporal ultimamente apresentado realçou dois casos de espera da Entidade-TCP: - quando, após o Utilizador lhe ter requerido a transmissão de Dados para a Rede, a Entidade aguarda (um pouco) que ele lhe entregue mais Dados: em tal caso, ela poderá ir congregando-os a todos em um único Segmento - por conseguinte aumentando a eficiência do uso dos recursos da Rede; - quando, após a Rede lhe ter entregue Dados a transferir ao Utilizador, a Entidade aguarda (um pouco) que ela lhe entregue mais Dados: a vir isso a suceder, e tendo-os acumulado a todos em um único Buffer, bastará uma única interrupção para sinalizar a sua chegada - por conseguinte melhorando a eficiência do uso do processador da máquina Tal espera não é sempre benvinda: casos haverá em que convirá apressar a Entidade Para o efeito, TCP proporciona duas flags, a saber: Push e Urgent Data. Push: Como forma de requerer o envio imediato dos Dados por parte da Entidade, o Utilizador deve solicitá-lo adequadamente na primitiva write. A Entidade responde preenchendo "de imediato" um Segmento com os Dados ainda em espera, e fixando a On a flag Push. Na figura, encontra-se esquematizado este mecanismo: A-B) W invoca dois write, deixando à Entidade a decisão acerca do momento em que procederá ao envio para a Rede; no caso, ela envia-os aquando da invocação do segundo write D-F) W invoca quatro write, acompanhando o último deles com a solicitação do seu envio imediato para a Rede; a Entidade responde preenchendo um Segmento com os Dados em espera, e colocando a On a flag Push. D-F) W invoca quatro write, acompanhando o último deles com a solicitação do seu envio imediato para a Rede; a Entidade responde preenchendo de imediato um Segmento com os Dados em espera, e colocando a On a flag Push. G-J) W invoca quatro write, acompanhando o terceiro e o último deles com a solicitação do seu envio imediato para a Rede. Acontece que, aquando do terceiro write, a linha de saída para a Rede se encontra ocupada (busy), pelo que há que aguardar; após o quarto write, essa situação já se esvaneceu, pelo que a Entidade prossegue preenchendo um Segmento com os Dados em espera, e colocando a On a flag Push. Nota: na recepção de um Segmento com a flag Push a On, a Entidade destino deve passá-los ao Utilizadordestino de imediato; todavia, a sinalização de que a flag Push foi recebida a On, fica ao critério do programador da Entidade: ela pode, ou não, ser sinalizada. Ademais, não existe obrigação em lhe reportar o ponto exacto do fluxo de octetos em que o Utilizador-fonte invocou a função Push. Dados Urgentes: Em ordem a sinalizar à Entidade-destino Dados a processar rapidamente, o Utilizador deve solicitá-lo adequadamente na primitiva write. A Entidade local responde fixando a On a flag Urgent e designando, no campo Apontador à cauda dos Dados Urgentes, o termo dos dados urgentes; no destino, a Entidade reage alertando o Utilizador. Na figura, encontra-se esquematizado este mecanismo: K) W invoca um write sem requerer o mecanismo Urgent; a Entidade envia o correspondente Segmento No destino, a sua recepção não se faz acompanhar de nenhum alerta: os Dados são passados ao Utilizador quando este resolver por si "ver se já chegou algo" L ) W invoca um write requerendo o mecanismo Urgent; a Entidade envia o correspondente Segmento No destino, a sua recepção desencadeia de imediato um alerta ao Utilizador: ele pode de imediato invocar a primitiva read para os recolher

20 Prof V Vargas, I S T Pg 20/97