Documentação-TP1

7/24/2019 Documentao-TP1

1/20

Universidade Federal de Minas GeraisRedes de Computadores

SOCKETSTrabalho Prtico 01

Gabriel Natan Pires Silva - Matrcula: 2013024384


2/20

Sumrio

Introduo .................................................................................................................................................. 2

Metodologia ............................................................................................................................................... 2

Configurao da Mquina Utilizada ................................................................................................ 2

Implementao do Servidor .............................................................................................................. 2

Bibliotecas, Estruturas e Definies................................................................................................ 2

Resumo de Funcionamento do Cdigo .......................................................................................... 3

Implementao do Cliente ................................................................................................................. 4

Bibliotecas, Estruturas e Definies................................................................................................ 4

Resumo de Funcionamento do Cdigo .......................................................................................... 5

Procedimentos de Coleta de Dados................................................................................................ 6

Verificao de Funcionamento Correto e Adequado aos Requisitos........................................ 6

Testes de performance ..................................................................................................................... 8

Resultados ................................................................................................................................................. 8

Referentes ao Funcionamento Conforme os Requisitos.......................................................... 8

Resultados de Falha Intencional...................................................................................................... 8

Resultados Bem Sucedidos............................................................................................................ 10

Referentes Performance ............................................................................................................... 13

Testes Variando o Nmero de Arquivos....................................................................................... 13Testes Variando o Nmero de Bytes Total .................................................................................. 15

Anlises e Discusses ......................................................................................................................... 18

Acerca do Funcionamento .............................................................................................................. 18

Acerca da Performance .................................................................................................................... 18

Concluso ................................................................................................................................................ 19

Referncias Bibliogrficas .................................................................................................................. 19


3/20

Introduo

No ambiente das redes de computadores, a comunicao entre mquinas pode se dar de diversasmaneiras: orientada a conexo (ou no), orientada a confirmao (ou no), em pares, redes difusas,utilizando diversos protocolos, dentre outras variaes.

Devido o advento da Computao na Nuvem, onde dados ficam armazenados em servidores, a noo decomunicao entre cliente-servidor tornou-se corriqueira e, portanto, essencial sua compreenso emanipulao.

Sendo assim, o objetivo deste trabalho ser a implementao de programas que simulem um servidor eum cliente, operando de forma complementar ao outro e se valendo do protocolo TCP (largamente utilizadono desenvolvimento de ferramentas para a internet).

O par de programas se comunicar atravs de requisies e respostas, de forma a interligar a interface desocket do cliente com a do servidor e cada um ouvindo e escrevendo na socket alternadamente, de formaa funcionar tanto com o protocolo IPv4 quanto com IPv6.

Metodologia

Configurao da Mquina Utilizada

Processador: Intel Core i7-3537U 2.00GHz

Memria RAM: 8.00GB

Sistema Operacional: Linux Ubuntu

Implementao do Servidor

Para maiores esclarecimentos, vide structs_server.h, func_server.c e server.c.

Bibliotecas, Estruturas e Definies

Foram utilizadas as bibliotecas stdio.h e stdlib.h a fim dese utilizar funes padro comoprintf().

String.h foi utilizada a fim de implementar funes demanipulao strings como sprintf(), strcat(), dentre outras,importante visto que nosso objetivo requer envio demensagens de texto.


4/20

Em seguida foi necessrio uso de bibliotecas especficas para implementar a comunicao entre o servidore cliente. No caso foram utilizadas sys/types.h, sys/socket.h, netbd.h, arpa/inet.h, netinet/in.h.

A definio de MAX_STR = 259 se deve ao fato do tamanho mximo de nome de arquivo ser 255 bytesque somados a 3 bytes de bye e 1 byte de terminao (\0) se obtm o tamanho mximo possvel de uma

mensagem.

Na linha 12 verifica-se meramente umtypedef para no ser necessrio digitarstruct antes da declarao da estruturasockaddr_in6(j definida em sys/socket.he netinet/in.h.

A estrutura BUFFER contm umapontador para vetor de caracteresfocado na leitura da socket (read), outrona escrita (write) e outro (fileSpec) apenaspara definir o nome do documento detexto (que deve se chamar).

SERVER, por sua vez, contem um inteirosockfd, que vai conter o valor da socketaps aberta, portno que ir conter onmero da porta do servidor e um tiposockaddr_in6 addr que ir conter

parmetros do endereo do servidor (se IPv4 ou IPv6, por exemplo). Escolheu-se sockaddr_in6e nosockaddr_injustamente para operar com ambos protocolos.

J NEWCLIENT semelhante ao SERVER, diferindo apenas por no ter portnoe tendo addr_lenghtquecontm o valor de sizeof(NEWCLIENT.addr), e ip um vetor de caracteres do tamanho de um endereoIPv6, que ir conter o endereo IP do cliente em forma de texto.

Resumo de Funcionamento do Cdigo


5/20

O servidor funciona em trs etapas: inicializao, comunicao e trmino.

Na inicializao se declara variveis, inicializa buffer (com inicializa_buffer(&buffer)) e, uma vez que sejamfornecidos dois argumentos adequados (, ), inicia a conexo e gera umdocumento de texto (at ento vazio) com respectivamente inicia_conexao(server,newclient,argv[1]) edefine_nome_txt(newclient,&buffer) .

A comunicao apenas um loopque funciona enquanto no for recebida a mensagem de encerramentobye e verifica se a mensagem lida (read(newclient->sockfd, buffer.read, MAX_STR-1) - MAX_STR-1,pois a leitura at o byte de terminao \0 - READY (neste caso deve enviar READY ACK), se bye (neste caso encerra conexo), se contm bytestuffing mais detalhes em Implementao doCliente - (neste caso deve-se remov-lo e armazenar o nome real no arquivo comatualiza_documento(&buffer)e confirmer recebimento com FILE ACK) ou se um nome de diretrio(precisando apenas armazen-lo e confirmar recebimento). Ao final de cada loopescreve na socket comwrite(newclient->sockfd,buffer.write,MAX_STR-1).

Por fim o trmino requer fechar as sockets de SERVER e NEWCLIENT, atravs de termina(server,newclient).

Na inicializao que se trata tanto IPv4 quanto IPv6, mais especificamente na funo inicia_conexao()

de forma que ela segue um fluxo de operaes comeando pela abertura da socket do servidor -socket(AF_INET6, SOCK_STREAM,0)onde AF_INET6 neste caso especfico aceita por padro ambosIPv4 e IPv6 e nas configuraes da socket em seguida, onde definimos server->addr.sin6_family =AF_INET6 e server->addr.sin6_addr = in6addr_any, ambos protocolos citados sejam automaticamentetratados e aceitos.

Implementao do Cliente

Para maiores esclarecimentos, vide structs_client.h, func_client.c e client.c.

Bibliotecas, Estruturas e Definies

Com relao ao servidor, as nicas novidades so asbibliotecas sys/time.hque contm a funo gettimeofday()e aestrutura necessria para seu uso timeval.

J a biblioteca dirent.h que implementa as estruturas DIR edirent, bem como funes de abertura de diretrio opendir(), ede leitura de seu contedo readdir().


6/20

Os quatro primeiros typedef vistos aesquerda so pelo mesmo motivo citado nasestruturas do servidor (linha 12), bem comoo BUFFER (dessa vez sem fileSpec).

As novidades implementadas no cliente so,primeiramente, a estrutura ESTATISTICASque armazena o nmero de bytes enviadosem total_dados, a durao da execuo emtempo_execucaoem segundos e por fim avazo de dados em bytes por segundo.

Por fim h a estrutura CLIENT, que contmum inteiro sockfdpara armazenar o nmeroda socket aberta, in6_addr serv_addr quecontm informaes sobre o servidor que setenta conectar (exemplo, se IPv4 ou IPv6,

qual endereo, dentre outras), e umaestrutura hintse um apontador *resdo tipoaddrinfo, que como sugere o nome carregamparmetros da socket do cliente (como porexemplo, se dados sero enviados emSTREAM ou DATAGRAM).

Resumo de Funcionamento do Cdigo

Pelo fato de funcionar de forma complementar ao servidor, esperava-se que o cliente fosse estruturalmenteparecido com o mesmo. Dessa forma, o cliente funciona em quatro etapas: inicializao, comunicao,clculo de estatsticas e trmino.

Na inicializao se declara variveis, inicializa buffer (com inicializa_buffer(&buffer)) e, uma vez que sejamfornecidos quatro argumentos adequados (, , ,), inicia a conexo atravs de inicia_conexao(client, argv[1], argv[2]) e envia ao servidoro nome do diretrio de origem dos arquivos, atravs de define_nome_txt(client,&buffer,argv[3]) .


7/20

A comunicao inicia escrevendo na socket READY, chama gettimeofday(&t_inicio, NULL) e apsreceber READY ACK (atravs da leitura de socket) j l os nomes dos arquivos no diretrioem ciclocom a funo le_arquivos(client,&buffer,&estatisticas,argv[3]) , os escreve na socket com write(client->sockfd, buffer.write,MAX_STR-1),soma seu tamanho em bytes em estatisticas->total_dados e aguardarecebimento de FILE ACK lido na socket (read(client->sockfd,buffer.read,MAX_STR-1) para repetir aleitura, at que encerre o contedo do diretrio. Caso algum arquivo apresente nome na forma n*bye

(sendo n um nmero natural no nulo), utiliza-se uma tcnica de bytestuffingque consiste em acrescentarum bye a mais no nome de forma que nenhum arquivo seja enviado como bye e encerre a conexo por

engano.

O clculo de estatsticas comeam no momento que a leitura de diretrio acaba e envia bye ao servidor.

Inclusive nesta etapa que as medies so feitas, de forma que o cliente chama gettimeofday(&t_final,NULL)e calc_estatisticas(&estatisticas,t_inicio,t_fim). O gettimeofday()funciona de forma que armazenano primeiro argumento a hora do dia naquele instante, em segundos e microsegundos, e o segundoparmetro desnecessrio, pois corresponde ao fuso (NULL neste caso representa o defaultda mquinaque seria autocompletar seu fuso).

Para obter a durao da execuo basta realizar t_fim t_inicio. Como so estruturas que contemsegundos e microsegundos, use tempo_execucao = (t_fim.sec t_inicio.sec)+(t_fim.usec

t_inicio.usec)10E-6 segundos. O total de dados j foi obtido ao realizar total_dados += strlen(buffer.write) durante a comunicao. Por fim o throughput foi calculado como total_dados / tempo_execucao B/s.Depois ajustou-se tempo para ms e throughputpara kB/s.

O trmino se d fechando a socket do cliente por close(client->sockfd).

A questo do tratamento IPv4 e IPv6 foi resolvida na comunicao, mais especificamente eminicia_conexao(). No momento de definir os parmetros da conexo (em hints), a famlia foi definida comono especificada (pode ser tanto IPv4 quanto IPv6), atravs de client->hints.ai_family = AF_UNSPEC. Emseguida dividiu-se em dois casos: caso ao converter o endereo IP do servidor (declarado como tipoin6_addrpor default aceita ambos) de texto para binrio IPv4 ( inet_pton(AF_INET,)) retorne 1, o cliente configurado como famlia AF_INET para ser compatvel. O segundo caso caso o primeiro falhe einet_pton(AF_INET6,) retorne 1, o servidor usa endereo IPv6 e configura famlia do cliente como

AF_INET6.

Procedimentos de Coleta de Dados

Verificao de Funcionamento Correto e Adequado aos Requisitos

Primeiramente necessrio saber quais so os requisitos de projeto a serem cumpridos, sendo unsespecficos do cliente ou servidor, logo sero divididos nas categorias AMBOS, SERVIDOR e CLIENTE.

AMBOS: Devem realizar comunicao do tipo requisio-resposta (protocolo TCP);Funcionar com IPv4 e IPv6;

Encerrar comunicao aps fim da transferncia de dados (bye).

SERVIDOR: Precisa funcionar com base em apenas dois argumentos no terminal;

Receber READY do cliente e enviar READY ACK;


8/20

Gerar um documento de texto com ttulo formatado no modelo supracitado, contendo osdados coletados do cliente (um nome por linha) - Caso algum nome tenha sofridobytestuffing, deve retir-lo sem comprometer a conexo;

Ao final, aps receber bye,exibir o nmero de nomes recebidos.

CLIENTE: Necessrio funcionar com apenas quatro argumentos no terminal;

Enviar READY ao servidor (aps estabelecer conexo) e aguardar READY ACK;

Enviar os nomes de todos os arquivos (no subdiretrios) contidos no diretrioespecificado ao servidor. Caso algum corresponda a n*bye (tal que n pertence aos

nmeros naturais no nulos), efetuar bytestuffing;

Quando acabarem os arquivos, enviar bye ao servidor;

Calcular de alguma forma o a durao do envio (em ms), o nmero de bytes enviados e ataxa de transferncia entre cliente e servidor.

Para verificar tais requisitos funcionais utilizou-se a insero de linhas de cdigo que imprimem o statusda execuo ao longo da mesma e analisou-se o surgimento das mesmas no terminal. Os statusesperados que comprovariam o bom funcionamento do cdigo so:

- Servidor aberto. Aguardando cliente.: Servidor realizou abertura passiva com sucesso.

- O cliente de endereco X e porta Y conectou-se ao servidor. Aguardando arquivos.: Cliente encontrou oservidor adequadamente e servidor aguarda READY. Se X for iniciado com ::, o cliente se conectou porIPv6, se no, se conectou por IPv4.

- Documento a conter nomes [...]: .: Comprova criao do documento detexto com nome adequado. (Observao: O sistema no consegue criar arquivos contendo o smbolo /

presente no caminho de um diretrio ex.: home/natan portanto o servidor possui uma funo queautomaticamente substitui os / por > para evitar problemas)

- Cliente pronto para enviar arquivos. Autorizando envio.: READY recebido pelo servidor, READY ACKenviado.

- Cliente concluiu o envio. Foram recebidos K arquivos. Conexao encerrada.: Confirma recebimento dobye pelo servidor, contagem de nomes e o encerramento correto da conexo.

- Tentando conectar-se [...] por IPv_: Especifica qual protocolo IP cliente est acessando.

- Conectando [...]. Confirmando prontidao [...].: Conexo efetuada com sucesso e cliente enviouREADY.

- Autorizao de envio recebida. Enviando arquivos.: Comprova recebimento de READY ACK e inciode envio dos dados.

- Dados da execucao [...]: Mostra trmino do envio, envio de bye ao servidor,exibio das estatsticasexigidas e encerramento da conexo.


9/20

Testes de performance

Ao longo do desenvolvimento do par de programas, observou-se que no s o nmero de bytes erarelevante para a alterao de tempo de execuo e taxa de transferncia, como o nmero de arquivosenviados tambm interfere de maneira significativa na maneira como o projeto funciona, visto que cada

arquivo extra agrega um tempo de leitura a mais.

Sendo assim, os testes foram divididos nas categorias FUNO DE BYTES e FUNO DE ARQUIVOS.

FUNO DE BYTES: Elaborou-se uma tabela contendo nmero de bytes enviados, nmero de arquivosenviados, tempo da amostra, tempo mdio, desvio padro populacional do tempo e throughputmdio.Foram analisados o envio de 2jbytes, tal que 0 j 17 e j um nmero natural. Para cada valor de j foramfeitas 10 amostras de tempo e suas respectivas taxas de transferncia e automaticamente as tabelas(elaboradas no programa LibreOffice Calc) calcularam os dados restantes. Em seguida elaborou-se 4grficos: dois de tempo mdio (em ms) em funo do nmero de bytes (um em escala linear e outrologartmica) e dois de throughput mdio (em kB/s).

FUNO DE ARQUIVOS: Elaborou-se uma tabela contendo nmero de arquivos enviados, tempo da

amostra, tempo mdio, desvio padro populacional do tempo e throughputmdio. Foram analisados oenvio de 128 bytes fixos, divididos em 2marquivos, tal que 0 m 5 e m um nmero natural. Para cadavalor de m foram feitas 10 amostras de tempo e suas respectivas taxas de transferncia e automaticamenteas tabelas calcularam os dados restantes. Em seguida elaborou-se 4 grficos: dois de tempo mdio (emms) em funo do nmero de arquivos (um em escala linear e outro logartmica) e dois de throughputmdio (em kB/s).

Todos os grficos foram elaborados e posteriormente analisados (ajuste linear, exponencial ou sigmoidal)no programa OriginLab Origin 2015 (64 bitsSistema Operacional Windows 8Mesma mquina citadaanteriormente).

Resultados

Referentes ao Funcionamento Conforme os Requisitos

Resultados de Falha Intencional

Tentativa de abertura do servidor com menos de 2 argumentos:

Tentativa de abertura do servidor com porto invlido:


10/20

Tentativa de conexo do cliente com menos de 4 argumentos:

Tentativa de conexo do cliente com servidor fechado:

Tentativa de conexo do cliente com servidor aberto atravs de porto errado:

Tentativa de leitura de diretrio inexistente (IPv4):

Arquivo Gerado: 127.0.0.1pastainexistente.txt


11/20

Tentativa de leitura de diretrio inexistente (IPv6):

Arquivo Gerado: ::1pastainexistente.txt

Resultados Bem Sucedidos

Tentativa de leitura de diretrio vlido qualquer (IPv4 Sem arquivos de nome excepcional):


12/20

Arquivo Gerado: 127.0.0.1>home>natan>Desktop>TP1-FINAL.txt

Tentativa de leitura de diretrio vlido qualquer (IPv6 Sem arquivos de nome excepcional):

Arquivo Gerado: ::1>home>natan>Desktop>TP1-FINAL.txt


13/20

Tentativa de leitura de diretrio especial (IPv4Arquivos com nome contendo bye):

Arquivo Gerado: 127.0.0.1home>natan>Desktop>TESTE-BYES.txt

Tentativa de leitura de diretrio especial (IPv6Arquivos com nome contendo bye):


14/20

Arquivo Gerado: ::1home>natan>Desktop>TESTE-BYES.txt

Referentes Performance

Ao tentar verificar o comportamento dos programas, seja variando o nmero de mensagens ou de bytes,obteve-se uma tabela e 4 grficos para cada um dos dois casos, como citado em Metodologia. Noentanto, pelo fato de utilizar-se no eixo das abcissas sempre potncias de 2, optou-se por exibir e discutirneste texto apenas os grficos de eixo x em escala logartmica na base 2.

Testes Variando o Nmero de Arquivos

Foram criados diretrios todos contendo exatamente 128 bytes de nomes de arquivos, porm cada umcontinha esta soma dividida em partes iguais para 2s arquivos, sendo 0 s 5, ou seja, o cliente ir enviarde 1 32 mensagens, em potncias de 2 mensagens. Os resultados foram os seguintes:

Tabelas com a coleta de dados:


15/20

Grfico tempo de envio em funo do nmero de arquivos:

Curva que se adequa ao modelo: = 0.0513 0.268(.)

.

Grfico throughputem funo do nmero de arquivos:


16/20

Curva que se adequa ao modelo: = 41.098 602.095

.

Testes Variando o Nmero de Bytes Total

Foram criados diretrios contendo 2j(tal que 0 j 17) bytes de nomes de arquivos, inicialmente comapenas um arquivo, porm aps passar de 128 bytes foi necessrio dividir as mensagens, por limitaesdo sistema operacional. As divises foram feitas de forma que cada mensagem contivesse exatamente128 bytes. Os resultados foram os seguintes:

Tabelas com a coleta de dados:


17/20

Grfico tempo de envio em funo do nmero de bytes:

Curva que se adequa ao modelo: = 0.237 0.001(.)

.


18/20

Grfico throughputem funo do nmero de bytes:

Curva que se adequa ao modelo: = 35.139 (.)

+.(.)


19/20

Anlises e Discusses

Acerca do Funcionamento

Conforme citado em Verificao de Funcionamento Correto e Adequado aos requisitos, as impressesexpostas no terminal servem para indicar quais passos foram cumpridos ao longo da execuo do parservidor-cliente. Para que se possa afirmar que os cdigos funcionaram conforme o esperado necessrioanalisar tanto as situaes de falha quanto de sucesso.

Quanto as falhas temos que ambos servidor e cliente exibiram ERRO NOS ARGUMENTOS ao tentar

executar com menos de 2 e 4 parmetros, respectivamente, cumprindo este quesito. Ambos ao utilizar-sealgum porto bloqueado ou diferente entre si, exibiu ERRO DE BIND NA SOCKET no servidor, indicando

que de fato no se pde concluir a inicializao uma vez que a port era invlida, e ERRO NA CONEXAO

no cliente, demonstrando que a conexo s ocorre quando o cliente tenta acessar o servidor na porta queele realizou sua abertura (se servidor estiver fechado ou host incorreto h o mesmo erro). Por fim ao inserirum diretrio invlido percebemos que no cliente se exibe DIRETORIO NAO EXISTE e encerra conexo,

j no cliente h ERRO DE LEITURA NA SOCKET (Connection reset by peer) mostrando que um instanteantes do cliente fechar no h o que ser lido pelo servido j que no h diretrio a ser analisado e aps ocliente fechar, o servidor deve avisar que o seu par se desconectou. Logo, at ento o cdigo se comportouexatamente conforme esperado e de fato o cliente e servidor interagem entre si em tempo real.

J nas situaes de sucesso, quando o host especificado em IPv4 o cliente expressa Tentandoconectar-se em IPv4 e o servidor exibe o endereo do cliente e sua porta (comeada com 4 ou 5) e aimpresso na tela para IPv6 apresenta mesmo formato, com porta iniciada por 3, indicando que ambosfuncionam tanto para IPv4 quanto IPv6. Tanto cliente quanto servidor exibem todas as mensagens deprontido e autorizao, bem como as estatsticas e nome do arquivo previstas, mostrando que essesmecanismos operam corretamente. Ao estudar o contedo da pasta TESTE-BYES verificamos que h umbye, um byebye e um byenatan, no primeiro o programa (se no tratado) fecharia, no segundo e

terceiro se o bytestuffingestivesse incorreto poderiam ser exibidos como variaes do tipo byenatanbye

ou semelhantes.

Acerca da Performance

Em se tratando do nmero de arquivos como uma varivel, percebe-se que o tempo de execuo comea(para um arquivo) com por volta de 0.2 ms e acrescentando por volta de 0.15 ms a cada dobro de arquivos,at 16 mensagens. Depois disso o comportamento aparente linear acaba e percebe-se uma exponencialcrescente do tempo em funo do nmero de mensagens em escala log 2. J a taxa de transferncia uma exponencial decrescente conforme o expoente do nmero de mensagens aumenta. A variaoexponencial nos indica que o nmero de mensagens provavelmente o fator crtico para determinao do

tempo final de execuo e throughput.

Ao realizar a anlise voltada para o nmero de bytes enviados com a influncia do nmero de arquivosem mentepodemos perceber que inicialmente a curva de tempo em funo do nmero de bytes enviadosapresenta comportamento aproximadamente constante em torno de 0.23 ms para x < 8, que correspondeao trecho que, conforme a tabela indica, somente uma mensagem foi enviada, e para x > 8 h umcomportamento exponencial crescente, comprovando a suspeita de que o fator crtico para determinaodo tempo de execuo o nmero de arquivos enviados.


20/20

Por fim, vale destacar a curva de throughput em funo do nmero de bytes, pois seu comportamento foibastante singular e esclarecedor ao longo dos ensaios. A primeira poro, para x < 8, se assemelha umaexponencial crescente, enquanto a segunda poro seria uma exponencial crescente com expoentefracionrio, formando, juntos, uma curva sigmoidal. A primeira parcela nos mostra o momento em que onmero de mensagens constante igual a um, logo a taxa de transferncia ditada apenas pelo nmerode bytes enviados e aproximadamente dobra a cada aumento no expoente de bytes. Na segunda parcela

o nmero de bytes gradativamente suprimido pelo nmero de mensagens at se estabilizar emaproximadamente 4 MB/s (tomando 1M = 1000 k), pois neste trecho quando o nmero de bytes dobra onmero de mensagens dobra junto, ento a razo bytes/tempo aproximadamente 1 no final da curva.

Concluso

Um ponto interessante a se destacar que este tipo de comunicao no foi limitada pelo nmero de bytesenviados e sim por quantas vezes a operao de leitura do diretrio foi chamada, nos mostrando que

num ambiente no qual o canal no apresenta muitas restries (largura de banda alta, dentre outros) oque vai ditar a performance da comunicao ser a capacidade de processamento dos elementoscomputacionais, visto que ao longo de todos os testes utilizou-se o host local do computador.

Porm, caso o servidor e cliente estivessem geograficamente afastados, os parmetros do canalcomeariam a interferir significativamente na execuo dos programas, provavelmente aumentando otempo de execuo mdio proporcionalmente ao nmero de bytes enviados at um limite superior.Tambm haveria um risco maior de se perder, atrasar ou alterar mensagens, sendo necessrioimplementar mtodos mais refinados de temporizao, retransmisso, confirmao e verificao de erros,do contrrio a comunicao seria um fracasso.

Ao final deste projeto e por volta de 250 execues de teste, podemos concluir que tanto o cliente quantoo servidor conseguem efetuar uma conexo TCP tanto para protocolos IPv4 quanto IPv6 e transferir earmazenar de forma estvel e precisa todos os dados aos quais se prope, tornando este experimento umsucesso de acordo com os requisitos propostos e sadas esperadas.

Referncias Bibliogrficas

TCP/IP Programming in C - https://www.youtube.com/watch?v=V6CohFrRNTo

Using make and writing Makefile (in C++ or C) - https://www.youtube.com/watch?v=aw9wHbFTnAQ

http://linux.die.net/man/3/readdir

http://man7.org/linux/man-pages/man2/settimeofday.2.html

http://man7.org/linux/man-pages/man3/inet_pton.3.htmlhttp://man7.org/linux/man-pages/man2/getpeername.2.html

http://stackoverflow.com/questions/471248/what-is-ultimately-a-time-t-typedef-to

http://stackoverflow.com/questions/5901181/c-string-append

http://www-01.ibm.com/support/knowledgecenter/ssw_i5_54/rzab6/xacceptboth.htm?lang=pt-br

http://www-01.ibm.com/support/knowledgecenter/ssw_i5_54/rzab6/xip6client.htm?lang=pt-br

TCP IP Sockets in C, Second Edition Practical Guide for ProgrammersDONAHOO, Michael J.

Documentação-TP1

Documents

Transcript of Documentação-TP1