Universidade Federal de Minas Gerais Redes de Computadores

SOCKETS
Trabalho Prtico 01

Gabriel Natan Pires Silva - Matrcula: 2013024384

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 ....................................................................................... 13
Testes Variando o Nmero de Bytes Total .................................................................................. 15
Anlises e Discusses ......................................................................................................................... 18
Acerca do Funcionamento .............................................................................................................. 18
Acerca da Performance .................................................................................................................... 18
Concluso ................................................................................................................................................ 19
Referncias Bibliogrficas .................................................................................................................. 19

Introduo
No ambiente das redes de computadores, a comunicao entre mquinas pode se dar de diversas
maneiras: 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 de
comunicao entre cliente-servidor tornou-se corriqueira e, portanto, essencial sua compreenso e
manipulao.
Sendo assim, o objetivo deste trabalho ser a implementao de programas que simulem um servidor e
um cliente, operando de forma complementar ao outro e se valendo do protocolo TCP (largamente utilizado
no desenvolvimento de ferramentas para a internet).
O par de programas se comunicar atravs de requisies e respostas, de forma a interligar a interface de
socket do cliente com a do servidor e cada um ouvindo e escrevendo na socket alternadamente, de forma
a 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 de
se utilizar funes padro como printf().
String.h foi utilizada a fim de implementar funes de
manipulao strings como sprintf(), strcat(), dentre outras,
importante visto que nosso objetivo requer envio de
mensagens de texto.

Em seguida foi necessrio uso de bibliotecas especficas para implementar a comunicao entre o servidor
e 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 bytes
que 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 um

typedef para no ser necessrio digitar
struct antes da declarao da estrutura
sockaddr_in6 (j definida em sys/socket.h
e netinet/in.h.
A estrutura BUFFER contm um
apontador para vetor de caracteres
focado na leitura da socket (read), outro
na escrita (write) e outro (fileSpec) apenas
para definir o nome do documento de
texto
(que
deve
se
chamar
<end_cliente><nome_diretrio><.txt>).
SERVER, por sua vez, contem um inteiro
sockfd, que vai conter o valor da socket
aps aberta, portno que ir conter o
nmero da porta do servidor e um tipo
sockaddr_in6 addr que ir conter
parmetros do endereo do servidor (se IPv4 ou IPv6, por exemplo). Escolheu-se sockaddr_in6 e no
sockaddr_in justamente para operar com ambos protocolos.
J NEWCLIENT semelhante ao SERVER, diferindo apenas por no ter portno e tendo addr_lenght que
contm o valor de sizeof(NEWCLIENT.addr), e ip um vetor de caracteres do tamanho de um endereo
IPv6, que ir conter o endereo IP do cliente em forma de texto.

Resumo de Funcionamento do Cdigo

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 sejam
fornecidos dois argumentos adequados (<./executvel>, <porto_servidor>), inicia a conexo e gera um
documento de texto (at ento vazio) com respectivamente inicia_conexao(server,newclient,argv[1]) e
define_nome_txt(newclient,&buffer).
A comunicao apenas um loop que funciona enquanto no for recebida a mensagem de encerramento
bye 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 do
Cliente - (neste caso deve-se remov-lo e armazenar o nome real no arquivo com
atualiza_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 loop escreve na socket com
write(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 ambos
IPv4 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 automaticamente
tratados 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 as
bibliotecas sys/time.h que contm a funo gettimeofday() e a
estrutura necessria para seu uso timeval.
J a biblioteca dirent.h que implementa as estruturas DIR e
dirent, bem como funes de abertura de diretrio opendir(), e
de leitura de seu contedo readdir().

Os quatro primeiros typedef vistos a

esquerda so pelo mesmo motivo citado nas
estruturas do servidor (linha 12), bem como
o BUFFER (dessa vez sem fileSpec).
As novidades implementadas no cliente so,
primeiramente, a estrutura ESTATISTICAS
que armazena o nmero de bytes enviados
em total_dados, a durao da execuo em
tempo_execucao em segundos e por fim a
vazo de dados em bytes por segundo.
Por fim h a estrutura CLIENT, que contm
um inteiro sockfd para armazenar o nmero
da socket aberta, in6_addr serv_addr que
contm informaes sobre o servidor que se
tenta conectar (exemplo, se IPv4 ou IPv6,
qual endereo, dentre outras), e uma
estrutura hints e um apontador *res do tipo
addrinfo, que como sugere o nome carregam
parmetros da socket do cliente (como por
exemplo, se dados sero enviados em
STREAM ou DATAGRAM).

Resumo de Funcionamento do Cdigo

Pelo fato de funcionar de forma complementar ao servidor, esperava-se que o cliente fosse estruturalmente
parecido 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 sejam
fornecidos quatro argumentos adequados (<./executvel>, <host_servidor>, <porto_servidor>,
<nome_diretrio>), inicia a conexo atravs de inicia_conexao(client, argv[1], argv[2]) e envia ao servidor
o nome do diretrio de origem dos arquivos, atravs de define_nome_txt(client,&buffer,argv[3]).

A comunicao inicia escrevendo na socket READY, chama gettimeofday(&t_inicio, NULL) e aps

receber READY ACK (atravs da leitura de socket) j l os nomes dos arquivos no diretrio em ciclo
com 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 aguarda
recebimento de FILE ACK lido na socket (read(client->sockfd,buffer.read,MAX_STR-1) para repetir a
leitura, 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 bytestuffing que consiste em acrescentar
um 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 armazena
no primeiro argumento a hora do dia naquele instante, em segundos e microsegundos, e o segundo
parmetro desnecessrio, pois corresponde ao fuso (NULL neste caso representa o default da mquina
que seria autocompletar seu fuso).
Para obter a durao da execuo basta realizar t_fim t_inicio. Como so estruturas que contem
segundos 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 throughput para 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 em
inicia_conexao(). No momento de definir os parmetros da conexo (em hints), a famlia foi definida como
no especificada (pode ser tanto IPv4 quanto IPv6), atravs de client->hints.ai_family = AF_UNSPEC. Em
seguida dividiu-se em dois casos: caso ao converter o endereo IP do servidor (declarado como tipo
in6_addr por 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 e
inet_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 uns
especficos 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;

Gerar um documento de texto com ttulo formatado no modelo supracitado, contendo os

dados coletados do cliente (um nome por linha) - Caso algum nome tenha sofrido
bytestuffing, 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 diretrio
especificado 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 a
taxa de transferncia entre cliente e servidor.

Para verificar tais requisitos funcionais utilizou-se a insero de linhas de cdigo que imprimem o status
da execuo ao longo da mesma e analisou-se o surgimento das mesmas no terminal. Os status
esperados 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 o
servidor adequadamente e servidor aguarda READY. Se X for iniciado com ::, o cliente se conectou por
IPv6, se no, se conectou por IPv4.
- Documento a conter nomes [...]: <end_cliente><nome_diretrio>.: Comprova criao do documento de
texto 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 que
automaticamente substitui os / por > para evitar problemas)
- Cliente pronto para enviar arquivos. Autorizando envio.: READY recebido pelo servidor, READY ACK
enviado.
- Cliente concluiu o envio. Foram recebidos K arquivos. Conexao encerrada.: Confirma recebimento do
bye 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 enviou
READY.
- Autorizao de envio recebida. Enviando arquivos.: Comprova recebimento de READY ACK e incio
de envio dos dados.
- Dados da execucao [...]: Mostra trmino do envio, envio de bye ao servidor, exibio das estatsticas
exigidas e encerramento da conexo.

Testes de performance
Ao longo do desenvolvimento do par de programas, observou-se que no s o nmero de bytes era
relevante para a alterao de tempo de execuo e taxa de transferncia, como o nmero de arquivos
enviados 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 arquivos
enviados, tempo da amostra, tempo mdio, desvio padro populacional do tempo e throughput mdio.
Foram analisados o envio de 2j bytes, tal que 0 j 17 e j um nmero natural. Para cada valor de j foram
feitas 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 4
grficos: dois de tempo mdio (em ms) em funo do nmero de bytes (um em escala linear e outro
logartmica) 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 throughput mdio. Foram analisados o
envio de 128 bytes fixos, divididos em 2m arquivos, tal que 0 m 5 e m um nmero natural. Para cada
valor de m foram feitas 10 amostras de tempo e suas respectivas taxas de transferncia e automaticamente
as tabelas calcularam os dados restantes. Em seguida elaborou-se 4 grficos: dois de tempo mdio (em
ms) em funo do nmero de arquivos (um em escala linear e outro logartmica) e dois de throughput
mdio (em kB/s).
Todos os grficos foram elaborados e posteriormente analisados (ajuste linear, exponencial ou sigmoidal)
no programa OriginLab Origin 2015 (64 bits Sistema Operacional Windows 8 Mesma mquina citada
anteriormente).

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:

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

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):

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

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

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

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

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. No
entanto, pelo fato de utilizar-se no eixo das abcissas sempre potncias de 2, optou-se por exibir e discutir
neste 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 um
continha esta soma dividida em partes iguais para 2s arquivos, sendo 0 s 5, ou seja, o cliente ir enviar
de 1 32 mensagens, em potncias de 2 mensagens. Os resultados foram os seguintes:
Tabelas com a coleta de dados:

Grfico tempo de envio em funo do nmero de arquivos:

Curva que se adequa ao modelo:

= 0.0513 + 0.268

Grfico throughput em funo do nmero de arquivos:

(0.0316)
2.967

Curva que se adequa ao modelo:

= 41.098 + 602.095 2.17

Testes Variando o Nmero de Bytes Total

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

Tabelas com a coleta de dados:

Grfico tempo de envio em funo do nmero de bytes:

Curva que se adequa ao modelo:

= 0.237 + 0.001

(2.36)
1.463

Grfico throughput em funo do nmero de bytes:

Curva que se adequa ao modelo:

(4268.787)

= 35.139 + 1+100.258(10.126)

Anlises e Discusses
Acerca do Funcionamento
Conforme citado em Verificao de Funcionamento Correto e Adequado aos requisitos, as impresses
expostas no terminal servem para indicar quais passos foram cumpridos ao longo da execuo do par
servidor-cliente. Para que se possa afirmar que os cdigos funcionaram conforme o esperado necessrio
analisar 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-se
algum 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 que
ele realizou sua abertura (se servidor estiver fechado ou host incorreto h o mesmo erro). Por fim ao inserir
um 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 instante
antes do cliente fechar no h o que ser lido pelo servido j que no h diretrio a ser analisado e aps o
cliente fechar, o servidor deve avisar que o seu par se desconectou. Logo, at ento o cdigo se comportou
exatamente 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 Tentando
conectar-se em IPv4 e o servidor exibe o endereo do cliente e sua porta (comeada com 4 ou 5) e a
impresso na tela para IPv6 apresenta mesmo formato, com porta iniciada por 3, indicando que ambos
funcionam tanto para IPv4 quanto IPv6. Tanto cliente quanto servidor exibem todas as mensagens de
prontido e autorizao, bem como as estatsticas e nome do arquivo previstas, mostrando que esses
mecanismos operam corretamente. Ao estudar o contedo da pasta TESTE-BYES verificamos que h um
bye, um byebye e um byenatan, no primeiro o programa (se no tratado) fecharia, no segundo e
terceiro se o bytestuffing estivesse 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 exponencial
crescente 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 variao
exponencial 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 arquivos
em mente podemos perceber que inicialmente a curva de tempo em funo do nmero de bytes enviados
apresenta comportamento aproximadamente constante em torno de 0.23 ms para x < 8, que corresponde
ao trecho que, conforme a tabela indica, somente uma mensagem foi enviada, e para x > 8 h um
comportamento exponencial crescente, comprovando a suspeita de que o fator crtico para determinao
do tempo de execuo o nmero de arquivos enviados.

Por fim, vale destacar a curva de throughput em funo do nmero de bytes, pois seu comportamento foi
bastante singular e esclarecedor ao longo dos ensaios. A primeira poro, para x < 8, se assemelha uma
exponencial crescente, enquanto a segunda poro seria uma exponencial crescente com expoente
fracionrio, formando, juntos, uma curva sigmoidal. A primeira parcela nos mostra o momento em que o
nmero de mensagens constante igual a um, logo a taxa de transferncia ditada apenas pelo nmero
de 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 em
aproximadamente 4 MB/s (tomando 1M = 1000 k), pois neste trecho quando o nmero de bytes dobra o
nmero 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 bytes
enviados 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) o
que vai ditar a performance da comunicao ser a capacidade de processamento dos elementos
computacionais, 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 canal
comeariam a interferir significativamente na execuo dos programas, provavelmente aumentando o
tempo 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 necessrio
implementar 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 quanto
o servidor conseguem efetuar uma conexo TCP tanto para protocolos IPv4 quanto IPv6 e transferir e
armazenar de forma estvel e precisa todos os dados aos quais se prope, tornando este experimento um
sucesso 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.html
http://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 Programmers DONAHOO, Michael J.