c++ python linux cross-platform ipc

c++ - Plataforma cruzada IPC



python linux (15)

Estoy buscando sugerencias sobre posibles mecanismos de IPC que sean:

  • Plataforma cruzada (Win32 y Linux al menos)
  • Simple de implementar en C ++ , así como los 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.


¿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


¿Qué tal el Ahorro de Facebook ?

Thrift es un marco de software para el desarrollo de servicios escalables de idiomas cruzados. 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.


Creo que querrás algo basado en sockets.

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


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 pasas sobre él. Realmente desea ver algo que realice la verificación y el análisis para usted. Recomiendo mirar los Buffers de Protocolo de Google. 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.


Es posible que desee probar YAMI , es muy simple pero funcional, portátil y viene con enlace a algunos idiomas


La informática distribuida suele ser compleja y se recomienda utilizar bibliotecas o 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 ++ muy utilizado para computación distribuida llamada ACE y el 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!


Los protobufs de Google son una muy mala idea, con un código de depuración y mantenimiento fácil. 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 sus propios scripts Perl que producen código que es legible por humanos y debuable


No es más simple que usar pipes, que son compatibles con todos los sistemas operativos que conozco, y se puede acceder en casi todos los idiomas.

Mira this tutorial.


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 es simplemente usar archivos, tuberías o tomas de corriente o incluso una abstracción de nivel superior como HTTP.


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

  • regiones de memoria compartida nombradas en todo el sistema (implementaciones System V, POSIX y Windows);
  • nombrados semáforos en todo el sistema para sincronización de acceso (implementaciones System V, POSIX y Windows);
  • implementación del buffer compartido nombrado en todo el sistema basado en la memoria compartida y el semáforo;
  • sockets (TCP, UDP, SCTP) con soporte 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 los 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. Puedes 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.


Python tiene una biblioteca de IPC bastante buena: ver


Si desea una solución portable, fácil de usar, multilingüe y LGPL ed, le recomendaría 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-PAR.
  • Puede configurar el protocolo de transporte para que sea más eficiente si está pasando mensajes entre hilos ( inproc:// ), procesos ( ipc:// ) o máquinas ( {tcp|pgm|epgm}:// ), con un {tcp|pgm|epgm}:// inteligente opción para eliminar parte de los gastos generales del protocolo en caso de que las conexiones se estén ejecutando entre máquinas virtuales VMware ( vmci:// ).

Para la serialización sugeriría MessagePack o Protocol Buffers (que otros ya han mencionado también), dependiendo de sus necesidades.


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.


Sockets TCP para localhost FTW.


YAMI es un marco liviano de mensajería y redes.