Comunicação inter-processos com IPCMSG
A biblioteca IPCMSG foi criada para facilitar o desenvolvimento de programas que utilizam comunicação inter-processo. Nesse artigo aprenderemos, de forma prática, como usar essa biblioteca em seus códigos C/C++. O projeto se encontra em fase embrionária, portanto é fundamental ajudas, CRÍTICAS e/ou sugestões para amadurecimento do projeto. ” A nota foi enviada por Alessandro de Oliveira Faria (alessandrofariaΘnetitec·com·br), que acrescentou este link da fonte para maiores detalhes.(postado por Augusto Campos)
Comentários dos leitores
Comentário de Joao Pedro
21/10/05 14:30
Dúvida: Alguém pode me explicar para o que serve isto que o Cabelo fez?
Comentário de adilson
21/10/05 23:04 - usuário registrado #239
Grosso modo: IPC ou comunicação inter-processos, como o nome já diz, serve para que processos diferentes comuniquem-se uns com os outros passando dados, mensagens, comunicações de estados entre eles, etc. Existem várias maneiras de se fazer isso, a biblioteca acima cria uma maneira bem prática.
Digamos, por exemplo, que você tenha dois programas, um para extrair faixas de CDs e outro que transforma o resultado do primeiro em ogg.
Você poderia usar essa biblioteca para que eles conversem entre si, o primeiro avisando que terminou de extrair o arquivo 1.wav para o segundo, fazendo com que ele comece a codificação.
Depois você resolve escrever uma interface gráfica para estes programas. Usando o mesmo método, sua interface pode dizer para o ripador "extra as faixas 1,2 e 3 do CD em tal drive" e ficar, por sua vez, recebendo informações dos dois programas sobre o estado deles, se estão rodando certo, quantos % já foi extraído e codificado, etc.
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca
Digamos, por exemplo, que você tenha dois programas, um para extrair faixas de CDs e outro que transforma o resultado do primeiro em ogg.
Você poderia usar essa biblioteca para que eles conversem entre si, o primeiro avisando que terminou de extrair o arquivo 1.wav para o segundo, fazendo com que ele comece a codificação.
Depois você resolve escrever uma interface gráfica para estes programas. Usando o mesmo método, sua interface pode dizer para o ripador "extra as faixas 1,2 e 3 do CD em tal drive" e ficar, por sua vez, recebendo informações dos dois programas sobre o estado deles, se estão rodando certo, quantos % já foi extraído e codificado, etc.
___
Nullum magnum ingenium sine mixtura dementiae fuit - Seneca
Comentário de Alessandro de Oliveria Faria ( CABELO )
22/10/05 5:12
Guia de referência do programador.: Acabo de terminar o Guia do Programador:
Clique AQUI para visualiza-lo.
Clique AQUI para visualiza-lo.
Comentário de Ananias
23/10/05 3:59 - usuário registrado #444
CRÍTICAS: Evidentemente, ninguém deve ter pensado em utilizar o D-BUS, que é a biblioteca de IPC do FreeDesktop.org, que diversas aplicações estão usando, e que tem bindings para diversas linguagens.
Afinal, para que unir forças, se podemos fazer dois softwares distintos, que fazem a mesma coisa. (e dessa vez não dá nem pra dizer que é pro usuário poder escolher, já que o usuário não vê IPC)
O futuro ideal é que existam 3 milhôes de bibliotecas de IPC, e, se eu quiser fazer uma aplicação que consiga falar com qualquer programa eu tenha que escrever código para as três milhões de bibliotecas, e linkar meu programa com todas elas.
Como IPC é um "Instant Messenger" para programas, só posso imaginar que o próximo projeto seja um padrão de IM livre, não compatível com o Jabber. A analogia aqui é perfeita. Se a comunidade do SL se dividir em dois protocolos não compatíves de IM, um usuário que queira falar com qualquer pessoa vai precisar de pelo menos dois clientes. Com duas bibliotecas de IPC temos o mesmo efeito.
Se o projeto está sendo desenvolvido como aprendizado e/ou diversão ótimo. Agora, se alguém estiver precisando utilizar uma solução de IPC, escolha o D-Bus. Não precisamos de milhões de padrões diferentes para fazer a mesma coisa.
Afinal, para que unir forças, se podemos fazer dois softwares distintos, que fazem a mesma coisa. (e dessa vez não dá nem pra dizer que é pro usuário poder escolher, já que o usuário não vê IPC)
O futuro ideal é que existam 3 milhôes de bibliotecas de IPC, e, se eu quiser fazer uma aplicação que consiga falar com qualquer programa eu tenha que escrever código para as três milhões de bibliotecas, e linkar meu programa com todas elas.
Como IPC é um "Instant Messenger" para programas, só posso imaginar que o próximo projeto seja um padrão de IM livre, não compatível com o Jabber. A analogia aqui é perfeita. Se a comunidade do SL se dividir em dois protocolos não compatíves de IM, um usuário que queira falar com qualquer pessoa vai precisar de pelo menos dois clientes. Com duas bibliotecas de IPC temos o mesmo efeito.
Se o projeto está sendo desenvolvido como aprendizado e/ou diversão ótimo. Agora, se alguém estiver precisando utilizar uma solução de IPC, escolha o D-Bus. Não precisamos de milhões de padrões diferentes para fazer a mesma coisa.
Comentário de Ananias
23/10/05 4:00 - usuário registrado #444
Faltou o link: http://www.freedesktop.org/Software/dbus
Comentário de Alessandro de Oliveira Faria (CABELO)
23/10/05 13:09
Concordo plenamente, ENTRETANTO...: O Ananias tem razão sobre a sua colocação onde menciona a união de forças no desenvolvimento. Porém existem alguns fatores de deram origem a biblioteca.
1 - Quando inicie o desenvolvimento da IPCMSG (Janeiro de 2003), se não me falha a memória não havia implementação de socket na lib D-BUS ou não pesquisei direito ;-). Uma das principais necessidades do projeto que originou a biblioteca.
2 - A empresa (CLIENTE) precisava desenvolver algo para posterior comercialização. Para não violar a GPL (posso até ter errado), mas eu mesmo propus o desenvolvimento de algo novo não cópia aprimorada. Assim obtive um contrato de desenvolvimento (trabalhei e recebi por isto ou seja gerei renda (horas trabalhadas) para o leite das crianças).
3 - Tenho a filosofia de publicar todos os meus trabalhos open e proprietário para a comunidade, desde que não haja violação dos direitos contratuais de meu cliente.
Resumindo seria bem mais cômodo eu, adquirir a D-BUS e adaptá-la as minhas necessidades (ninguém iria ficar sabendo inicialmente). Mas por honestidade, sensatez e motivos comerciais resolvi cria uma lib para atender o projeto proprietário. Depois retirei as rotinas mencionadas no contrato de sigilo e publique o meu trabalho para a comunidade.
Mesmo assim Ananias, como sempre menciono toda crítica deve ser aceita como forma de expressão. Nesta vida percebi que tiramos mais proveito das críticas do que dos elogios.
Um abraço
CABELO
1 - Quando inicie o desenvolvimento da IPCMSG (Janeiro de 2003), se não me falha a memória não havia implementação de socket na lib D-BUS ou não pesquisei direito ;-). Uma das principais necessidades do projeto que originou a biblioteca.
2 - A empresa (CLIENTE) precisava desenvolver algo para posterior comercialização. Para não violar a GPL (posso até ter errado), mas eu mesmo propus o desenvolvimento de algo novo não cópia aprimorada. Assim obtive um contrato de desenvolvimento (trabalhei e recebi por isto ou seja gerei renda (horas trabalhadas) para o leite das crianças).
3 - Tenho a filosofia de publicar todos os meus trabalhos open e proprietário para a comunidade, desde que não haja violação dos direitos contratuais de meu cliente.
Resumindo seria bem mais cômodo eu, adquirir a D-BUS e adaptá-la as minhas necessidades (ninguém iria ficar sabendo inicialmente). Mas por honestidade, sensatez e motivos comerciais resolvi cria uma lib para atender o projeto proprietário. Depois retirei as rotinas mencionadas no contrato de sigilo e publique o meu trabalho para a comunidade.
Mesmo assim Ananias, como sempre menciono toda crítica deve ser aceita como forma de expressão. Nesta vida percebi que tiramos mais proveito das críticas do que dos elogios.
Um abraço
CABELO