D-Bus - D-Bus
| Desenvolvedor (s) | chapéu vermelho |
|---|---|
| lançamento inicial | Novembro de 2006 |
| Versão estável | 1.12.20 / 2 de julho de 2020
|
| Versão de visualização | 13.1.18 / 2 de julho de 2020
|
| Repositório |
|
| Escrito em | C |
| Sistema operacional | Plataforma cruzada |
| Modelo | |
| Licença | GPLv2 + ou AFL 2.1 |
| Local na rede Internet | www |
Na computação , o D-Bus (abreviação de " Desktop Bus ") é um mecanismo de middleware orientado a mensagens que permite a comunicação entre vários processos executados 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 por ambientes de desktop 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 não deve ser confundida com o próprio D-Bus, pois outras implementações da especificação D-Bus também existem, como GDBus (GNOME), QtDBus ( Qt / KDE), dbus-java e sd-bus (parte do systemd ) .
Visão geral
D-Bus é um mecanismo de comunicação entre processos (IPC) inicialmente projetado para substituir os sistemas de comunicação de componentes de software usados pelos ambientes de desktop GNOME e KDE Linux ( 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.
Devido ao grande número de processos envolvidos —adicionar processos que fornecem os serviços e clientes que os acessam— estabelecer comunicações IPC um-para-um entre todos eles 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. Os processos conectados a um barramento não sabem como isso é implementado internamente, mas a especificação D-Bus garante que todos os processos conectados ao barramento possam se comunicar entre si por meio dele.
Os ambientes de desktop Linux tiram proveito dos recursos do D-Bus instanciando vários barramentos, notavelmente:
- 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 desktop para aplicativos de usuário na mesma sessão de desktop e permite a integração da sessão de desktop como um todo
Um processo pode se conectar a qualquer número de barramentos, 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 de usuário forem combinadas em um único barramento de usuário.
O D-Bus fornece funcionalidades adicionais ou simplifica os aplicativos existentes, incluindo compartilhamento de informações, modularidade e separação de privilégios . Por exemplo, as informações sobre uma chamada de voz recebida por Bluetooth ou Skype podem ser propagadas e interpretadas por qualquer reprodutor de música em execução, que pode reagir silenciando o volume ou pausando a reprodução até que a chamada seja concluída.
O D-Bus também pode ser usado como uma estrutura para integrar diferentes componentes de um aplicativo de usuário. Por exemplo, uma suíte de escritório pode se comunicar por meio do barramento de sessão para compartilhar dados entre um processador de texto e uma planilha .
Especificação D-Bus
Modelo de ônibus
Cada conexão a um barramento é identificada no contexto do D-Bus pelo que é chamado de nome de barramento . Um nome de barramento consiste em duas ou mais strings separadas por pontos de letras, dígitos, travessões e sublinhados. Um exemplo de um nome de barramento válido é org.freedesktop.NetworkManager.
Quando um processo estabelece uma conexão com um barramento, o barramento atribui à conexão um nome de barramento especial denominado nome de conexão exclusivo . Os 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 durante a vida útil do barramento. Isso significa que nenhuma outra conexão com aquele barramento terá atribuído esse nome de conexão exclusivo, mesmo se o mesmo processo encerrar a conexão com o barramento e criar uma nova. Os nomes de conexão exclusivos são facilmente reconhecíveis porque começam com o caractere de dois-pontos - proibido de outra forma. Um exemplo de um nome de conexão exclusivo é :1.1553(os caracteres após os dois pontos não têm nenhum significado particular).
Um processo pode solicitar nomes de barramento adicionais para sua conexão, desde que qualquer nome solicitado já não esteja sendo usado por outra conexão com o barramento. No jargão do D-Bus, quando um nome de barramento é atribuído a uma conexão, diz-se que a conexão possui o nome do barramento. Nesse sentido, um nome de barramento não pode pertencer a duas conexões ao mesmo tempo, mas, ao contrário de nomes de conexão exclusivos, esses nomes podem ser reutilizados se estiverem disponíveis: um processo pode reivindicar um nome de barramento liberado — propositalmente ou não— por outro processo.
A ideia por trás desses nomes de barramento adicionais, comumente chamados de nomes bem conhecidos , é fornecer uma maneira de se referir a um serviço usando um nome de barramento pré-arranjado. Por exemplo, o serviço que relata a hora e a data atuais no barramento do sistema está no processo cuja conexão possui o nome do barramento org.freedesktop.timedate1 , independentemente de qual processo seja.
Os nomes de barramento podem ser usados como uma maneira simples de implementar aplicativos de instância única (as segundas instâncias detectam que o nome do barramento já está em uso). Ele também pode ser usado para rastrear o ciclo de vida de um processo de serviço, uma vez que o barramento envia uma notificação quando um nome de barramento é liberado devido ao encerramento de um processo.
Modelo de objeto
Por causa de sua concepção original como um substituto para vários sistemas de comunicação orientados a componentes, o D-Bus compartilha com seus predecessores um modelo de objeto no qual expressa a semântica das comunicações entre clientes e serviços. Os termos usados no modelo de objeto D-Bus imitam aqueles usados por algumas linguagens de programação orientadas a objetos . Isso não significa que o D-Bus esteja de alguma forma limitado às linguagens OOP - na verdade, a implementação mais usada ( libdbus ) é escrita em C , uma linguagem de programação procedural .
No D-Bus, um processo oferece seus serviços expondo objetos . Esses objetos têm métodos que podem ser invocados e sinais que o objeto pode emitir. Métodos e sinais são chamados coletivamente de membros do objeto. Qualquer cliente conectado ao barramento pode interagir com um objeto usando seus métodos, fazendo solicitações ou comandando o objeto a realizar ações. Por exemplo, um objeto que representa um serviço de horário pode ser consultado por um cliente usando um método que retorna a data e a hora atuais. Um cliente também pode ouvir os sinais que um objeto emite quando seu estado muda devido a certos eventos, geralmente relacionados ao serviço subjacente. Um exemplo seria quando um serviço que gerencia dispositivos de hardware - como USB ou drivers de rede - sinaliza um evento de "novo dispositivo de hardware adicionado". Os clientes devem instruir o barramento de que estão interessados em receber certos sinais de um determinado objeto, uma vez que um barramento D-Bus apenas passa sinais para os processos com interesse registrado neles.
Um processo conectado a um barramento D-Bus pode solicitar que exporte quantos objetos D-Bus desejar. Cada objeto é identificado por um caminho de objeto , uma string de números, letras e sublinhados separados e prefixados por uma barra, chamada assim por causa de sua semelhança com os caminhos do sistema de arquivos Unix . O caminho do objeto é selecionado pelo processo de solicitação e deve ser exclusivo no contexto dessa conexão de barramento. Um exemplo de caminho de objeto válido é /org/kde/kspread/sheets/3/cells/4/5. No entanto, não é obrigatório - mas também não é desencorajado - para formar hierarquias dentro de caminhos de objeto. A convenção de nomenclatura particular para os objetos de um serviço é inteiramente de responsabilidade dos desenvolvedores de tal serviço, mas muitos desenvolvedores optam por namespace- los usando o nome de domínio reservado do projeto como um prefixo (por exemplo, / org / kde ).
Cada objeto está inextricavelmente associado à conexão de barramento particular para onde foi exportado e, do ponto de vista do D-Bus, só vive no contexto de tal conexão. Portanto, para poder usar um determinado serviço, o cliente deve indicar não apenas o caminho do objeto que fornece o serviço desejado, mas também o nome do barramento sob o qual o processo do serviço está conectado ao barramento. Isso, por sua vez, permite que vários processos conectados ao barramento possam exportar diferentes objetos com caminhos de objeto idênticos de forma inequívoca.
Membros —métodos e sinais— que podem ser usados com um objeto são especificados por uma interface . Uma interface é um conjunto de declarações de métodos (incluindo sua passagem e retorno de parâmetros) e sinais (incluindo seus parâmetros) identificados por um nome separado por ponto semelhante à notação de interfaces da linguagem Java . Um exemplo de um nome de interface válido é org.freedesktop.Introspectable. Apesar de sua semelhança, os nomes das interfaces e dos bus não devem ser confundidos. Um objeto D-Bus pode implementar várias interfaces, mas pelo menos deve implementar uma, fornecendo suporte para todos os métodos e sinais definidos por ele. A combinação de todas as interfaces implementadas por um objeto é chamada de tipo de objeto .
Ao usar um objeto, é uma boa prática para o processo do cliente fornecer o nome da interface do membro além do nome do membro, mas só é obrigatório quando há uma ambigüidade causada por nomes de membros duplicados disponíveis em diferentes interfaces implementadas pelo objeto - caso contrário, o o membro selecionado é indefinido ou errôneo. Um sinal emitido, por outro lado, deve sempre indicar a qual interface pertence.
A especificação D-Bus também define várias interfaces padrão que os objetos podem querer implementar, além de suas próprias interfaces. Embora seja tecnicamente opcional, a maioria dos desenvolvedores de serviço D-Bus opta por suportá-los em seus objetos exportados, pois eles oferecem recursos adicionais importantes para clientes D-Bus, como introspecção . Essas interfaces padrão são:
- org.freedesktop.DBus.Peer : fornece uma maneira de testar se uma conexão D-Bus está ativa.
- org.freedesktop.DBus.Introspectable : fornece um mecanismo de introspecção através do qual um processo cliente pode, em tempo de execução, obter uma descrição (em formato XML ) das interfaces, métodos e sinais que o objeto implementa.
- org.freedesktop.DBus.Properties : permite que um objeto D-Bus exponha as propriedades ou atributos do objeto nativo subjacente ou simule-os se não existir.
- org.freedesktop.DBus.ObjectManager : quando um serviço D-Bus organiza seus objetos hierarquicamente, esta interface fornece uma maneira de consultar um objeto sobre todos os subobjetos em seu caminho, bem como suas interfaces e propriedades, usando uma única chamada de método .
A especificação D-Bus define várias operações de barramento administrativo (chamadas "serviços de barramento") a serem realizadas usando o objeto / org / freedesktop / DBus que reside no nome de barramento org.freedesktop.DBus . Cada barramento reserva esse nome de barramento especial para si mesmo e gerencia todas as solicitações feitas especificamente para essa combinação de nome de barramento e caminho de objeto. As operações administrativas fornecidas pelo barramento são aquelas definidas pela interface org.freedesktop.DBus do objeto . Essas operações são usadas, por exemplo, para fornecer informações sobre o status do barramento ou para gerenciar a solicitação e liberação de nomes de barramentos conhecidos adicionais .
Modelo de comunicação
O D-Bus foi concebido como um sistema de comunicação entre processos genérico e de alto nível. Para atingir tais objetivos, as comunicações D-Bus são baseadas na troca de mensagens entre processos em vez de "bytes brutos". As 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 têm uma estrutura bem definida (até os tipos de dados transportados em sua carga útil são definidos), permitindo que o barramento as valide e rejeite qualquer mensagem malformada. Nesse sentido, o D-Bus está mais próximo de um mecanismo RPC do que de um mecanismo IPC clássico, com seu próprio sistema de definição de tipo e seu próprio empacotamento .
O barramento suporta dois modos de troca de mensagens entre um cliente e um processo de serviço:
- Pedido-resposta um para um : Esta é a maneira de um cliente invocar o método de um objeto. O cliente envia uma mensagem ao processo de serviço exportando o objeto e o serviço, por sua vez, responde com uma mensagem de volta ao processo cliente. A mensagem enviada pelo cliente deve conter o caminho do objeto, o nome do método invocado (e opcionalmente o nome de sua interface) e os valores dos parâmetros de entrada (se houver) conforme definido pela interface selecionada do objeto. A mensagem de resposta carrega o resultado da solicitação, incluindo os valores dos parâmetros de saída retornados pela invocação do método do objeto ou informações de exceção se houver um erro.
- Publicar / assinar : É a forma de um objeto anunciar a ocorrência de um sinal às partes interessadas. O processo de serviço do objeto transmite uma mensagem que o barramento passa apenas para os clientes conectados que assinaram o sinal do objeto. A mensagem carrega o caminho do objeto, o nome do sinal, a interface à qual o sinal pertence e também os valores dos parâmetros do sinal (se houver). A comunicação é unilateral: não há mensagens de resposta à mensagem original de nenhum processo do cliente, pois o remetente não conhece as identidades nem o número dos destinatários.
Cada mensagem D-Bus consiste em um cabeçalho e um corpo. O cabeçalho é formado por diversos campos que identificam o tipo de mensagem, o remetente, bem como as informações necessárias para entregar a mensagem ao destinatário (nome do barramento de destino, caminho do objeto, nome do método ou sinal, nome da interface, etc.). O corpo contém a carga útil de dados que o processo receptor interpreta - por exemplo, os argumentos de entrada ou saída. Todos os dados são codificados em um formato binário bem conhecido chamado formato wire, que suporta a serialização de vários tipos, como números inteiros e de ponto flutuante, strings, tipos compostos e assim por diante, também conhecido como empacotamento .
A especificação D-Bus define o protocolo de conexão : como construir as mensagens D-Bus a serem trocadas entre os processos dentro de uma conexão D-Bus. No entanto, ele não define o método de transporte subjacente para entregar essas mensagens.
Internos
A maioria das implementações de D-Bus existentes segue a arquitetura da implementação de referência. Esta arquitetura consiste em dois componentes principais:
- uma biblioteca de comunicações ponto a ponto que implementa o protocolo de conexão D-Bus para trocar mensagens entre dois processos. Na implementação de referência, essa biblioteca é libdbus . Em outras implementações, o libdbus pode ser encapsulado por outra biblioteca de nível superior, ligação de linguagem ou totalmente substituído por uma implementação independente diferente que serve ao mesmo propósito. Esta biblioteca suporta apenas comunicações um-para-um entre dois processos.
-
um processo daemon especial que desempenha a função de barramento e ao qual o restante dos processos se conecta usando qualquer biblioteca de comunicações ponto a ponto D-Bus. Este processo também é conhecido como daemon do barramento de mensagens , pois é responsável por rotear mensagens de qualquer processo conectado ao barramento para outro. Na implementação de referência, essa função é desempenhada pelo dbus-daemon , que por sua vez é construído em cima do libdbus . Outra implementação do daemon de barramento de mensagem é o dbus-broker , que é construído sobre o barramento SD .
A biblioteca libdbus (ou seu equivalente) usa internamente um mecanismo IPC nativo de nível inferior para transportar as mensagens D-Bus necessárias entre os dois processos em ambas as extremidades da conexão D-Bus. A especificação D-Bus não determina quais mecanismos de transporte IPC específicos devem estar disponíveis para uso, pois é a biblioteca de comunicações que decide quais métodos de transporte ela suporta. Por exemplo, em sistemas operacionais semelhantes ao Unix, como o Linux, o libdbus normalmente usa soquetes de domínio Unix como o método de transporte subjacente, mas também suporta soquetes TCP .
As bibliotecas de comunicação de ambos os processos devem concordar sobre o método de transporte selecionado e também sobre o canal particular usado para sua comunicação. Esta informação é definida pelo que o D-Bus chama de endereço . Os soquetes de domínio Unix são objetos do sistema de arquivos e, portanto, podem ser identificados por um nome de arquivo, portanto, um endereço válido seria unix:path=/tmp/.hiddensocket. Ambos os 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ções na forma de key=valuepares separados por vírgulas . Dessa forma, por exemplo, ele pode fornecer informações de autenticação para um tipo específico de conexão que o suporta.
Quando um daemon de barramento de mensagem como dbus-daemon é usado para implementar um barramento D-Bus, todos os processos que desejam se conectar ao barramento devem saber o endereço do barramento , o endereço pelo qual um processo pode estabelecer uma conexão D-Bus à central processo de barramento de mensagem. Neste cenário, o daemon de barramento de mensagem seleciona o endereço de barramento e os processos restantes devem passar esse valor para seu libdbus correspondente ou bibliotecas equivalentes. dbus-daemon define um endereço de barramento diferente para cada instância de barramento que ele fornece. Esses endereços são definidos nos arquivos de configuração do daemon.
Dois processos podem usar uma conexão D-Bus para trocar mensagens diretamente entre eles, mas esta não é a maneira pela qual o D-Bus normalmente deve ser usado. A maneira usual é sempre usar um daemon de barramento de mensagem (ou seja, dbus-daemon ) como um ponto central de comunicação para o 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 na primeira instância e a entrega ao destinatário apropriado. O daemon de barramento de mensagem pode ser visto como um hub ou roteador encarregado de levar cada mensagem ao seu destino, repetindo-a por meio da conexão D-Bus ao processo do destinatário. O processo do destinatário é determinado pelo nome do barramento de destino no campo de cabeçalho da mensagem ou pelas informações de assinatura dos sinais mantidos pelo daemon do barramento de mensagem no caso de mensagens de propagação de sinal. O daemon de barramento de mensagem também pode produzir suas próprias mensagens como uma resposta a certas condições, como uma mensagem de erro para um processo que enviou uma mensagem para um nome de barramento inexistente.
dbus-daemon melhora o conjunto de recursos já fornecido pelo próprio D-Bus com funcionalidade adicional. Por exemplo, a ativação do serviço permite o início automático de serviços quando necessário - quando a primeira solicitação para qualquer nome de barramento de tal serviço chega ao daemon de barramento de mensagem. Dessa forma, os processos de serviço não precisam ser iniciados durante a inicialização do sistema ou do usuário, nem precisam consumir memória ou outros recursos quando não estão sendo usados. Este recurso foi originalmente implementado usando ajudantes setuid , mas hoje em dia também pode ser fornecido pela estrutura de ativação de serviço do systemd . A ativação do serviço é um recurso importante que facilita o gerenciamento do ciclo de vida do processo de serviços (por exemplo, quando um componente de desktop deve iniciar ou parar).
História e adoção
O D-Bus foi iniciado em 2002 por Havoc Pennington, Alex Larsson ( Red Hat ) e Anders Carlsson. A versão 1.0 —considerada API estável— foi lançada em novembro de 2006.
Fortemente influenciado pelo sistema DCOP usado pelas versões 2 e 3 do KDE , o D-Bus substituiu o DCOP no lançamento do KDE 4 . Uma implementação de D-Bus oferece suporte à maioria dos sistemas operacionais POSIX e existe uma porta para Windows . É usado pelo Qt 4 e posterior pelo GNOME . No GNOME, ele substituiu gradualmente a maioria das partes do mecanismo Bonobo anterior . Ele também é usado pelo Xfce .
Um dos primeiros a adotar foi a (hoje obsoleta) Camada de Abstração de Hardware . A HAL usou o D-Bus para exportar informações sobre o hardware que foi adicionado ou removido do computador.
O uso do D-Bus está se expandindo continuamente além do escopo inicial de ambientes de desktop para cobrir uma quantidade cada vez maior de serviços de sistema. Por exemplo, o daemon de rede NetworkManager , a pilha bluetooth BlueZ e o servidor de som PulseAudio usam o D-Bus para fornecer parte ou todos os seus serviços. systemd usa o protocolo com fio D-Bus para comunicação entre systemctl e systemd, e também está promovendo daemons de sistema tradicionais para serviços D-Bus, como logind . Outro usuário pesado do D-Bus é o Polkit , cujo daemon de autoridade de política é implementado como um serviço conectado ao barramento do sistema.
Ele também é usado como o protocolo de fio para o protocolo AllJoyn para automação residencial , para este fim AllJoyn adiciona descoberta, gerenciamento de sessão, segurança, compressão de cabeçalho, suporte a dispositivo embutido e torna-o agnóstico de transporte.
Implementações
libdbus
Embora existam várias implementações do D-Bus, a mais amplamente usada é a implementação de referência libdbus , desenvolvida pelo mesmo projeto freedesktop.org que projetou a especificação. No entanto, libdbus é uma implementação de baixo nível que nunca foi feita para ser usada diretamente por desenvolvedores de aplicativos, mas como um guia de referência para outras reimplementações do D-Bus (como aquelas incluídas em bibliotecas padrão de ambientes de desktop ou em ligações de linguagem de programação ) O próprio projeto freedesktop.org recomenda que os autores de aplicativos "usem uma das ligações ou implementações de nível superior". A predominância de libdbus como a implementação D-Bus mais usada fez com que os termos "D-Bus" e "libdbus" fossem usados alternadamente, levando a confusão.
GDBus
GDBus é uma implementação de D-Bus baseada em streams GIO incluídos no GLib , com o objetivo de ser usado por GTK + e GNOME . GDBus não é um wrapper de libdbus, mas uma reimplementação completa e independente da especificação e protocolo D-Bus. MATE Desktop e Xfce (versão 4.14), que também são baseados em GTK + 3, também usam GDBus.
QtDBus
QtDBus é uma implementação do D-Bus incluída na biblioteca Qt desde sua versão 4.2. Este componente é usado por aplicativos, bibliotecas e componentes do KDE para acessar os serviços D-Bus disponíveis em um sistema.
sd-bus
Em 2013, o projeto systemd reescreveu o libdbus em um esforço para simplificar o código, mas também resultou em um aumento significativo do desempenho geral do D-Bus. Em benchmarks preliminares, a BMW descobriu que a biblioteca D-Bus do systemd aumentou o desempenho em 360%. Na versão 221 do systemd , a API sd-bus foi declarada estável.
libnih-dbus
O projeto libnih fornece uma "biblioteca padrão" leve de suporte C para D-Bus. Além disso, tem um bom suporte para compilação cruzada.
kdbus
/dev/kdbus(cf. devfs ).O kdbus era um projeto que visava reimplementar o D-Bus como um mecanismo de comunicação entre processos ponto a ponto mediado por kernel . Além das melhorias de desempenho, o kdbus teria vantagens decorrentes de outros recursos do kernel Linux , como namespaces e auditoria, segurança da mediação do kernel, condições de fechamento de corrida e permitindo que o D-Bus seja usado durante a inicialização e desligamento (conforme necessário pelo systemd). A inclusão do kdbus no kernel do Linux provou ser controversa e foi abandonada em favor do BUS1 , como uma comunicação mais genérica entre processos .
Ligações de linguagem
Vários vínculos de linguagem de programação para D-Bus foram desenvolvidos, como aqueles para Java , C # e Ruby .
Veja também
Referências
links externos
- Página inicial do D-Bus em Freedesktop.org
- Especificação D-Bus
- Introdução ao D-Bus no wiki Freedesktop.org
- Tutorial D-Bus
- Visão geral do DBus