D-Bus

Em computação, D-Bus ou DBus (acrônimo para Desktop Bus, em inglês, ou Barramento de área de trabalho, em português), um barramento de software, é um mecanismo de comunicação entre processos (CIP) e chamada de procedimento remoto que possibilita a comunicação entre vários programas de computador (isto é, processos) rodando simultaneamente na mesma máquina. O D-Bus foi desenvolvido como parte do projeto freedesktop.org, iniciado por Havoc Pennington da Red Hat para padronizar serviços fornecidos pelos ambientes de desktop do Linux como GNOME e KDE.

O projeto freedesktop.org também desenvolveu uma biblioteca de software livre e de código aberto chamada libdbus, como uma implementação de referência da especificação. Esta biblioteca é geralmente confundida com o próprio D-Bus. Outras implementações da biblioteca cliente do D-Bus também existem, como GDBus (GNOME), QtDBus (Qt/KDE), dbus-java e sd-bus (parte do systemd).

D-Bus é um mecanismo de comunicação entre processos inicialmente concebido para substituir os sistemas de comunicação de componentes de software usados pelos ambientes de desktop Linux GNOME e KDE (CORBA e DCOP, respectivamente). Os componentes desses ambientes de desktop são normalmente distribuídos em muitos processos, cada um fornecendo apenas alguns - normalmente um - serviços. Esses serviços podem ser usados por aplicativos clientes regulares ou por outros componentes do ambiente de desktop para executar suas tarefas.

Processos sem o D-Bus

Os mesmos processos com o D-Bus

Grandes grupos de processos cooperativos demandam uma densa malha de canais individuais de comunicação (usando métodos de comunicação entre processos um-para-um) entre eles. O D-Bus simplifica os requisitos de comunicação entre processos com um único canal compartilhado.

Devido ao grande número de processos envolvidos - incluindo processos que fornecem os serviços e os clientes acessando-os - o estabelecimento de comunicações CIP um-para-um entre todos torna-se uma abordagem ineficiente e pouco confiável. Em vez disso, o D-Bus fornece uma abstração de barramento de software que reúne todas as comunicações entre um grupo de processos em um único canal virtual compartilhado. [6] Processos conectados a um barramento não sabem como ele é implementado internamente, mas a especificação D-Bus garante que todos os processos conectados ao barramento possam se comunicar entre si através dele.

Os ambientes de desktop Linux aproveitam as facilidades do D-Bus instanciando não um barramento, mas muitos:

• um único barramento de sistema, disponível para todos os usuários e processos do sistema, que fornece acesso aos serviços do sistema (ou seja, serviços fornecidos pelo sistema operacional e também por quaisquer daemons do sistema)
• um barramento de sessão para cada sessão de login do usuário, que fornece serviços de área de trabalho para aplicativos do usuário na mesma sessão da área de trabalho e permite a integração da sessão da área de trabalho como um todo

Um processo pode se conectar a qualquer número de barramento, desde que tenha acesso a eles. Na prática, isso significa que qualquer processo do usuário pode se conectar ao barramento do sistema e ao seu barramento de sessão atual, mas não aos barramentos de sessão de outro usuário, ou mesmo a um barramento de sessão diferente pertencente ao mesmo usuário. A última restrição pode mudar no futuro se todas as sessões do usuário forem combinadas em um único barramento do usuário.

O D-Bus fornece recursos adicionais ou simplifica a funcionalidade existente para os aplicativos, incluindo compartilhamento de informações, modularidade e separação de privilégios. Por exemplo, informações sobre uma chamada de voz recebida via Bluetooth ou Skype podem ser propagadas e interpretadas por qualquer reprodutor de música atualmente em execução, que pode reagir alterando o volume ou pausando a reprodução até que a chamada seja finalizada.

O D-Bus também pode ser usado como uma estrutura para integrar diferentes componentes de um aplicativo de usuário. Por exemplo, um pacote de escritório pode se comunicar através do barramento de sessão para compartilhar dados entre um processador de texto e uma planilha.

Cada conexão a um barramento é identificada no D-Bus através de um nome de barramento.^[3]O nome de barramento consiste de duas ou mais strings separadas por ponto que podem conter letras, dígitos, traços e underscores - um nome de domínio reverso. Um exemplo de nome de barramento válido é org.freedesktop.NetworkManager.^[4]

Quando um processo se conecta a um barramento, o barramento dá para a conexão um nome de barramento especial chamado nome único de conexão (”unique connection name”, em inglês).^[4][5] Nomes de barramento desse tipo são imutáveis - é garantido que eles não mudarão enquanto a conexão existir - e, mais importante, eles não podem ser reutilizados enquanto o barramento estiver ativo.^[3][4][5] Isso significa que nenhuma outra conexão àquele barramento terá o mesmo nome único de conexão, mesmo que um mesmo processo feche a conexão ao barramento e a abra de novo. Nomes únicos de conexão são facilmente reconhecíveis porque eles iniciam com o caractere de dois-pontos :, cuja utilização é proibida em outras aplicações.^[5][4] Um exemplo de nome único de conexão é :1.1553 (os caracteres depois dos dois-pontos não possuem nenhum significado especial).^[5]

Um processo pode pedir mais nomes de barramento para sua conexão,^[5] desde que nenhum nome pedido já esteja sendo usado por outra conexão ao barramento. No linguajar de D-Bus, diz-se que quando um nome de barramento está sendo usado por uma conexão, essa conexão possui aquele nome.^[3][5] Neste sentido, nomes de barramento não podem ser possuídos por duas conexões ao mesmo tempo, mas, diferente dos nomes únicos de conexão, os nomes de barramento podem ser reutilizados se estiverem disponíveis: um processo pode possuir um nome de barramento que foi liberado - propositalmente ou não - por outro processo.^[3][4]

A ideia por trás destes nomes de barramento adicionais, comumente chamados de nomes bem-conhecidos (”well-known names”, em inglês), é fornecer outra forma de se referir a um serviço utilizando um nome de barramento definido previamente.^[4][5] Por exemplo, o serviço que reporta a data e hora atual no barramento de sistema existe em um processo cuja conexão possui o nome de barramento org.freedesktop.timedate1, independentemente de qual processo é.

Nomes de barramento podem ser usados como uma forma de implementar aplicações de instância singular (uma segunda instância da aplicação perceberia que o nome já está sendo utilizado).^[5] Também pode ser usado para monitorar o ciclo de vida de um processo, já que o barramento envia uma notificação quando o nome de barramento é liberado devido ao encerramento de um processo.^[6]

Por causa da sua concepção original como um substituto para diversos componentes orientados a sistemas de comunicação, o D-Bus compartilha com seus antecessores um modelo de objeto no qual se expressa a semântica das comunicações entre clientes e serviços. Os termos utilizados no modelo de objeto D-Bus imitam aqueles utilizados por algumas linguagens de programação orientadas a objetos. Isso não significa que o D-Bus é de alguma forma limitado a linguagens POO - na verdade, a implementação mais utilizada (libdbus) é escrita em C, uma linguagem de programação procedimental.

No D-Bus, um processo oferece seus serviços expondo objetos. Esses objetos tem métodos que podem ser invocados, e sinais que um objeto pode emitir.^[5] Métodos e sinais são coletivamente referidos como membros do objeto.^[3] Qualquer cliente conectado a um barramento pode interagir com um objeto utilizando seus métodos, fazendo pedidos ou comandando que o objeto faça ações.^[5] Por exemplo, um objeto representando um serviço de tempo pode ser solicitado por um cliente usando um método que retorna a data e hora atual. Um cliente também pode escutar sinais que um objeto emite quando seu estado muda devido a certos eventos, geralmente devido a um serviço relacionado. Um exemplo seria quando um serviço que administra dispositivos de hardware - como um USB - sinaliza um evento “um novo dispositivo de hardware foi adicionado”. Clientes devem instruir o barramento de que eles tem interesse em receber certos sinais de um objeto particular, já que o D-Bus só passa sinais aos processos que registraram um interesse neles.^[4]

Um processo conectado a um D-Bus pode requisitar que ele exporte quantos objetos D-Bus ele quiser. Cada objeto é identificado através de um caminho de objeto (”object path”, em inglês): uma string de números, letras e underscores separadas, prefixadas pelo caractere de barra. Ele é chamado de caminho devido a sua semelhança com o sistema de caminhos Unix.^[3][5] Um caminho de objeto é selecionado pelo processo que faz o requerimento, e deve ser único dentro do contexto daquela conexão de barramento. Um exemplo de caminho de objeto válido é /org/kde/kspread/sheets/3/cells/4/5.^[5] Não é obrigatório - mas também não é desencorajado - que sejam formadas hierarquias dentro dos caminhos de objeto.^[4] A convenção de nomeação de objetos de um serviço está completamente a critério dos desenvolvedores do serviço, mas muitos desenvolvedores escolhem utilizar um namespace com um nome de domínio reservado do projeto como prefixo (ex. /org/kde).^[5]

Cada objeto é indissociável à conexão de barramento onde ele foi exportado, e, do ponto de vista do D-Bus, só existe no contexto daquela conexão. Assim, para poder usar um determinado serviço, um cliente deve não só informar o caminho de objeto que fornece o serviço desejado, mas também o nome de barramento sob o qual o processo do serviço está conectado.^[3] Isso permite que vários processos conectados a barramentos possam exportar objetos diferentes com caminhos de objeto idênticos sem ambiguidades.

Uma interface especifica membros - métodos e sinais - que podem ser usados com um objeto.^[5] É um conjunto de declarações de métodos (incluindo parâmetros de passagem e de retorno) e sinais (incluindo seus parâmetros) identificados por um nome separado por pontos parecido com a anotação de interfaces da linguagem Java.^[4][5] Um exemplo de um nome de interface válido é org.freedesktop.Instrospectable.^[4] Mesmo com suas similaridades, nomes de interface e nomes de barramento não devem ser confundidos. Um objeto D-Bus pode implementar diversas interfaces, devendo implementar pelo menos uma, e deve dar suporte para cada método e sinal definido nela. A combinação de todas as interfaces implementadas por um objeto se chama tipo de objeto.^[3][5]

Quando um processo-cliente estiver usando um objeto, é uma boa prática fornecer o nome da interface do membro ao lado do nome do membro, mas isso só é obrigatório quando houver alguma ambiguidade causada por nomes de membros duplicados que estão disponíveis via diferentes interfaces implementadas por um objeto^[3][5] - desta forma, o membro selecionado seria indefinido ou errôneo. Um sinal emitido, diferente de um método, deve sempre indicar a qual interface ele pertence.

A especificação D-Bus também define diversas interfaces padrão que objetos podem querer implementar em conjunto com suas próprias interfaces.^[7] Enquanto isso é tecnicamente opcional, a maioria dos desenvolvedores do serviço D-Bus escolhem dar suporte a elas nos seus objetos exportados, já que elas fornecem recursos adicionais importantes aos clientes D-Bus, como a introspecção.^[4] Essas interfaces padrão são:^[4][7]

• org.freedesktop.DBus.Peer: inclui uma forma de testar se uma conexão D-Bus está ativa.^[4]
• org.freedesktop.DBus.Introspectable: inclui um mecanismo de introspecção através do qual um processo-cliente pode, durante o tempo que estiver ativo, receber uma descrição (em formato XML) das interfaces, métodos e sinais que um objeto implementa.^[5][7]
• org.freedesktop.DBus.Properties: permite que um objeto D-Bus exponha as propriedades e atributos fundamentais por trás do objeto, ou simulá-los caso estes não existam.^[7]
• org.freedesktop.DBus.ObjectManager: quando um serviço D-Bus organiza seus objetos hierarquicamente, essa interface fornece uma forma de interrogar um objeto sobre todos os sub-objetos no seu caminho, além de suas interfaces e propriedades, utilizando uma única chamada de método.^[7]

A especificação D-Bus também define um número de operações administrativas de barramento (chamados de “serviços de bus”) que podem ser performadas utilizando o objeto /org/freedesktop/DBus que está no nome de barramento org.freedesktop.DBus.^[7] Cada barramento reserva esse nome de barramento especial para si mesmo, e administra quaisquer requisições feitas especificamente para essa combinação de nome e caminho de objeto. As operações administrativas fornecidas pelo barramento são aquelas definidas pela interface de objeto org.freedesktop.DBus. Estas operações são usadas, por exemplo, para fornecer informações sobre o status do barramento,^[3] ou para administrar as requisições e liberações de nomes de barramento bem-conhecidos.^[4][7]

O D-Bus foi concebido para ser um sistema de comunicação genérico e de alto-nível entre processos. Para atingir estas metas, as comunicações D-Bus são baseadas na troca de mensagens entre processos ao invés de “bytes puros”.^[3][5] Mensagens D-Bus são itens discretos de alto-nível que um processo pode enviar através do barramento para outro processo conectado. As mensagens tem uma estrutura bem definida (até mesmo os tipos de dados enviados no payload são definidos), permitindo que o barramento valide ou rejeite quaisquer mensagens malformadas. Neste quesito, o D-Bus se parece mais com um mecanismo RPC do que um mecanismo IPC clássico, com seu próprio sistema de definição de tipos e o seu próprio marshalling.^[3]

O barramento suporta duas formas de mensagem entre um cliente e um processo de um serviço^[3]:

• Requisição-resposta um-pra-um: Essa é a forma que um cliente invoca um método do objeto. O cliente envia uma mensagem para o processo do serviço exportando o objeto, e em troca o serviço responde com a mensagem de volta para o processo cliente.^[5] A mensagem enviada pelo cliente deve conter o caminho do objeto, o nome do método sendo invocado (e opcionalmente, o nome da interface), e os valores dos parâmetros de input (se houverem) conforme definido pela interface selecionada do objeto. A mensagem de resposta inclui o resultado da requisição, incluindo os valores dos parâmetros de output retornados pela invocação do método do objeto, ou informação excepcional se houver um erro.^[3][5]
• Publicação-assinatura: Essa é a forma que um objeto anuncia a ocorrência de um sinal para os processos interessados. O processo do serviço do objeto envia uma mensagem via broadcast que o barramento passa somente para os clientes conectados que se inscreveram no sinal do objeto.^[5] A mensagem contém o caminho do objeto, o nome do sinal, a interface a qual o sinal pertence, e o valor dos parâmetros do sinal (se estes existirem). A comunicação é de mão-única: não há mensagens de resposta vindas dos clientes. O processo que enviou o sinal não sabe a quantidade de ouvintes ou suas identidades.^[3][5]

Cada mensagem consiste em um cabeçalho e um corpo.^[5] O cabeçalho é formado por diversos campos que identificam o tipo de mensagem, o remetente, e também informações necessárias para que a mensagem chegue a seus recipientes (nome do barramento de destino, caminho do objeto, nome do método ou sinal, nome da interface, etc.).^[5][7] O corpo da mensagem contém o payload que o processo recipiente interpreta - por exemplo, os argumentos de input e output. Todos os dados são codificados em um formato binário muito conhecido chamado de wire format que suporta a serialização de vários tipos, como de números inteiros, números de ponto flutuante, strings, etc.,^[7] também conhecido como marshalling.

A especificação D-Bus define o wire protocol como construir mensagens D-Bus para que sejam trocadas entre processos dentro de uma conexão D-Bus, contudo, ela não define o método de transporte por trás da entrega destas mensagens.

A maioria das implementações D-Bus segue a arquitetura da implementação de referência. Essa arquitetura consiste de dois componentes principais:^[3]

• uma biblioteca de comunicação ponto-a-ponto que implementa o wire protocol do D-Bus a fim de trocar mensagens entre dois processos. Na implementação de referência, essa biblioteca é a libdbus. Em outras implementações, alibdbus pode estar dentro de outra biblioteca de nível mais alto, ou pode ser completamente substituída por uma outra implementação que sirva o mesmo propósito.^[8] Essa biblioteca só suporta comunicação um-pra-um entre dois processos.^[5]
• um processo daemon especial que faz o papel do barramento e ao qual o resto dos processos se conecta, utilizando qualquer biblioteca de comunicação D-Bus ponto-a-ponto. Esse processo é também conhecido como daemon de barramento de mensagem,^[9] já que ele é responsável por rotear mensagens vindas de qualquer processo que esteja conectado em um barramento a outro. Na implementação de referência, esse papel é desempenhado pelo dbus-daemon, que por sua vez é feito em cima da biblioteca libdbus. Outra implementação do daemon de barramento de mensagem é o dbus-broker, que é feito em cima de sd-bus.

A biblioteca libdbus (ou equivalente) internamente utiliza um mecanismo IPC nativo de baixo-nível para transportar as mensagens D-Bus requeridas entre dois processos nas duas pontas da conexão D-Bus. A especificação D-Bus não possui uma definição mandatória de quais mecanismos de transporte IPC específicos devem estar disponíveis para uso, e fica a critério da biblioteca de comunicação definir quais métodos de transporte ela suporta. Por exemplo, em sistemas do tipo Unix, como o Linux libdbus, tipicamente se utiliza soquetes de domínio Unix por trás do método de transporte, mas também dá suporte a soquetes TCP.^[3][5]

As bibliotecas de comunicação de ambos processos deve concordar sobre o método de transporte escolhido e também qual canal de comunicação será particularmente usado para sua comunicação. Essa informação está definida dentro do que o D-Bus chama de endereço.^[4][5] Soquetes de domínio Unix são objetos do sistema de arquivos, e então podem ser identificado por um nome de arquivo, assim, um endereço válido seria unix:path=/tmp/.hiddensocket.^[3][7] Ambos processos devem passar o mesmo endereço para suas respectivas bibliotecas de comunicação para estabelecer a conexão D-Bus entre eles. Um endereço também pode fornecer dados adicionais para a biblioteca de comunicação no formato de pares chave=valor separados por vírgula.^[4][7] Dessa forma, por exemplo, pode-se fornecer informações de autenticação para um tipo específico de conexão que tenha suporte para tal.

Quando um daemon de barramento de mensagem como o dbus-daemon é usado para implementar um barramento D-Bus, todos os processos que queiram se conectar ao barramento devem saber o endereço do barramento, endereço no qual um processo pode estabelecer conexão ao barramento de processo de mensagens centrais do D-Bus.^[3][5] Neste cenário, o daemon de barramento de mensagem seleciona o endereço do barramento e o processo restante deve passar o valor para a sua libdbus ou biblioteca equivalente. O dbus-daemon define um endereço de barramento diferente para cada instância de barramento que ele fornece. Estes endereços estão definidos nos arquivos de configuração do daemon.

Dois processos podem utilizar uma conexão D-Bus para trocar mensagens diretamente entre si,^[10] mas essa não é a forma intencionada de uso do D-Bus. A forma padrão é sempre usar um daemon de barramento de mensagem (como o dbus-daemon) como um ponto central de comunicação ao qual cada processo deve estabelecer sua conexão D-Bus ponto-a-ponto. Quando um processo - cliente ou serviço - envia uma mensagem D-Bus, o processo de barramento de mensagem a recebe em primeira instância e a repassa para o recipiente apropriado. O daemon de barramento de mensagem pode ser visto como um roteador, encarregado de entregar cada mensagem ao seu destino repetindo ela através da conexão D-Bus até o processo recipiente.^[5] O processo recipiente é determinado pelo nome de barramento de destino no cabeçalho da mensagem,^[7] ou pelas informações de inscrição para sinais mantidas pelo daemon de barramento de mensagem no caso de mensagens de propagação de sinal.^[4] O daemon de barramento de mensagem também pode produzir suas próprias mensagens como resposta a certas condições, como mensagens de erro para um processo que envie uma mensagem com destino a um nome de barramento que não existe.^[5]

O dbus-daemon melhorou o conjunto de recursos já fornecidos pelo D-Bus com funcionalidades extras. Por exemplo, ativação de serviço permite inicialização de serviços automática quando necessário - quando a primeira solicitação de um nome de barramento de um serviço chega ao daemon de barramento de mensagem.^[3] Dessa forma, os processos dos serviços não precisam ser inicializados durante a inicialização do sistema ou durante o estágio de inicialização de usuários, assim, não consumem memória ou outros recursos enquanto não forem necessários. Este recurso foi originalmente implementado usando ajudantes do setuid,^[11] mas atualmente também pode ser fornecido pelo esquema de ativação de serviços do systemd. Ativação de serviços é um recurso importante que facilita a administração do ciclo de vida de processos de serviços (como exemplo, quando um componente desktop deve iniciar ou parar).^[5]

O D-Bus foi iniciado em 2002 por Havoc Pennington, Alex Larsson (Red Hat) e Anders Carlsson.^[12] A versão 1.0 - considerada API estável - foi lançada em Novembro de 2006.^[13][14]

Fortemente influenciado pelo sistema DCOP utilizado pelas versões 2 e 3 do KDE, o D-Bus substituiu o DCOP no lançamento do KDE 4.^[14][15] Uma implementação do D-Bus presta suporte principalmente a sistemas operacionais POSIX, e uma porta para Windows existe. É usado pelo Qt 4 e posteriormente pelo GNOME. No GNOME, ele gradualmente substituiu o mecanismo anterior Bonobo. Também é utilizado pelo Xfce.

Um de seus pioneiros foi o Hardware Abstraction Layer (atualmente depreciado). O HAL utilizava o D-Bus para exportar informações sobre hardware adicionado ou removido do computador.^[12]

A utilização do D-Bus tem crescido estavelmente além do escopo inicial de ambientes desktop para incluir uma quantidade cada vez maior de serviços do sistema. Por exemplo, o daemon de rede do NetworkManager, o Stack Bluetooth BlueZ e o servidor de áudio PulseAudio utilizam o D-Bus para fornecer (parcial ou completamente) seus serviços. O systemd utiliza o D-Bus wire protocol para comunicação entre o systemctl e o systemd, e também promove daemons tradicionais do sistema a serviços D-Bus, como o logind.^[16] Outro utilitário do D-bus é o Polkit, cujo daemon de autoridade de políticas é implementado como um serviço conectado ao barramento do sistema.^[17]

Referências