Aug

30

2 anos no ar!

August 30, 2009 | Leave a Comment

Eu não vou emitir um post muito longo, até porque hoje foi um dia atípico no trabalho, sabe como é … e amanhã começa tudo de novo. Venho mais uma vez comemorar o aniversário deste portal, pelos seus dois anos no ar ininterruptamente tentando colaborar de alguma forma para o futuro de nosso país.

Mais uma vez agradeço a todos aqueles que de certa forma foram “influenciados” pelas críticas postadas aqui, e que a partir de então passaram a ter uma atitude mais cidadã com a sociedade, contribuindo para a posteridade de forma mais efetiva do que antes. A todos os leitores o meu Muito Obrigado.

Atenciosamente,
Renato Pesca

Aug

22

Lua

August 22, 2009 | Leave a Comment

Lua is easy, it is a relatively new language, interpreted as Java , Python, some other languages, but natively brazilian. It was developed in 1993 by individuals at Tecgraf and Lablua, laboratories of Department of Computer Science of PUC-Rio.

After talking with a friend currently undergraduating in computer science, where he has related his good relationship with the language, I have decided to perform tests.

Then, I found this site with some useful information for dummies as me. I think it can help people searching to learn the basic of the language. Click here and you will be redirected to the site.

Aug

19

Continuando com nossos posts sobre a Camada de Enlace, hoje eu abordarei os processos de detecção e correção de erros de bits, mais particularmente sobre a técnica de paridade. Ela ilustra as idéias básicas sobre detecção de erros em dados transmitidos.

O cenário ilustrado consiste em um emissor, que pretende enviar D bits ao receptor. Como não podemos garantir uma transmissão isenta de erros, supomos que o receptor recebe D’ bits. A paridade consiste em: enviar D bits + bit de paridade. O bit de paridade será 0 ou 1 de acordo com o número de bits 1 presente na quantidade de D bits. Caso tenhamos um número ímpar de bits 1 no conjunto nosso bit de paridade será 1, caso contrário, 0. Observe que o bit de paridade enviado também pode ser corrompido durante a transmissão.

Veja que esta técnica é falha, pois a princípio recebemos D’ bits + bit de paridade’, ou seja, podemos receber ambas as quantidades corrompidas, D’ e o bit de paridade não-corrompido, ou D e o bit de paridade corrompido.

Considere o exemplo abaixo:

  1. Emissor: D = 11001011; bit de paridade = 1 => total de bits 1: 6(par)
    Receptor: D’ = 11001011; bit de paridade’ = 1 => total de bits 1: 6(par)
    Conclusão: nenhum erro detectado
  2. Emissor: D = 11001011; bit de paridade = 1 => total de bits 1: 6(par)
    Receptor: D’ = 11001111; bit de paridade’ = 1 => total de bits 1: 7(ímpar)
    Conclusão: erro detectado
  3. Emissor: D = 11001011; bit de paridade = 1 => total de bits 1: 6(par)
    Receptor: D’ = 00111011; bit de paridade’ = 1 => total de bits 1: 6(par)
    Conclusão: nenhum erro detectado

Observe o ítem 3), onde há corrupção de dados não identificada pelo algoritmo de detecção. Esta situação é denominada erros de bits não detectados. Neste caso um quadro da camada de enlace recebido seria desencapsulado e um datagrama defeituoso entregue à camada de rede.

Experiências demonstraram que erros de bits se aglomeram em rajadas. A probabilidade de haver erros não detectados em um quadro protegido por um esquema do tipo pode alcançar 50%.

Logo, técnicas mais eficientes precisam ser utilizadas: a) métodos de soma de verificação, comumente implementados em protocolos de camadas superiores; b) verificação de redundância clíclica(CRC), implementada em adaptadores, na camada de enlace. Estas técnicas serão objeto de um próximo post.

Aug

11

Há cerca de um mês eu precisei resolver um problema em um servidor que envolveu conhecimentos de Hierarquia em Certificação Digital. Para que o conhecimento fosse compartilhado no local objeto da atividade eu escrevi algo sobre o tema. Como considerei o escrito interessante, gostaria de divulgá-lo em meu Blog também.

O modelo de certificação digital é baseado em chaves públicas, ou seja, se Manoel e José desejam trocar mensagens seguras, cada um publica uma mensagem usando a chave pública do outro. A única falha neste processo é que Manuel, irmão gêmeo de Manoel, desejando ler mensagens destinadas ao irmão, pode publicar uma chave pública fazendo-se passar por Manoel.

Para resolver este problema cria-se uma Entidade Certificadora, aqui denominada EC, que tem a confiança de todos os participantes da ICP (Infra-Estrutura de Chaves Públicas), ou seja, a EC faz parte de um conjunto de EC’s, e cada EC tem seus usuários atrelados à ela.

Desta forma, quando queremos enviar uma mensagem para Manoel, sabendo que o seu certificado é assinado pela EC correspondente, temos confiança de que estamos realmente nos comunicando com Manoel.

Quando os certificados não são emitidos pela mesma EC, considerando que nós, denominados X (pertencentes à Entidade EC1) queremos nos comunicar com Y (pertencente à Entidade EC2), uma relação de confiança precisa ser estabelecida entre X e Y, para que possamos confiar na chave pública de Y e então estabelecer uma conversação segura.

Esta relação de confiança pode ser validada quando a chave pública do certificado de Y também é assinada por uma entidade de nível maior. Esta entidade de nível maior por sua vez pode não ser a entidade no topo da hierarquia (a entidade no topo da hierarquia tem o seu certificado auto-assinado). Assim, precisamos percorrer a hierarquia até o final para nos certificarmos da validade da chave pública com quem estamos tentando comunicação.

Este foi só um exemplo de relação de confiança (existem relacionamentos de confiança muito mais complexos). O exemplo acima ilustra o surgimento da hierarquia de certificados, e a necessidade de Certificados Intermediários em algumas situações para validar a comunicação entre dois nós (um dos nós quase sempre representa um host, o outro pode representar um servidor Web que pretende oferecer conteúdo comprovadamente seguro).

Aug

9

Aug

9

Aug

9

Aug

9

Aug

9

Mais uma banda com boas músicas que não tocam nas rádios do Pindorama.

Aug

5

Basicamente podemos dizer que há dois tipos de canais: a) broadcast; b) enlaces de comunicação ponto-a-ponto.

Um protocolo de camada de enlace é usado para transportar um datagrama por um enlace individual. Neste ponto definimos as unidades de dados trocadas pelo protocolo como quadros. O protocolo é responsável pela movimentação dos datagramas da camada de rede nó a nó. Vale ressaltar que durante o trajeto de um datagrama este pode ser manipulado através dos enlaces por diferentes protocolos de enlace.

Os serviços oferecidos por um protocolo nesta camada incluem: a) enquadramento de dados [ a estrutura do quadro que encapsula um datagrama é determinada pelo protocolo a ser utilizado ] ; b) acesso ao enlace [ um protocolo de acesso ao meio define regras segundo as quais um quadro é transmitido no enlace quando vários nós compartilham o mesmo enlace de broadcast ]; c) entrega confiável [ muitos protocolos não fornecem um serviço de entrega confiável pois a implementação de reconhecimentos e retransmissões em hardware representariam custo adicional na fabricação de NICs, assim como pelo fato de que o serviço já é oferecido por protocolos de camadas superiores ]; d) controle de fluxo [ caso seja implementado no protocolo, o serviço evita que o nó remetente congestione o nó receptor ]; e) correção de erros [ auxilia o nó receptor na detecção de erros, e pode permitir que este nó detecte em que parte do quadro há corrupção de dados ]; f) half-duplex e full-duplex [ full-duplex corresponde à capacidade de um nó enviar e receber informações simultaneamente através de um enlace ].

No próximo post tratarei de técnicas de detecção de erros, a saber: verificação de paridade, métodos de soma de verificação e verificação de redundância cíclica, conhecida como CRC (sigla em inglês).

keep looking »

Links

Skype: SkypeMe™!

Icq: