Pregunta

Estoy buscando sugerencias sobre posibles mecanismos de IPC que sean:

  • Plataforma cruzada (Win32 y Linux al menos)
  • Sencillo de implementar en C++ así como el lenguajes de scripting más comunes (Perl, Ruby, Python, etc.).
  • Finalmente, fácil de usar desde el punto de vista de la programación!

¿Cuales son mis opciones?Estoy programando en Linux, pero me gustaría que lo que escribo sea portátil a otros sistemas operativos en el futuro.He pensado en usar sockets, canalizaciones con nombre o algo como DBus.

¿Fue útil?

Solución

En términos de velocidad, el mejor mecanismo IPC multiplataforma serán las tuberías.Sin embargo, eso supone que desea IPC multiplataforma en la misma máquina.Si desea poder comunicarse con procesos en máquinas remotas, querrá considerar el uso de sockets.Afortunadamente, si estás hablando al menos de TCP, los sockets y las tuberías se comportan más o menos de la misma manera.Si bien las API para configurarlos y conectarlos son diferentes, ambas simplemente actúan como flujos de datos.

Lo difícil, sin embargo, no es el canal de comunicación, sino los mensajes que se transmiten por él.Realmente desea ver algo que realice la verificación y el análisis por usted.Recomiendo mirar en Google. Búfers de protocolo.Básicamente, crea un archivo de especificaciones que describe el objeto que desea pasar entre procesos, y hay un compilador que genera código en varios lenguajes diferentes 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 analizarlo usted mismo.

Otros consejos

Para C++, consulte Impulsar la PCI.
Probablemente también pueda crear o encontrar algunos enlaces para los lenguajes de secuencias de comandos.

De lo contrario, si es realmente importante poder interactuar con lenguajes de secuencias de comandos, lo mejor que puede hacer es simplemente utilizar archivos, tuberías o sockets o incluso una abstracción de nivel superior como HTTP.

¿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.En este momento, es compatible con casi todos los lenguajes de programación.

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

Quizás quieras intentarlo YAMI , es muy simple pero funcional, portátil y viene con enlace a algunos idiomas

Si desea un sistema portátil, fácil de usar, multilingüe y LGPLsolución ed, te recomendaría CeroMQ:

  • Increíblemente rápido, escalable casi lineal y aún así 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 hacerlo más eficiente si pasa mensajes entre subprocesos (inproc://), procesos (ipc://) o máquinas ({tcp|pgm|epgm}://), con una opción inteligente para eliminar parte de los gastos generales del protocolo en caso de que se ejecuten conexiones entre máquinas virtuales VMware (vmci://).

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

Qué tal si El ahorro de Facebook?

Thrift es un marco de software para el desarrollo de servicios escalables en varios idiomas.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 a través de HTTP y se puede usar desde cualquier idioma.

YAMI: otra infraestructura de mensajería más es un marco ligero de mensajería y redes.

Si estás dispuesto a probar algo un poco diferente, existe la HIELO plataforma de CeroC.Es de código abierto y es compatible con prácticamente todos los sistemas operativos que puedas imaginar, además de tener soporte de lenguajes para C++, C#, Java, Ruby, Python y PHP.Por último, es muy fácil de conducir (las asignaciones de idiomas 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.

Puedo sugerirle que utilice el plibsys Biblioteca C.Es muy simple, liviano y multiplataforma.Publicado bajo la LGPL.Proporciona:

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

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

Si necesita pasar grandes conjuntos de datos entre procesos (especialmente si la velocidad es esencial), es mejor usar memoria compartida para pasar los datos en sí y 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 a través de un socket a otro proceso;como una notificación suele ser muy pequeña, el tiempo empleado es mínimo;
  • 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 al primer proceso para que pueda alimentar más datos.

Este enfoque se puede implementar de forma multiplataforma.

La informática distribuida suele ser compleja y se recomienda utilizar bibliotecas o marcos existentes en lugar de reinventar la rueda.El cartel anterior ya enumeró un par de estas bibliotecas y marcos.Dependiendo de sus necesidades, puede elegir un marco de muy bajo nivel (como sockets) o de alto nivel (como CORBA).No puede haber una respuesta genérica de "usa esto".Debe informarse 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 C++ muy utilizado para la informática distribuida llamado ACE y CORBA ORB TAO (que se basa en ACE).Existen muy buenos libros sobre ACE. http://www.cs.wustl.edu/~schmidt/ACE/ así que podrías echarle un vistazo.¡Cuidarse!

No hay nada más sencillo que usar canalizaciones, que son compatibles con todos los sistemas operativos que conozco y a las que se puede acceder en prácticamente todos los idiomas.

Verificar este tutorial.

Conectores TCP para localhost FTW.

Python tiene una biblioteca IPC bastante buena:ver https://docs.python.org/2/library/ipc.html

Xojo tiene soporte IPC multiplataforma incorporado con su clase IPCSocket.Aunque obviamente no podrías "implementarlo" en otros idiomas, podrías usarlo en una aplicación de consola Xojo y llamarlo desde otros idiomas, haciendo que esta opción sea quizás muy sencilla para ti.

Los protobufs de Google son una muy mala idea, ya que desea un código fácil de mantener y depurar.Es muy fácil para la gente abusar de él y usarlo para contaminar su código.los archivos proto son buenos, pero es básicamente lo mismo que un archivo de encabezado de estructura, y el código que genera es una completa basura que te hace preguntarte 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 que utilice simplemente un archivo de encabezado con estructuras de formato fijo que se puedan depurar fácilmente.

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

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top