Arianne de Paula Bortolan GRR20140220 Dante da Silva Aleo GRR20171593
1 - Nosso programa foi escrito em Python 3, por isso para executar os programas utilize comando: python3 e não o comando python. 2 - O nosso servidor UDP realiza scrapping de tweets do twitter para criar a stream para seus clientes, para isso ele utiliza uma biblioteca não instalada por padrão no dinf tornando assim necessário a instalação dessa biblioteca (tweepy), para poder executar o servidor, para instalar a biblioteca sem utilizar sudo e somente localmente, execute o comando abaixo: pip3 install --user tweepy 3 - Para executar o servidor você deve informar os seguintes parametros: porta e intervalo de envio de cada pacote, exemplo abaixo: python3 server.py 6000 5 4 - Para executar o cliente você deve informar o ip do servidor, a porta e quantos tweets deseja receber do servidor, exemplo: python3 client.py 127.0.0.1 6000 25 5 - Por questões de segurança inserimos dois arquivos server.py, o primeiro em server.py.txt não contem os tokens de autenticação do twitter, ou seja, não funciona e é somente para visualização do código, o segundo está no formato .tar e com link para download direto, este contém os tokens e é funcional!! A razão para isso é para que bots não façam scrap do token de dev que utilizamos para conectar no twitter.
Este trabalho tem como objetivo a implementação de um servidor UDP com capacidade de atender multiplos clientes. O servidor envia para os clientes uma Stream de Tweets que contenha qualquer um dos seguintes temas: Cloud, Information security, Hacking e Python. Nosso servidor se conecta a API do twitter e realiza essa mineração de tweets filtrando pelos tópicos mencionados anteriormente e os envia para os clientes conectados. Para essa conexão com a API do twitter utilizamos o token de desenvolvedor para uma conta dummy feita somente para esse trabalho e utilizamos a biblioteca python tweepy, que contém as funções que realizam a autenticação com a API do Twitter. O fluxo de comunição é o seguinte, o servidor se conecta a API e começa a coletar tweets e então ele entra no modo de espera para clientes se conectarem, os clientes se conectam ao servidor enviando seu ip e nome de máquina, sendo o nome inserido pelo o usuário, o servidor então, separa a comunicação de cada cliente em uma thread respondendo eles de maneira independente e individual, ou seja, o pacote de número dois do cliente Y é diferente do pacote de número dois do cliente Z. Cada cliente define quantos tweets deseja receber, já o servidor define o tempo de intervalo pra envio de cada tweet. No fim de tudo o cliente recebe em tela os tweets e os salva em um arquivo com o nome "nome da maquina"_tweets. Além de gerar um log de execução final que mostra as estatisticas de pacotes. Cada cliente gera um log individual pra cada conexão tida com o servidor, o nome do log gerado por cada máquina é "nome da maquina"_log, e além do log com estatisticas, ele salva os tweets recebidos com a hora em que fora recebidos. A razão para tratarmos cada cliente de forma individual em thread foi para conseguirmos fazer nosso servidor UDP simular uma stream TCP, em sockets TCP no python, não é necessario o servidor esperar por uma mensagem do cliente pois ele não depende do ip para enviar mensages. Já no UDP temos esse problema de o cliente sempre ter que enviar uma mensagem para o servidor primeiro, para que ele possa enviar mensagens ao cliente. Utilizando threads podemos deixar o servidor em um processo sempre esperando mensagem de novos clientes, enquanto outros processos do mesmo programa, ficam enviando as streams de tweet sem ter que serem interrompidas. Segue um diagrama com a arquitetura do nosso programa:
Logs três máquinas cliente: Cliente Um Cliente Dois Cliente Três Código cliente: client.py Código server (versão funcional em .tar pois contém os tokens de autenticação): server.tar Código server (versão para visualização em txt sem tokens): server.py