A falha da Internet em SP

O problema da Telefônica em SP revelou as falsas expectativas que as pessoas e empresas têm acerca da confiabilidade da Internet. Em particular, causou-me surpresa grandes entidades públicas não possuírem link secundário com Embratel, Intelig ou outra telecom diferente, ou mesmo alguma solução "caseira".

Antes de ir trabalhar no INdT, eu e o Toti instalávamos servidores Linux como meio de vida. Na época em que encerramos as atividades, acho que quase metade das solicitações de orçamento tinham relação com redundância de comunicação com filiais ou com a Internet. DSL com WiFi, DSL com link, duas DSLs de telecoms diferentes, e assim por diante. E eram empresas relativamente pequenas, de 50 ou 100 empregados, que estavam preocupadas com a confiabilidade da Internet.

É certo que muitos desses projetos de redundância tinham motivações extrinsecas à confiabilidade: o uso de canais mais baratos (DSL ao invés de link dedicado), a confiabiilidade baixa de redes WiFi em longa distância (que alguns clientes tinham armado para evitar os custos de um link ponto-a-ponto), o balanceamento de carga, e até a absurda estrutura de preços dos links (às vezes, dois links de capacidade X custavam muito menos que um link 2X).

Mas o fato é que tais arranjos traziam confiabilidade extra, e os e-mails automáticos nos revelavam que a redundância era freqüentemente posta à prova.

Eu mesmo não me sentiria confortável sem ter um plano B de conectividade. Caso a DSL falhe, tenho GPRS/EDGE ilimitado, e pretendo ter 3G assim que a antena local suportar. Ainda não precisei usar o plano B, mas de vez em quando eu testo.

Uns dias depois, nesta mesma semana, houve panes nos estados de PA e MA devido a uma escavadeira ter cortado fibras óticas. Uns tempos atrás, boa parte da Ásia ficou sem Internet porque um cabo submarino foi cortado. Faz mais tempo ainda, que o principal backbone da Internet, que corre ao redor de Washington e carrega 70% do tráfego da rede mundial, também sofreu pane e o mundo inteiro sofreu devido ao DNS. Já deveria estar patente que tais coisas acontecem, e muito.

Parece que a Telefônica vendeu serviço de conectividade com garantia "cinco noves", ou seja, com 99,999% de confiabilidade. Cometeu o mesmo erro dos clientes, com o agravante que sabe estar vendendo algo que não pode entregar; certamente vai pagar multas milionárias por conta disso.

Se as comunicações da Telefônica pararam por causa de dois roteadores que eram redundantes e pararam ao mesmo tempo, é preciso melhorar essa infra-estrutura, porque redundância em duplo não é suficiente. Aviões tem linhas hidráulicas triplas ou quádruplas (dependendo do modelo) e ainda assim já ocorreram casos de pane hidráulica total, a ponto dos projetistas modernos cogitarem adicionar vectored thrust para garantir alguma manobrabilidade em caso de pane total.

Outro agravante é o expertise interno em telefonia que deveria ter ensinado alguma coisa à rede de dados. A rede de telefonia garante tanto confiabilidade quanto performance, e não lembro de nenhum caso recente ou passado de pane na telefonia. É MUITO mais fácil e barato garantir confiabilidade no TCP/IP porque seu roteamento é muito mais poderoso que o do SS7, e uma diminuição na performance do TCP/IP é mais bem tolerada.

Estou curioso para ver como a TLPP4 abrirá no pregão de segunda-feira. Nesta sexta-feira, quem pagou o pato foi a Telemar/OI (TLNP4) com uma queda de quase 2%.

N810 é o que há

Tive a oportunidade de utilizar o N810 por alguns dias, deviido ao projeto em que estou trabalhnando. Depois de usar o N800 por bom tempo, posso dizer que o N810 é muito melhor. Se alguém pretende comprar um Tablet, recomendo fortemente o 810, pelos seguintes motivos:

1. Teclado. O mini teclado físico do 810 não é a oitava maravilha, mas é infinitamente melhor que teclado virtual. O grande problema do teclado virtual e que ocupa espaço precioso na tela. O reconhecimento de escrita tem o mesmo defeito. O N800 deveria ter seguido a filosofia Palm de deixar um espaço de tela sensível dedicada a reconhecimento de escrita. O teclado real mata essa discussão com tiro de canhão.

2. Acabamento. O aspecto externo é bem mais bonito e "liso". As teclas que já existiam no N800 estão em lugares mais lógicos, embora o controle de volume do 770 ainda era o melhor.

3. Memória flash interna. Como essa memória contém o swap, é muito interessante que ela tenha boa capacidade e não seja facilmente removível como é nos outros Tablets.

4. GPS embutido.

5. Vem com suporte para prender no automóvel.

6. A câmera continua sendo ruim mas está na fronte, não mais naquele pinguelo que salta para fora. Mais apropriado para o uso imaginado dela, que é videofone.

Desvantagens: não tem mais receptor FM, e o conector USB é micro ao invés do mini (menos padrão, por enquanto). O case rígido do 770 ainda era melhor que a capinha de couro. O carregador que veio na caixa ainda não é aquele bem pequeno do N95.

Palestra no evento SIRC da UNIFRA

Nesta última quarta-feira (11/6) proferi uma palestra na UNIFRA (Centro Universitário Franciscano), em Santa Maria/RS. O tema foi "Python para dispositivos móveis".

O objetivo foi instigar o pessoal a desenvolver em Python, seja no PC, seja para dispositivos móveis que serão (ou são) a próxima onda da informática. Foi uma versão modificada da palestra que fiz em Manaus em novembro do ano passado, mas com mais foco em Python e menos em outras alternativas como OpenC, Mamona etc.

Desenvolver para mobile é difícil, por diversos motivos. Como parte da argumentação em favor do Python, menciono em detalhes o tipo de problema que o desenvolvedor mobile típico (usando C ou C++) enfrenta no seu dia-a-dia.

Pena que meu tempo estava curto e não pude preparar uma palestra mais elaborada, talvez até aproximando-se de um mini-curso. Quem sabe na próxima. Mas diversos alunos presentes na palestra já tinham experimentado Python em dispositivos Nokia, seja nos celulares Série 60 ou nos Tablets, então ao menos eu tinha "testemunhas" que atestavam a veracidade do que estava falando...

A UNIFRA é uma universidade mantida pela Igreja Católica, mais especificamente pelas Irmãs Franciscanas. O prédio onde ocorreu o evento SIRC (Simpósio de Informática da Região Centro de RS) é extremamente bonito. As escadarias da entrada pareciam coisa de novela, e fiz papel de bobo tirando várias fotos delas (além do que a câmera do celular não é grande-angular, então as fotos não fazem justiça ao local).

Tanto professores como alunos pareceram extremamente preparados e interessados, não sei como não ouvi falar deles antes, ainda mais estando relativamente perto.

Na verdade, eu também não conhecia a cidade. Santa Maria fica exatamente no meio de RS, e ocupa uma posição estratégica, em diversos aspectos: ferroviário, militar (parece que há um contingente de 7000 militares), e educacional, com diversas universidades entre elas a UNIFRA e a UFSM. Santa Maria tem em torno de 300 mil habitantes, tamanho semelhante a Blumenau/SC ou Jundiaí/SP. Boa parte da população é de fora, que vem estudar, ou então por ser militar.

O professor Cassal foi meu "cicerone", e me assistiu de forma extremamente atenciosa tanto na logística da viagem como durante a estada na cidade. Meus agradecimentos a ele.

Um aspecto curioso do evento foi que ocorreu um "momento cultural" imediatamente antes da abertura. Três alunos dos cursos relacionados a informática armaram-se de arcordeon, violão e bateria, e tocaram diversas músicas, desde gauchescas até MPB, passando por "Asa Branca". E eles tocaram bem à beça. Coisas do Rio Grande do Sul.

Finalmente, para ir de Porto Alegre à Santa Maria, é preciso pegar um vôo num pequeno turbohélice de 20 lugares. A maioria das pessoas deve ter medo disso; eu particularmente adorei, fazia muito tempo que não voava em avião de hélice, e quanto menor e mais lento, mais um avião balança, tornando a viagem muito mais divertida. O aviãozinho Let-410 fabricado no antigo bloco comunista tem muito empuxo e parece ser feito para pistas muito mais curtas do que as existentes em aeroportos "normais".

Carteira de identidade de uma conexão

Cada conexão TCP/IP tem uma identificaação única na Internet. Esta id. é composta por quatro valores: os endereços IP das duas pontas, mais os números de porta que cada ponta atribuiu àquela conexão em particular.

Da minha experiência como professor, sei que o conceito de endereço é mais ou menos compreensível por todos, mas o conceito de porta fica no ar.

A porta é uma abstração criada pelo protocolo de transporte. O objetivo é permitir que um terminal possa manter diversas conexões abertas ao mesmo tempo, e mesmo várias conexões separadas entre os mesmos dois terminais. Sem a porta, seria necessário criar algum outro mecanismo que distinguisse os dados vindos de cada conexão.

Poddemos fazer uma analogia com os correios. Em geral, uma carta menciona o nome do destinatário, embora ele não seja necessário para a entrega da carta; bastaria o endereço. Mas aí, se mora mais de uma pessoa na casa, como saber para quem é a carta sem um nome? Seria necessário abrir a carta, e tentar inferir o destinatário pelo conteúdo.

A porta num pacote TCP ou UDP faz o mesmo papel do nome em uma carta. Mas a porta ainda tem uma utiilidade adicional na Internet, que é identificar os serviços. Por exemplo, um servidor Web sempre atende na porta 80. Isto facilita a vida dos clientes que não precisam descobrir a porta do serviço Web, basta saber o endereço.

Isto também significa que todas as conexões com este servidor Web terão metade de suas identidades sempre igual, já que endereço o porta do terminal servidor são sempre iguais. A distinção entre conexões fica totalmente dependente do endereço e porta do terminal cliente.

Bem, e qual vai ser o número de porta do lado cliente? Não importa, pois é do cliente a iniciativa de fazer a conexão, assim o servidor fica sabendo já no primeiro pacote qual é a porta do ooutro lado (para quem ele deverá mandar o pacotte de resposta).

Normalmente o cliente escolhe uma porta 'alta', ou seja, acima de 32000, que não costuma ser usada por servidores. O valor exato costuma ser escolhido pelo sistema operacional. Mas absolutamente nada impede que a própria aplicação cliente escolha sua porta, e pode escolher uma porta 'baixa', até mesmo a porta 80. Se não estiver em uso por outra conexão, nem houver um servidor Web rodando na mesma máquina, tá valendo.

A única exigência é o cliente escolher uma porta que ele mesmo já não esteja usando para outra conexão com o mesmo servidor.

Assim, não há nada esotérico a respeito das portas. É apenas um truque para que um terminal possa manter várias conexões abertas concomitantemente. E a convenção de o servidor atender sempre à mesma porta existe apenas para evitar a necessidade de fazer-se procura DNS também pela porta.

Aliás, o DNS suporta resolução de porta além de resolver eendereços. Alguns serviços como LDAP usam rotineiramente este método de resolução, pois não se sabe a priori nem o endereço nem a porta do servidoor LDAP responsável por um domínio.

Assim, ninguém precisa ficar assustado com a perspectiva futura dos serviços não terem mais portas fixas. O DNS dá jeito -- se estiver corretamente configurado...

Num próximo post, veremos como fica a identidade única das conexões na presença de um roteador NAT.

Comunicação "sem conexão" não existe

Uma coisa que é rotineiramente ensinada aos novatos em protocolos de rede, e escrita em praticamente todos os compêndios a respeito do assunto, é que TCP é um protocolo "com conexão" e UDP é um protocolo "sem conexão".

Num contexto maior, também ensinamos que antes da comunicação baseada em pacotes de dados (que hoje é prevalente), havia a comunicação baseada em circuitos, ou seja, linhas telefônicas (mediante discagem ou privativas). Também existe a tendência de dizer que linha telefônica é uma conexão, enquanto na comunicação por pacotes 'não há' conexão.

O primeiro exemplo didático que se costuma dar para comunicação por datagrama ("sem conexão"), é a carta enviada pelo correio, que não tem garantia de entrega, e o tempo de entrega é apenas melhor esforço (ou seja, depende do bom humor do Correio).

Agora, quem disse que não há conexão entre remetente e destinatário? É claro que há. A questão é que o Correio não toma conhecimento dela; apenas transmite cartas. E isto não é ruim; pelo contrário, é bom, pois eu posso mandar cartas para milhares de pessoas diferentes sem que eu precise dizer ao Correio porque estou fazendo isso.

O mesmo aplica-se a diferença entre linha telefônica (privada ou comutada) e pacotes de dados. Quando dois terminais comunicam-se usando pacotes de dados, é claro que existe uma conexão entre esses dois terminais. De outro modo, por que eles estariam trocando dados, se não houvesse interesse mútuo nisso?

A diferença é que, numa ligação telefônica, a companhia telefônica "sabe" que essa conexão existe, e é diretamente responsável por ela. Além disso, cada conexão serve apenas para uma dupla (ou tupla) de terminais. Se João precisa falar com Maria e também com José, precisa estabelecer duas conexões separadas. Mesmo que ele use cada uma delas 50% do tempo, ele paga por minuto, pelas duas ligações.

Já num serviço de pacotes de dados, a infra-estrutura é análoga à do Correio: ela só promete entregar pacotes ao destino, sem confirmação, na base do melhor esforço. O serviço de dados não quer nem saber se dois terminais vão trocar 1 ou 1 milhão de pacotes entre si. A responsabilidade de criar e manter as conexões é do terminal, não do serviço. Isto sobrecarrega o terminal. Por outro lado, a maioria dos serviços de dados custa o mesmo, esteja você comunicando com 1, 10 ou 1000 interlocutores diferentes.

No caso dos protocolos TCP/IP, a responsabilidade de manter a conexão é sempre do terminal. Resta saber que parte do software que roda no terminal (sistema operacional ou aplicação) vai tomar conta disso.

No caso do TCP, o sistema operacional é o responsável por manter a conexão entre os terminais. Isto facilita a vida da aplicação. Por exemplo, quem desenvolve um browser não precisa tratar coisas como perdas de pacotes e retransmissões. Isto é muito conveniente, evita muita duplicação de código, e o protocolo TCP é utilizado sempre que possível.

Já o protocolo UDP transfere a responsabilidade da conexão para a aplicação. Isto torna o desenvolvimento da mesma bem mais complicado, e bem mais difícil de "fazer direito". Por outro lado, há situações em que isto é necessário e conveniente.

Por exemplo, quando um serviço atende milhões de clientes num curto espaço de tempo, trocando mensagens curtas, UDP é muito melhor que TCP, pois em geral os sistemas operacionais têm limites no número de conexões TCP, enquanto uma aplicação pode usar memória virtual e controlar milhões de conexões UDP sem maiores problemas. É por isso que serviços como DNS utilizam UDP.

Outro motivo para usar UDP é delegar o controle de congestionamento à aplicação. TCP faz controle de congestionamento, mas o faz de um jeito que é inadequado para serviços como multimídia e voz sobre IP. UDP permite delegar tal controle à aplicação.

O último motivo para utilizar-se UDP em vez de TCP é o uso de multicast/broadcast. Analogamente a uma ligação telefônica, TCP "custa" muito para conectar com diversos clientes ao mesmo tempo. E quando o serviço manda dados majoritariamente numa única direção, é mais econômico utilizar broadcast e multicast, pois permite atingir inúmeros destinatários, custando uma única transmissão ao remetente.

Existem tentativas de adicionar-se suporte a multicast a protocolos confirmados, caso do XTP. Mas está longe de ser algo largamente adotado.

Mas o fato é que é errado rotular UDP de um serviço "sem conexão". A conexão sempre existe; a questão é quem toma conta dela.

De modo geral, quanto mais empurra-se a responsabilidade da conexão para a aplicação que roda no computador do usuário final, mais barato é o serviço, menor é sua confiabilidade, e mais flexível é o seu uso.

Assim, temos os serviços a seguir numa ordem decrescente de responsabilidade pela conexão:

* broadcasting (TV ou rádio);

* linha privada implantada pelo próprio usuário (raro);

* linha privada da telecom;

* linha discada ou ISDN da telecom;

* X.25 da Embratel;

* Internet, TCP;

* Internet, UDP.

A tendência geral é a migração de todo e qualquer serviço de dados para a Internet. Apesar da confiabilidade menor que as outras alternativas, é a mais flexível. E o contínuo investimento na Internet, tanto na melhoria do serviço em si quanto nos algoritmos que rodam nos terminais têm aproximado a qualidade de serviço das demais opções. Há uns oito ou nove anos atrás, VoIP era uma mera curiosidade, um brinquedo. Hoje em dia, todo mundo usa, até mesmo as telecoms.

Esta transferência de responsabilidade da conexão para o usuário do serviço é maravilhosa, pois é a liberdade de expressão ao extremo. Basta ter uma ADSL, e você pode comunicar-se com o mundo todo, em qualquer protocolo, sendo cliente ou servidor de qualquer serviço de dados. Talvez haja telecoms que registrem suas conexões TCP e UDP para fins forenses, mas isso tem antídoto fácil e rápido: criptografia e/ou protocolos exóticos. O gênio está fora da garrafa.

Por outro lado é algo assustador, pois existem inúmeros mecanismos sociais que perdem parte considerável da sua força num mundo assim. Quantos políticos já não foram "enquadrados" por conta das suas ligações telefônicas? E se eles estivessem usando VoIP? É bem verdade que provavelmente todos os serviços VoIP mantém registros das ligações, porém a tendência a longo prazo é o VoIP independer de serviços centrais (embora requisitar uma informação destas para a Skype que é sediada em Luxemburgo deva ser uma epopéia judiciária).

Skype funciona bem, mas no fundo é um subproduto dos roteadores NAT e da necessidade de conectar-se a telefones convencionais (SkypeOut). Num mundo ideal futuro, ("imagine all the people...") vamos usar IPv6 e usaremos telefones SIP que discam diretamente uns para os outros, sem necessidade de serviços intermediários.

Naturalmente, as autoridades policiais perdem uma ferramenta mas têm ganhado outra, que é o uso cada vez mais raro do dinheiro vivo em favor das operações on-line. Até alguém inventar o e-money. Na verdade o que falta ao e-money é disseminar seu uso, porque ele está inventado.