2008-09-13 17 views
60

Busco sugerencias sobre posibles mecanismos de IPC que son:Cruz plataforma IPC

  • Cruz plataforma (Win32 y Linux al menos)
  • fácil de implementar en C++, así como la lenguajes de scripting más comunes (perl, ruby, python, etc.).
  • Finalmente, ¡fácil de usar desde el punto de vista de la programación!

¿Cuáles son mis opciones? Estoy programando en Linux, pero me gustaría que lo que escribo sea portátil para otros sistemas operativos en el futuro. He pensado en usar sockets, named pipes o algo así como DBus.

Respuesta

46

En términos de velocidad, el mejor mecanismo de IPC multiplataforma será el de las tuberías. Sin embargo, eso supone que desea un IPC multiplataforma en la misma máquina. Si desea poder hablar con procesos en máquinas remotas, en su lugar, querrá usar sockets. Afortunadamente, si hablamos de TCP al menos, los sockets y pipes se comportan de manera muy similar. Si bien las API para configurarlas y conectarlas son diferentes, ambas actúan como flujos de datos.

La parte difícil, sin embargo, no es el canal de comunicación, sino los mensajes que pasa sobre él. Realmente desea ver algo que realice la verificación y el análisis para usted. Recomiendo mirar Google Protocol Buffers. Básicamente, crea un archivo de especificaciones que describe el objeto que desea pasar entre los procesos, y hay un compilador que genera código en varios idiomas para leer y escribir objetos que coinciden con la especificación. Es mucho más fácil (y menos propenso a errores) que intentar crear un protocolo de mensajería y un analizador.

+5

+1 para Protocol Buffers, muy buena alternativa para IPC/RPC. – sharkin

+1

+1 La primera vez que escuché acerca de los Buffers de Protocolo. Sin duda será útil pronto. – AdamW

+0

¿Son las tuberías la respuesta cuando desea comunicarse con un proceso que ya se inició y se está ejecutando?Para eso, deberían ser tomas de corriente ¿no? – donatello

15

Para C++, consulte Boost IPC.
Probablemente también pueda crear o encontrar algunos enlaces para los lenguajes de scripting.

De lo contrario, si es realmente importante poder interactuar con los lenguajes de scripting, lo mejor que puede hacer es simplemente usar archivos, tuberías o zócalos o incluso una abstracción de nivel superior como HTTP.

5

¿Qué tal Facebook's Thrift?

Thrift es un marco de software para el desarrollo de servicios multilingües escalables. Combina una pila de software con un motor de generación de código para crear servicios que funcionen de manera eficiente y sin problemas entre C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk y OCaml.

+2

Suena como un montón de sobrecarga. –

3

No es más sencillo que utilizar tuberías, que se admiten en todos los sistemas operativos que conozco, y se puede acceder en casi todos los idiomas.

Consulte this tutorial.

+1

El enlace del tutorial está roto, ¿tiene otro enlace o algunas palabras clave que podríamos usar para rastrearlo? – rcreswick

+1

Por lo que sé, no hay una API api que sea similar en Win32 y Unix a menos que use cygwin, que no es una opción muy conveniente para la mayoría de los programas de Windows. – Laserallan

+1

[Aquí] (http://web.archive.org/web/20080919054639/http://www.utdallas.edu/~kcooper/teaching/3375/Tutorial6a/tutorial6.htm) es el enlace del tutorial a través de la máquina de retorno . – Russ

4

Sockets TCP a localhost FTW.

5

Creo que querrá algo basado en sockets.

Si desea RPC en lugar de solo IPC, sugeriría algo como XML-RPC/SOAP que se ejecuta a través de HTTP y puede utilizarse desde cualquier idioma.

+1

RPC ** es ** una tecnología IPC ... – schlamar

+0

Sí, supongo que me refiero a RPC como inter-máquina (multiplataforma entre dos máquinas que ejecutan diferentes SO), e IPC como significado entre dos procesos en una máquina (cross- plataforma en el nivel de origen para construcciones, por ejemplo, Linux y Windows). –

4

Si está dispuesto a probar algo un poco diferente, existe la plataforma ICE de ZeroC. Es de código abierto, y es compatible con casi todos los sistemas operativos que se te ocurran, además de tener soporte de lenguaje para C++, C#, Java, Ruby, Python y PHP. Finalmente, es muy fácil de conducir (las asignaciones de idioma están diseñadas para adaptarse de forma natural a cada idioma). También es rápido y eficiente. Incluso hay una versión reducida para dispositivos.

7

Es posible que desee probar YAMI, es muy simple pero funcional, portátil y viene con la unión a pocos idiomas

+0

+1 es una nueva para mí y parece interesante. – RSabet

9

Por qué no D-Bus? Es un sistema de paso de mensajes muy simple que se ejecuta en casi todas las plataformas y está diseñado para ser robusto. Es compatible con casi todos los lenguajes de scripting en este punto.

http://freedesktop.org/wiki/Software/dbus

+0

"D-Bus se licencia bajo su elección de la Licencia Académica versión 2.1, o la Licencia Pública General GNU versión 2." - GPL puede no ser adecuado. – Nick

+0

@Nick La licencia de D-Bus solo lo afectará si intenta modificar D-Bus. Siempre y cuando solo lo use para comunicación, realmente no importa si D-Bus es GPL – SystematicFrank

+1

. Hay algunas desventajas de D-BUS (aparte de la licencia): 1) no es exactamente rápido 2) Necesita un daemon corriendo para que d-bus funcione (afaik) – kralyk

3

La computación distribuida suele ser complejo y que están bien aconseja el uso de las bibliotecas o los marcos existentes en lugar de reinventar la rueda. El póster anterior ya ha enumerado un par de estas bibliotecas y marcos. Dependiendo de sus necesidades, puede seleccionar un nivel muy bajo (como sockets) o un marco de alto nivel (como CORBA). No puede haber una respuesta genérica de "usa esto". Necesita educarse sobre la programación distribuida y luego le resultará mucho más fácil elegir la biblioteca o el marco adecuado para el trabajo.

Existe un marco de C++ ampliamente utilizado para computación distribuida llamada ACE y CORBA ORB TAO (que se basa en ACE). Existen muy buenos libros sobre ACE http://www.cs.wustl.edu/~schmidt/ACE/ por lo que podría echarle un vistazo. ¡Cuídate!

-5

Los protobufs de Google son una muy mala idea con lo que usted quiere es fácil de mantener y depurar el código. es demasiado fácil para las personas abusar de él y usarlo para contaminar su código. los archivos proto son agradables, pero básicamente es lo mismo que un archivo de encabezado de estructura, y el código que genera es una porquería completa, por lo que uno se pregunta si realmente es una herramienta de ataque encubierta para sabotear proyectos de software en lugar de automatizarlos. Después de usarlo por un tiempo, es casi imposible eliminarlo de su código. es mejor utilizar un archivo de cabecera de estructuras de formato de corrección que se puedan depurar fácilmente.

si realmente necesita compresión, cambie a una asignación de dirección/datos de estructuras de archivo de forma remota ... entonces los paquetes son solo un conjunto de pares de direcciones/datos ... también una estructura que es muy fácil de automatizar con su scripts de perl propios que producen código que sea legible y debugable

+0

¿Puedes dar un buen ejemplo? –

4

Si quieres una, fácil de usar, multi-idioma portátil y solución ed LGPL, le recomiendo que ZeroMQ:

  • increíblemente rápido, casi lineal escalable y aún simple.
  • Adecuado para sistemas/arquitecturas simples y complejos.
  • Patrones de comunicación muy potentes disponibles: REP-REP, PUSH-PULL, PUB-SUB, PAR-PAIR.
  • Puede configurar el protocolo de transporte para que sea más eficiente si está de paso de mensajes entre las roscas (inproc://), procesos (ipc://) o máquinas ({tcp|pgm|epgm}://), con una opción inteligente para cortar alguna parte de los gastos generales de protocolo en caso de que las conexiones se estén ejecutando entre las máquinas virtuales de VMware (vmci://).

Para la serialización, sugeriría MessagePack o Protocol Buffers (que otros ya han mencionado), según sus necesidades.

2

Puedo sugerirle que use la biblioteca C plibsys. Es muy simple, liviano y multiplataforma. Publicado bajo LGPL. Proporciona:

  • denominadas regiones de memoria compartida en todo el sistema (implementaciones System V, POSIX y Windows);
  • semáforos nombrados en todo el sistema para la sincronización de acceso (implementaciones System V, POSIX y Windows);
  • implementación de búfer compartido en todo el sistema basado en la memoria compartida y el semáforo;
  • sockets (TCP, UDP, SCTP) con compatibilidad con IPv4 e IPv6 (implementaciones de UNIX y Windows).

Es una biblioteca fácil de usar con una documentación bastante buena. Como está escrito en C, puede hacer enlaces fácilmente desde lenguajes de scripting.

Si necesita pasar grandes conjuntos de datos entre procesos (especialmente si la velocidad es esencial), es mejor usar la memoria compartida para pasar los datos y los sockets para notificar a un proceso que los datos están listos. Puede hacerlo de la siguiente manera:

  • un proceso coloca los datos en un segmento de memoria compartida y envía una notificación mediante un socket a otro proceso; como una notificación generalmente es muy pequeña, la sobrecarga de tiempo es mínima;
  • otro proceso recibe la notificación y lee los datos del segmento de memoria compartida; después de eso, envía una notificación de que los datos se leyeron nuevamente en el primer proceso para que pueda alimentar más datos.

Este enfoque se puede implementar de forma multiplataforma.