Archive

Archive for the ‘Computer Theory’ Category

Preparando as RFCs para o UIMA

Introdução

Uma vez entendido o UIMA segue a aprendizagem sobre ele. Olhando primeira figura do texto Instalação do Apache UIMA (Apache UIMA Installation), vê-se o conjunto de material não estruturado a ser analisado, reproduzida na Figura 1, com ênfase no repositório do RFC Editor, onde repousam os principais documentos do IETF.

aeasd-1

Figura 1. O repositório das RFCs. Primeira base não estruturada a ser analisada pelo UIMA.

Como trabalhar com o repositório das RFCs

RFCs não possuem data e hora marcadas para aparecer e, estão em um formato que deve ser normalizado (brancos, figuras em texto, autores, diferenças de padrões de escrita, etc.), para adaptar-se ao UIMA ou outra aplicação. Este processo de normalização é, na verdade uma “arrumação” sobre os dados de entrada e possui as característica descritas por Wickham (2014)1. Portanto é necessário, um pré-processamento, no qual estas duas questões serão resolvidas. A Figura 2 apresenta um modelo preliminar a ser seguido.

uima-preprocessamentorfcs

Figura 2. O pré-processamento das RFCs.

O próprio RFC Editor recomenda um mecanismo2 de recuperação de RFCs usando o rsync, uma ferramenta disponível nos sistema a la Unix e também, no Windows. Como mostra a Figura 2, o rsync trás a base do RFC Editor para o diretório rfstemp/ local, de forma incremental, como se desejava. Sobre este diretório, um programa em Python (denominado preprocess.py) é executado periodicamente e, sempre, executa o rsync, transferindo as novas RFCs para o diretório rfcs/, as quais são consumidas pelo UIMA. A Figura 3 mostra o exemplo de uma execução do rsync, no Windows 10, via prompt e uma nova RFC disponível (rfc7715.txt). Naturalmente, esta execução não foi a primeira vez, oportunidade em que isto é, o diretório rfstemp/ já tinha sido populado com TODAS as RFCs.

uima-rsync-exemplo

Figura 3. Execução do rsync e a disponibilidade de uma nova RFC enfatizada em vermelho.

A periodicidade de execução do programa preprocess.py é feita, automaticamente, através do cron (um processo, também, disponível para o Windows). Ele preserva a informação sobre a última RFC atualizada, captura as novas, normalizando e colocando-as no diretório de entrada para o UIMA (rfcs/). O processo de normalização é simples, retirando tudo o que é texto inútil de cada RFC (brancos, rodapés, etc.). Em função do UIMA, o programa preprocess.py, eventualmente, evoluirá o processo de normalização e/ou aperfeiçoará a entrada (isto é, o conteúdo do diretório rfcs/).

O UIMA, ao consumir as RFCs deixa o diretório rfcs vazio. Nas atividades do UIMA, Java é a principal linguagem, como vimos no primeiro artigo da série: Instalação do Apache UIMA (Apache UIMA Installation). O segundo artigo é uma visão geral do UIMA: Funcionamento Básico do Apache UIMA


  1. Wickham, H. Tidy Statistic. Journal of Statistical Software, Foundation for Open Access Statistics, v. 59, n. 10, 2014.
  2. https://www.rfc-editor.org/retrieve/rsync/

Expressões regulares, autômato finito não determinístico e autômato finito determinístico


 

Introdução

 

No desenvolvimento de um programa (http://www.braga.eti.br/ca/) para exibir quaisquer das 256 regras de autômatos celulares (ACs) propostos pelo incrível Stephen Wolfram, em seu volumoso livro “A New Kind of Science” deparou-se com a questão, simples, de como tratar as possíveis combinações de entrada, do referido programa, já que o usuário poderia:

  1. Pedir o AC de uma única regra (x, onde 0 \leq x \geq 255);
  2. Pedir um conjunto de ACs no seguinte formato: xy, onde x, y \leq 255\,\,e\,\,x < y;
  3. Pedir vários ACs, combinando as duas alternativas anteriores separadas por vírgula (,), em um número finito (e, arbitrário) de vezes.

Este artigo trata das etapas necessárias para que se possa implementar, de forma correta, o tratamento da entrada do programa proposto. Tais etapas são: (a) a construção da expressão regular, (b) a transformação da expressão regular em um autômato finito não determinístico (NFA), (c) a redução do NFA para um autômato finito determinístico (DFA) e, (d) a implementação propriamente dita.

 

Expressão Regular

 

Na literatura de computação, principalmente, os trabalhos de pessoas que lidam com inseguridade como, por exemplo, LANGSEC: Language-theoretic Security recomendam, insistentemente, o uso de linguagens regulares para tratar as entradas de um programa. Nesta direção, se considerado que nos itens de 1 a 3 das especificações acima, as variáveis x e y (diferentes entre si) são números de 0 a 255 pode-se adotar tais números como símbolos, e com as abstrações admissíveis usar a letra (ou símbolo!) n para representá-los e, adicionalmente reconhecer, que dois outros símbolos como pré-requisitos, (, e ), as seguintes combinações de entrada são possíveis:

  • n
  • n, n-n
  • n, n-n, n, …,n, n-n, …
  • n-n, …, n, …,n, n-n, …
  • etc

De tais combinações, depois de um pequeno esforço mental é possível identificar a expressão regular que responde ao desejado:

(n\mid nn)(,n\mid,nn)^*

A noção de abstração aplicada à formulação da expressão regular implica que serão deixadas para a implementação, as questões limitantes do uso do símbolo n e da representação infinita do *.

Dada a expressão regular, a próxima etapa é a construção do NFA.

 

Autômato finito não determinístico (NFA)

 

Construir um NFA a partir de uma expressão regular utilizando-se do algoritmo disponível em várias referências é uma tarefa extremamente agradável, muito embora, um pouco trabalhosa. em determinados casos. Entretanto, na Internet existem diversos ambientes para construção do NFA, de forma automática. Um deles é o Regular Expression to NFA. Usando-o, obtemos o NFA exibido na Figura 1.

 

nfa-erca

Figura 1. NFA obtido automaticamente. Fonte: Regular Expression to NFA.

 

Autômato finito determinístico (DFA)

 

O mesmo construtor do NFA, fornece o DFA, imediatamente, conforme visto na Figura 2.

 

dfa-erca

Figura 2. DFA produzido a partir do NFA da Figura 1. Fonte: Regular Expression to NFA.

 

 

Implementação

 

No Capítulo 10, “Patterns, Automata, and Regular Expressions”, do livro de Al Aho e Jeff Ullman, imperdível e disponível na Internet em Foundations of Computer Science, exibe um algoritmo de implementação de um autômato, extremamente simples, como se pode verificar. Foi usado aquele algoritmo para a implementação e, na oportunidade garantindo as restrições sobre a expressão regular lembradas acima.

Máquinas de estado finito: Parte Prática: MEF do BGP

 

Introdução

 

O foco deste blogue é a infraestrutura da Internet (II). Vez ou outra, um deslize ocorre resultando um texto inesperado e desconexo com a II. Geralmente, tais desvios decorrem de motivações que não estão claras nos textos mas que, eventualmente, serão esclarecidas.

Dada a justificativa, o texto atual está orientado a um dos componentes que irão fazer parte do projeto descrito em [3]. Trata-se da máquina de estado finito (MEF), base para o autômato finito presente na relação entre ROPEs (Repositórios de Objetos de Projeto Estendidos). Máquina de estado finito é um modelo que captura trecho de uma computação. Há definições melhores, e para avançarmos sobre elas veremos os aspectos práticos e teóricos relacionados.

A visão prática é a máquina de estado finito ou MEF, do BGP, já falada no blogue, mas sem os detalhes importantes de seu comportamento. A visão teórica será a representação formal da MEF do BGP à luz de uma modelagem aritmética apropriada, seguindo a sugestão de [6], página 443.

A descrição da MEF do BGP será um apanhado do que está descrito em alguns textos importantes. Stewart4, na página 31, item 2.1 tem uma descrição simples e didáticamente irrepreensível, como sempre. Ele avança, no item seguinte (2.2, página 33) para os tipos de mensagens do BGP. É imperdível, a leitura! White e outros5, na página 22 oferecem uma oportunidade de vislumbrar o MFE do BGP, em uma única figura, com tudo o que será descrito abaixo, sob a ótica prática (ou direta). Por fim, vale lembrar que a RFC42711 é, naturalmente, a referência definitiva e no item 8, página 37, ela lembra bem que a proposta é conceitual e não necessáriamente exige-se sua implementação ipsis literae. Mas, o autor não sabe informar se algum BGP (a.k.a., sua MEF) implementado em algum roteador disponível no mercado deixa de cumprir a especificação da RFC4271.

 

A MEF do BGP

 

A Figura 1, abaixo exibe uma representação da MEF do BGP. Na realidade, como veremos mais tarde esta MEF é um autômato finito representado por seis estados: Idle, Connect, Active, OpenSent, OpenConfirm e Established. O estado inicial do MEF é o Idle. Um estado muda para outro estado de acordo com a representação das setas (arcos ou arestas) identificadas por uma letra (de A a U), para facilitar o entendimento do MEF, na sequência.

 

Figura 1. Máquina de Estado Finito do BGP. Desenhado pelo autor com base no item 8.2.2 da RFC4271.

 

Existem 28 eventos que podem gerar transições na MEF do BGP, e eles estão enumeradas abaixo:

    1. ManualStart
    2. ManualStop
    3. AutomaticStart
    4. ManualStart_with_PassiveTcpEstablishmen
    5. AutomaticStart_with_PassiveTcpEstablishment
    6. AutomaticStart_with_DampPeerOscillations
    7. AutomaticStart_with_DampPeerOscillations_and_PassiveTcpEstablishment
    8. AutomaticStop
    9. ConnectRetryTimer_Expires
    10. HoldTimer_Expires
    11. KeepaliveTimer_Expires
    12. DelayOpenTimer_Expires
    13. IdleHoldTimer_Expires
    14. TcpConnection_Valid
    15. Tcp_CR_Acked
    16. Tcp_CR_Invalid
    17. TcpConnectionConfirmed
    18. TcpConnectionFails
    19. BGPOpen
    20. BGPOpen with DelayOpenTimer running
    21. BGPHeaderErr
    22. BGPOpenMsgErr
    23. OpenCollisionDump
    24. NotifMsgVerErr
    25. NotifMsg
    26. KeepAliveMsg
    27. UpdateMsg
    28. UpdateMsgErr

Alguns destes eventos são opcionais, mas é pouco provável que alguma implementação de BGP deixe algum de fora. A descrição detalhada destes eventos estão na RFC42711, item 8.1 na página 38. Muitos destes eventos precisam de parâmetros, denominados atributos de sessão associados a eles. Existem dois tipos de atributos, os obrigatórios (ou mandatórios) e os opcionais. Os obrigatórios são:

      1. State
      2. ConnectRetryCounter
      3. ConnectRetryTimer
      4. ConnectRetryTime
      5. HoldTimer
      6. HoldTime
      7. KeepaliveTimer
      8. KeepaliveTime
      9.  

        O atributo state indica o estado corrente da MEF do BGP e o atributo ConnectRetryCounter indica o número de vezes que um BGP tentou estabelecer uma sessão com seu empareado. O restantes dos atributos obrigatórios estão escritos no item 10 da RFC42711. Os atributos opcionais são, continuando a sequência acima:

      10. AcceptConnectionsUnconfiguredPeers
      11. AllowAutomaticStart
      12. AllowAutomaticStop
      13. CollisionDetectEstablishedState
      14. DampPeerOscillations
      15. DelayOpen
      16. DelayOpenTime
      17. DelayOpenTimer
      18. IdleHoldTime
      19. IdleHoldTimer
      20. PassiveTcpEstablishment
      21. SendNOTIFICATIONwithoutOPEN
      22. TrackTcpState

Os atributos opcionais e as relações com os eventos estão descritos no item 8.1.1 e 8.2.1.3 da RFC42711.

Um exemplo de como os atributos estão associados a eventos é o evento 9, ConnectRetryTimer_Expires. Este evento ocorrerá (ou será gerado), se o atributo obrigatório 3, ConnectRetruTimer expirar.

 

O comportamento da MEF do BGP

 

A transição entre cada estado da MEF mostrada na Figura 1 é uma combinação do evento e de atributos a ele associados. A RFC42711, no item 8.2.2 descreve com detalhes refinados como ocorre a transição entre cada estado da MEF. Não entraremos em detalhes sobre a transição, por limitação de espaço e de foco. Entretanto daremos uma ideia geral do mecanismo, mostrando a transição do estado Connect para o estado OpenConfirm, através de L, pois esta transição é uma novidade em relação às RFCs anteriores, do BGP.

Suponha que o estado da MEF seja Connect. Se uma mensagem OPEN é recebida enquanto o evento 20 (BGPOpen with DelayOpenTimer running) está ativo no sistema local (MEF que estamos analisando), então ocorrerá o seguinte:

      • Se o processo sobre o atributo ConnectRetryTimer está ativo, então ele é parado e o ConnectRetryTimer (c) é zerado;
      • Completa a inicialização do BGP;
      • Para e zera o atributo DelayOpenTimer (p);
      • Envia uma mensagem OPEN;
      • Envia uma mensagem KEEPALIVE;
      • Se o valor inicial do atributo HoldTimer (e) não é zero, então:
        • Inicia o valor do atributo KeepaliveTimer (g) com o valor inicial e,
        • Restabeleça o atributo HoldTimer para o valor negociado;
      • Entretanto, se o valor inicial do atributo HoldTimer (e) é zero, então:
        • Restabeleça o atributo KeepaliveTimer (g) e,
        • Restabeleça o atributo HoldTimer (e) para zero;
      • Mude o estado para OpenConfirm

Então podemos dizer que L (transição do estado Connect para o estado OpenConfirm) será ativada, quanto o evento 20c,e,g,p ocorrer (dependendo de condições dos atributos apresentados nos índices superiores). É uma representação abstrata, cuja principal finalidade é a de exibir a transição, o evento e os atributos diretamente envolvidos. A abstração remove detalhes relevantes que a RFC4271 esclarece apropriadamente, razão pela qual a ela se deve recorrer para o comportamento completo da transição. Assim pensando, a Tabela 1 mostra as 21 transições (representadas pelas letras maiúsculas na Figura 1), os eventos envolvidos em cada uma e os atributos associados.

Arco Transição Eventos e atributos envolvidos
A Idle=>Idle 6m, 7m, 13m
B Idle=>Active 4b,c, 5b,c
C Active=>Active 16c,n, 17c,n
D Active=>OpenConfirm 20c,e,g,p
E OpenConfirm=>Established 26e
F Established=>Established 26e, 27e
G Established=>Idle 2b,c, 8b,c,m, 9b,c,m, 10b,c,e,m, 12b,c,m, 13b,c,m, 18b,c, 19b,c,l,m, 20b,c,m, 21b,c,m, 22b,c,m, 23b,c,l,m, 24b,c, 25b,c, 28b,c,m
H Idle=>Connect 1b,c, 3b,c
I Connect=>Idle 2b,c, 8b,d,m,p, 10b,d,m,p, 11b,d,m,p, 13b,d,m,p,18c,p, 19b,d,m,p, 21c,m,t, 23b,d,m,p, 24d,m,p, 25b,d,m,p, 26b,d,m,p, 27b,d,m,p, 28b,d,m,p
J Connect=>Connect 9c,p, 16c,n,p, 17c,n,p
K Connect=>OpenSent 12e, 16c,e,n, 17c,e,n
L Connect=>OpenConfirm 20c,e,g,p
M Connect=>Active 18c,p
N Active=>Connect 9c
O Active=>OpenSent 12c,p, 16c,e,n, 17c,e,n
P OpenSent=>Active 18c
Q OpenSent=>OpenConfirm 19e,g,p
R OpenSent=>Idle 2c, 8b,c,m, 9b,c,m, 10b,e,m, 11b,c,m, 12b,c,m, 13b,c,m, 20b,c,m, 21b,c,m, 22b,c,m, 23b,c,m, 24c, 25b,c,m, 26b,c,m, 27b,c,m, 28b,c,m
S OpenConfirm=>OpenConfirm 11g
T OpenConfirm=>Idle 2b,c, 8b,c,m, 9b,c,m, 10b,c,m, 12b,c,m, 13b,c,m, 14b,c,m, 16b,c,m, 17b,c,m, 18b,c, 19b,c,m, 20b,c,m, 21b,c, 22b,c, 23b,c,m, 25b,c, 27b,c,m, 28b,c,m
U Active=>Idle 2b,c,p,t, 8b,c,m, 10b,c,m, 11b,c,m, 13b,c,m, 18b,c,m, 19b,c,m, 21b,c,m,t, 22b,c,m,t, 23b,c,m, 24b,c,m,p, 25b,c,m, 26b,c,m, 27b,c,m, 28b,c,m
Tabela 1. Transições do MEF do BGP, eventos e atributos envolvidos.

 

Observações complementares

 

As RFC62867 e RFC66082 aparecem em Referências, por serem atualizações da RFC42711, sem interesse direto, no presente texto, embora sejam importantes na implementação do BGP e de sua MEF.

 

Referências

 

    1. RFC4271, A Border Gateway Protocol 4 (BGP-4) Y. Rekhter, T. Li, S. Hares [ January 2006 ] (TXT = 222702) (Obsoletes RFC1771) (Updated-By RFC6286, RFC6608) (Status: DRAFT STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
    2. RFC6608, Subcodes for BGP Finite State Machine Error J. Dong, M. Chen, A. Suryanarayana [ May 2012 ] (TXT = 8612) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.
    3. Julião Braga. (2012). Objetos de Projeto Estendidos (OPE). Disponível em: https://juliaobraga.wordpress.com/2012/08/22/objetos-de-projeto-estendidos-ope/. Acessado em 26/08/2012.
    4. Stewart, J. W. III. BGP4: inter-domain routing in the Internet. Reading, Mass.: Addison Wesley, 1998.
    5. White, R., McPherson, D., Sangli, S. Practical BGP. Boston, MA: Pearson, 2005. 434 p.
    6. Gersting, J. L. Fundamentos Matemáticos para a Ciência da Computação: um tratamento moderno de matemática discreta. Tradução: Valéria de Magalhães Iorio. Rio de Janeiro: LTC, 2008. PLT 166, Anhanguera Educacional S. A. 5a. edição, 597 p.
    7. RFC6286, Autonomous-System-Wide Unique BGP Identifier for BGP-4 E. Chen, J. Yuan [ June 2011 ] (TXT = 7497) (Updates RFC4271) (Status: PROPOSED STANDARD) (Stream: IETF, Area: rtg, WG: idr). Acessado em 26/08/2012.

Soquetes: PHP, IPv6 e inseguridade

 

Introdução

 

Soquete é um recurso muito interessante e bastante usado pelos programadores mais experientes. Soquete é usado quando se deseja conexão entre equipamentos por diversas razões, como por exemplo, se a expectativa é o controle mais refinado da comunicação entre sistemas operacionais diferentes. Este texto mostra algumas preocupações a serem levadas em conta quando a linguagem é o PHP. Tais preocupações devem induzir ao leitor, no final, que a programação do soquete, em si é razoavelmente simples. Mas a programação da aplicação é difícil.

 

Soquetes e o conceito Cliente-Servidor

 

O modelo Cliente-Servidor é inerente ao uso de soquetes. Os diagramas que apresentam os soquetes sempre são formais. Um bom exemplo pode ser visto em [1], onde há uma abstração do relacionamento entre o Cliente e o Servidor usando soquetes. Um diagrama mais refinado é mostrado na figura abaixo.

 

 

Um exemplo de um servidor completo, que aceita telnet, pode ser visto no sítio do PHP, em [2]. Um texto muito interessante, completo e exaustivamente discutido, com exemplos na linguagem C está em [3].

Um problema que ocorreu no exemplo do sítio do PHP, [2], em IPv4, foi o aparecimento de alguns caracteres adicionais, nos 5 primeiros textos que o Cliente enviava para o Servidor. Não consegui resposta para o problema, mas algumas pessoas diziam que se referia ao protocolo do telnet. Mas não apresentavam solução. No primeiro texto do Cliente para o Servidor, este prefixava algo como ÿþÿþ ÿþÿþ’ÿü e, outros caracteres eram adicionados, diminuindo o tamanho, até o quinto texto. A partir do sexto texto, não aparecia mais. A solução encontrada, foi usar a função substr para obter o texto original com base no caracter 22. Tal posição foi encontrada via algumas tentativas/erro.

Em IPv6, este problema não ocorreu. O tratamento IPv6 no PHP (soquete) precisa ser explicitado, no primeiro parâmetro da função socket_create(AF_INET6, SOCK_STREAM, SOL_TCP). Para IPv4, retira-se o 6. Fora a indiossincrasia do IPv4, tudo funcionou conforme o figurino. No final fiquei imaginando se o amadurecimento no desenvolvimento do IPv6 e seus aplicativos (do sistema) refletia estabilidade maior do que o IPv4. Pura conjectura, claro.

Programar o soque é simples, portanto. Há muita ajuda na Internet e googladas procurando por PHP irão trazer resultados interessantes. Mas, programar a aplicação do soquete é uma tarefa difícil. Quem tiver IPv6, pode testar o protótipo, bastanto usar o comando abaixo:

telnet -6 peony.pegasus.com.br 10000

Só irá funcionar, em IPv6! Tudo o que for digitado, exceto os resultados dos comandos descritos na “ajuda”, retornam ao Cliente.

 

Qual a dificuldade no desenvolvimento de programas e/ou aplicações usando soquetes?

 

Muitas!! O exemplo, que pode ser visto pelo telnet acima, é muito simples porque lida com a necessidade de conhecimento da linguagem PHP e as funções disponíveis para os soquetes. É uma questão de treino. A resposta à entrada meu ip, por exemplo, depende de uma função especial, socket_getpeername. Fora as questões abstratas dos manuais deve-se aprender o local onde ela será colocada e de como pode-se evitar a sua execução repetitiva, já que o servidor de soquete sobrevive dentro de alguns do…while(true). No exemplo em pauta foi usado o artifício da numeração das linhas de entrada. A criatividade pode nos remeter a outras soluções.

Por outro lado, a linguagem de entrada é demasiadamente simples e se encaixa no mais baixo nível da hierarquia das linguagens: uma linguagem regular. Além disso, a aplicação do exemplo, isto é, o Servidor usa uma regra básica de somente executar o que reconhece previamente (já que são poucos e bem definidos comandos), repassando de volta ao Cliente a entrada que ela não consegue interpretar. Contudo, uma aplicação, via de regra, tende a complicar o meio de campo participando daquele conjunto indesejável, da indecidibilidade. Há uma linha de pesquisa muito interessante, denominada “A ciência da inseguridade”, nomeada pelo Len Sassaman (morto prematuramente aos 31 anos), Meredith L Patterson, Sergey Bratus e outros. Vale a pena um atento olhar no sítio desta turma, em [4], para garantir que nossas preocupações estejam sólidas em relação aos problemas que ocorrem quando se deseja programar de forma segura. Este mesmo grupo expõe uma questão bastante convincente: protocolos são tão complexos (aka, BGP), que verificar se diferentes implementações atendem às especificações originais é um problema indecidível.

Por fim, se o Servidor for mais complexo no sentido de precisar de reconhecer muitos comandos ou de uma linguagem mais complexa, algumas regras serão observadas, até por recomendação do pessoal do projeto LANGSEC, como por exemplo garantir que o “reconhecedor” da entrada seja gerado por uma gramática, preferencialmente regular ou no máximo, livre de contexto (visível na Hierarquia de Chomsky, mostrada na figura abaixo). Além de outras recomendações, evidentemente!

Classificação de gramáticas formais, segundo Chomsky.

 

Referências

 


1. Wikipedia. Berkeley sockets. Wikipedia. [Online] [Citado em: 02 de março de 2012.] http://en.wikipedia.org/wiki/Berkeley_sockets.
2. The PHP Group. Sockets. PHP. [Online] [Citado em: 1 de março de 2012.] http://www.php.net/manual/en/book.sockets.php.
3. Hacking, Jon Erickson. Hacking. [trad.] Marcelo Madeira e Henriqueta Grubba. 1. São Paulo : Digerati Books, 2009. ISBN 978-85-60480-30-2.
4. Sassaman, Len, Patterson, Meredith L. e Bratus, Sergey. LANGSEC: Language-theoretic Security. [Online] http://langsec.org.

%d blogueiros gostam disto: