Pagina scratch

Horários no IFSC

Segunda-feira => 7:30 ás 9:30 e 13:30 ás 15:30

Terça-feira => 7:30 ás 9:30

Quarta-Feira => 9:30 ás 11:30

Sexta-Feira => 15:30 ás 17:30

Primeiro Laboratório Scratch

O objetivo deste primeiro laboratório no Scratch é desenvolver um ambiente que simule uma rede local com topologia em estrela (utilizando um switch),em anel (utilizando uma rede local Token-Ring) ou topologia em barramento e em seguida mostre a forma com que ocorre a troca de mensagens em cada protocolo. Será possível visualizar a troca de mensagens entre os computadores da rede através de simulações em broadcast, multicast e unicast, dependendo da escolha do usuário.

Nas simulações também será possível visualizar colisões de pacotes quando o meio estiver ocupado por outros dispositivos e aguardar um certo tempo para tentar transmitir novamente seus pacotes até o destino desejado. Com isso será possível compreender melhor o funcionamento do método de transmissão CSMA-CD, amplamente utilizado em redes locais Ethernet, onde o dispositivo "escuta" o meio antes de transmitir e, se ninguém estiver transmitindo no momento, a troca de mensagens ocorrerá entre A e B.

Em seguida será possível clicar em um botão para mudar este método para CSMA-CA, onde o dispositivo avisa que irá transmitir momentos antes de efetivamente transmitir, dessa forma todos os dispositivos sabem que alguém deseja usar o meio em determinado momento e então não ocupam-no. dessa forma será possível verificar as diferenças entre ambos métodos de transmissão, CSMA-CD e CSMA-CA. Também haverá simulações que demonstre o funcionamento e a forma como ocorre a negociação em modos simplex, half-duplex e full-duplex.

Também será possível inserir novos computadores e novas interfaces de rede aos computadores já existentes no cenário e em seguida realizar novas simulações. O cenário apresentará os endereços físicos (MAC) e endereço lógico (IP) de cada interface.

Casos de Uso Previstos

Caso 2 - O usuário clica sobre um PC para enviar uma mensagem para outro PC

Para a simulação iniciar, basta clicar em um dos 5 computadores da rede e inserir na caixa de texto que se abrirá o ID do computador de destino que se deseja enviar o pacote. Então, o pacote será enviado ao meio. Este fará a entrega do pacote até o destino desejado, porém, todas as demais estações receberão o pacote, no entanto, somente a que obtiver o ID designado lê a mensagem. Será possível enviar mais de uma mensagem ao mesmo tempo simplesmente clicando em outro computador e inserindo o endereço de destino desejado como da primeira vez. No entanto, quando uma mensagem é enviada ao meio, este fica ocupado e se houver a tentativa de ocupação do meio por outra mensagem, ocorrerá uma colisão. Por este motivo, a interface de rede "escuta" o meio e aguarda até que este esteja desocupado para enviar a mensagem. Desta forma, evita-se que a colisão ocorra.

=Caso 3 - Ocorrência de colisão

Haverá um botão chamado "Forçar colisão". Quando clicado neste botão, duas mensagens serão enviadas ao mesmo tempo e será possível observar o comportamento do sistema quando ocorrer uma colisão. Será sorteado um valor aleatório de tempo para os dois computadores tentarem retransmitir suas mensagens. Ao final deste tempo ocorrerá a transmissão. Aquele que obtiver o menor tempo sorteado transmitirá primeiro, o outro escutará o meio e aguardará que o mesmo fique desocupado após o estouro do tempo sorteado e enviará a mensagem ao destino desejado.

Caso 4 - O usuário constrói o cenário desejado

Haverá um botão chamado "Criar cenário". Quando clicado, aparecerá na tela o barramento em que os computadores da rede estarão conectados. Haverá também os cabos de rede que deverão ser conectados ao barramento. Para isso, basta clicar nele e arrastar até próximo a uma das extremidades no barramento. Haverá também a figura de um computador, basta clicar e arrastá-lo até a outra extremidade do cabo de rede que foi conectado ao barramento. Será possível conectar até 5 computadores e realizar os mesmos testes e as mesmas simulações citadas anteriormente.

Reunião 06/05

Foi apresentado uma prévia daquilo que deverá ser implementado no Scratch para a topologia em barramento. Esta prévia foi disponibilizado acima nesta mesma página. Em seguida foi apresentado as alterações da versão anterior do primeiro projeto no Scratch com uma topologia em barramento, sendo verificado algumas melhorias em relação a versão anterior, entre elas a entrega do pacote ao meio para o mesmo distribuir a todos dispositivos da rede, porém somente o destinatário "lê" a mensagem. Também foi implementado uma "ocupação do meio" enquanto há pacotes trafegando na rede, onde o mesmo também avisa quando está desocupado.

Foi discutido a possibilidade de implementação de, quando clicado em um PC enquanto já estaria sendo utilizado o meio, mostrar uma mensagem ao usuário dizendo que o meio estaria ocupado, sendo que, para 1 dos PCs, esta lógica já está funcionando. Ficou acordado que esta mensagem não deveria aparecer, apenas o pacote seria gerado e não seria despachado ao meio enquanto este não estiver livre. Sendo assim, seria possível dispensar a simulação que gera colisões.

Também foi discutido sobre a possibilidade de implementação de apresentação de um cabeçalho, contendo os endereços de origem e destino junto de uma mensagem que seria transportada pelo meio dentro dos pacotes já existentes e apresentada quando esta atinja o seu destino.

Por último, com relação a possibilidade de criação de cenários, foi levantada a hipótese de ser implementado um cenário que o usuário possa definir quantos PCs teria a rede dele e que ele simplesmente clicasse em um PC e automaticamente o sistema alocaria um ID, um endereço MAC para todas as interfaces de rede e os cabinhos para conectar os PCs ao meio físico.

Versão atual do projeto: [[Media:Arquivo:Barramento2.sb]]

Reunião 13/05

Neste dia foi apresentado as evoluções no desenvolvimento das simulações da topologia em barramento, onde um mini cabeçalho é gerado e apresentado em tela antes e após a entrega das mensagens entre os computadores. Também foi verificado que o sistema já dispunha de um algoritmo que evite colisões de mensagens na rede, isto é, se algum PC verifica que o meio está ocupado, ele prepara a mensagem para ser enviada mas não a envia até que o meio avise que está livre. Após o meio enviar o sinal que está livre, a mensagem é transmitida normalmente.

Com relação a criação de cenários por parte do usuário, foi levantada a hipótese de usarmos o "MIT SCRATCH ONLINE", que dispõe de uma facilidade para criação de clones de objetos, facilidade esta que poderia ajudar nas implementções. No entanto, houveram algumas dificuldades na adaptação com o novo sistema e no estudo de suas novas funcionalidades e por isso o desenvolvimento do laboratório de criação de cenários ainda está nos primórdios.

Para a próxima semana, ficamos acordados que seria interessante se o cenário de criação de topologias implementasse uma funcionalidade especial: que o meio propagasse a mensagem não mais através de pacotinhos, mas que fosse "preenchesse o meio" com as informações e elas prosseguissem até o destino como se fosse água dentro de um cano, tudo isso utilizando o MIT-SCRATCH. Antes de tudo, o cenário para criação de topologias deveria estar implementado, já que ele é extremamente necessário para a realização dos testes, portanto, este deve ser o próximo passo a ser concluído.

Reunião 20/05

Na reunuão deste dia foi levantada uma certa dificuldade em manipular clones gerados pelo Scratch 2.0, pois a princípio não haveria como reutilizar um clone gerado anteriormente e efetuar novas manipulações a partir deste clone. Então, foi levantada a hipótese de colocarmos um contador que vá incrementando seu número sempre que um novo clone é gerado. Esse contador seria o ID do clone. Então bastaria realizar um teste com este contador, se este fosse o ID do clone clicado, então fariamos a ação necessária. Vimos que dessa forma será possível manipular clones antigos quando clicado sobre os mesmos.

Também foi discutido a respeito da forma como a informação deveria "fluir" no meio. E uma forma interessante levantada foi a de utilizar clones que representariam a informação atravessando o meio após a criação do cenário pelo usuário. Ficou acertado que, a princípio, haverão posições nas coordenadas do palco que serão específicas para que haja a presença de um PC, isto é, haverá um limite (entre -10 e 10 por exemplo de X), e se o PC for colocado entre este limite, ele deverá ir automaticamente para a posição 0 de X, para que seja possível criar uma forma matemática para os fluxos de informação da origem até o destino.

Reunião 27/05

Neste dia foi apresentado alguns avanços no desenvolvimento do cenário de criação de topologias, entre elas o fato de, quando clicado no cabo de rede, um clone do mesmo aparece no ponteiro do mouse e nele fica até ocorrer um novo clique. Além disso, tanto para o cabo de rede como para o PC, quando ambos atingem um raio de 10 unidades das coordenadas do palco, o objeto vai automaticamente para onde ele deve ser posto, e além disso, para o PC, essa lógica só funcionará caso haja um cabo espetado no meio. Também foi apresentado uma pequena ideia de como pode ser o fluxo de informação no meio com clones.

Em seguida, foi sugerido que seja implementado um mini sistema que trafegue informações pelo meio e que fosse utilizado clones para representar cada bit (zero e um), além de haver um terceiro estado com um clone de cor diferente que represente algum dado que tenha sofrido colisão.

Reunião 03/06

Na reunião deste dia foi apresentados as novas implementações do sistema que mostre como é feita a troca de bits em um meio de comunicação, conforme descrição da reunião anterior. Nesse sistema, o usuário clica em uma das extremidades (emissor) e digita uma mensagem (binária) para que esta trafegue pelo meio até a outra extremidade (receptor). Então, a mensagem é transformada em "bolinhas" vermelhas (bit 0) ou verdes (bit 1) e viajam com sincronismo até seu destino que reconhece a chegada das "bolinhas" e as interpreta para que seja possível compreender a mensagem original.

A única coisa que a princípio não estaria funcionando é a colisão. Então, conforme discutido em reunião neste dia, deveria ser feita algumas correções no código, entre elas a substituição de 2 sprites referentes aos 2 tipos de bits por apenas 1 sprite e este realizasse clonagens e mudanças de trajes para representar o bit que se necessite. As chaves que são 2 sprites que geram e recebem os bits também devem ser clones a partir de 1 único sprite. Além também da correção de bugs que estão ocorrendo em virtude de uma lógica discutida para a utilização de uma lógica de representação de bits com colisão que foi feito uma tentativa de implementação no cenário.

Reunião 10/06

Neste dia foi apresentada algumas evoluções no projeto de comunicação através do meio entre dois dispositivos. A maior evolução em relação a semana anterior é que agora existe apenas um sprite para todos os tipos de bits e apenas um strite para a chave que representa uma interface de rede do dispositivo de comunicação. Isso foi possível graças a utilização de clones em posições desejadas para as chaves e múltiplos clones para os bits combinados com mudanças de traje que nada mais é que um único sprite podendo variar em 3 cores de acordo com aquilo que se deseje representar (bit0, bit 1 ou bit com colisão). Também foi visto que o projeto possui uma lista que indica a mensagem que cada dispositivo deve receber.

Entretanto, foi verificado e discutido algumas funcionalidades que não estariam de acordo com um cenário real e sendo proposta a alteração da forma como estaria implementado. A mais importante mudança diz respeito ao fato de o próprio bit identificar a chave de destino quando este a encontrar, quando na verdade é a chave quem deve identificar a chegada de um bit e armazenar o valor em um buffer próprio, para cada chave, e não com um único buffer para todo o cenário como está implementado. Foi verificado também uma anormalidade em bits com colisão, onde apenas um dos bits colididos muda o traje para a cor Roxa, quando os dois deveriam mudar de cor. Além disso, a própria chave deve escutar a chegada de bits para identificar colisões e parar de transmitir por um tempo para em seguida retransmitir a sua mensagem em um tempo aleatório.

Para a próxima reunião, a meta é resolver as anomalias e os bugs ainda presentes no projeto e em seguida fazer um estudo da implicação de um novo dispositivo final no cenário e onde a entrada de um Hub ou Switch poderia facilitar as implementações de uma rede em crescimento.

--Roicenir.r 10h17min de 24 de abril de 2013 (BRT)Roicenir Girardi Rostirolla