크로스 플랫폼 IPC

크로스 플랫폼 IPC

---

가능한 IPC 메커니즘에 대한 제안을 찾고 있습니다.

• 크로스 플랫폼 (최소 Win32 및 Linux)
• C ++ 및 가장 일반적인 스크립팅 언어 (perl, ruby, python 등) 로 간단하게 구현할 수 있습니다 .
• 마지막으로 프로그래밍 관점에서 사용 하기 쉽습니다!

내 옵션은 무엇입니까? 저는 Linux에서 프로그래밍하고 있지만 나중에 다른 OS로 이식 할 수 있도록 작성하고 싶습니다. 소켓, 명명 된 파이프 또는 DBus와 같은 것을 사용하는 것에 대해 생각했습니다.

---

속도 측면에서 최고의 크로스 플랫폼 IPC 메커니즘은 파이프입니다. 그러나 동일한 시스템에서 교차 플랫폼 IPC를 원한다고 가정합니다. 원격 컴퓨터의 프로세스와 대화 할 수 있도록하려면 대신 소켓을 사용하는 것이 좋습니다. 운 좋게도 최소한 TCP에 대해 이야기하고 있다면 소켓과 파이프는 거의 동일한 동작을합니다. 설정 및 연결을위한 API는 다르지만 둘 다 데이터 스트림처럼 작동합니다.

그러나 어려운 부분은 통신 채널이 아니라 전달하는 메시지입니다. 당신은 정말로 당신을 위해 검증과 구문 분석을 수행 할 무언가를보고 싶어합니다. Google의 프로토콜 버퍼를 살펴 보는 것이 좋습니다 . 기본적으로 프로세스간에 전달하려는 개체를 설명하는 사양 파일을 만들고 사양과 일치하는 개체를 읽고 쓰기 위해 다양한 언어로 코드를 생성하는 컴파일러가 있습니다. 메시징 프로토콜을 작성하고 직접 구문 분석하는 것보다 훨씬 쉽고 버그 발생 가능성이 적습니다.

---

C ++의 경우 Boost IPC를 확인하십시오 .
스크립팅 언어에 대한 바인딩도 만들거나 찾을 수 있습니다.

그렇지 않으면 스크립팅 언어와 인터페이스 할 수있는 것이 정말 중요한 경우 가장 좋은 방법은 단순히 파일, 파이프 또는 소켓 또는 HTTP와 같은 더 높은 수준의 추상화를 사용하는 것입니다.

---

왜 D-Bus가 아닌가? 거의 모든 플랫폼에서 실행되고 견고성을 위해 설계된 매우 간단한 메시지 전달 시스템입니다. 이 시점에서 거의 모든 스크립팅 언어에서 지원됩니다.

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

---

YAMI 를 사용해보고 싶을 수도 있습니다. 매우 간단하지만 기능적이며 이식 가능하며 몇 가지 언어에 바인딩 할 수 있습니다.

---

휴대 가능하고 사용하기 쉬운 다국어 및 LGPL ed 솔루션을 원한다면 ZeroMQ를 추천합니다 .

• 놀랍도록 빠르고 거의 선형으로 확장 가능하며 여전히 간단합니다.
• 간단하고 복잡한 시스템 / 아키텍처에 적합합니다.
• 사용 가능한 매우 강력한 통신 패턴 : REP-REP, PUSH-PULL, PUB-SUB, PAIR-PAIR.
• VMware간에 연결이 실행되는 경우 프로토콜 오버 헤드의 일부를 줄이는 스마트 옵션을 사용하여 스레드 ( inproc://), 프로세스 ( ipc://) 또는 시스템 ( {tcp|pgm|epgm}://) 간에 메시지를 전달하는 경우 전송 프로토콜을보다 효율적으로 구성 할 수 있습니다. 가상 머신 ( vmci://).

직렬화 의 경우 필요에 따라 MessagePack 또는 Protocol Buffers (다른 사용자도 이미 언급 했음)를 제안 합니다.

---

방법에 대한 페이스 북의 드리프트 ?

Thrift는 확장 가능한 언어 간 서비스 개발을위한 소프트웨어 프레임 워크입니다. 소프트웨어 스택을 코드 생성 엔진과 결합하여 C ++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C #, Cocoa, Smalltalk 및 OCaml간에 효율적이고 원활하게 작동하는 서비스를 빌드합니다.

---

나는 당신이 소켓을 기반으로 한 것을 원할 것이라고 생각합니다.

IPC가 아닌 RPC를 원한다면 HTTP를 통해 실행되고 모든 언어에서 사용할 수있는 XML-RPC / SOAP와 같은 것을 제안합니다.

---

YAMI-Yet Another Messaging Infrastructure 는 경량 메시징 및 네트워킹 프레임 워크입니다.

---

plibsys C 라이브러리 를 사용하는 것이 좋습니다 . 매우 간단하고 가볍고 크로스 플랫폼입니다. LGPL에 따라 출시되었습니다. 다음을 제공합니다.

• 명명 된 시스템 전체 공유 메모리 영역 (System V, POSIX 및 Windows 구현)
• 액세스 동기화를위한 명명 된 시스템 전체 세마포 (System V, POSIX 및 Windows 구현)
• 공유 메모리 및 세마포어를 기반으로하는 명명 된 시스템 전체 공유 버퍼 구현
• IPv4 및 IPv6 지원 (UNIX 및 Windows 구현)이있는 소켓 (TCP, UDP, SCTP).

꽤 좋은 문서로 라이브러리를 사용하기 쉽습니다. C로 작성되었으므로 스크립팅 언어에서 쉽게 바인딩을 만들 수 있습니다.

프로세스간에 대용량 데이터 세트를 전달해야하는 경우 (특히 속도가 필수적인 경우) 공유 메모리를 사용하여 데이터 자체를 전달하고 소켓을 사용하여 데이터가 준비되었음을 프로세스에 알리는 것이 좋습니다. 다음과 같이 만들 수 있습니다.

• 프로세스는 데이터를 공유 메모리 세그먼트에 넣고 소켓을 통해 다른 프로세스로 알림을 보냅니다. 알림은 일반적으로 매우 작기 때문에 시간 오버 헤드가 최소화됩니다.
• 다른 프로세스는 통지를 수신하고 공유 메모리 세그먼트에서 데이터를 읽습니다. 그 후 데이터가 더 많은 데이터를 공급할 수 있도록 데이터가 첫 번째 프로세스로 다시 읽 혔다는 알림을 보냅니다.

이 접근 방식은 크로스 플랫폼 방식으로 구현할 수 있습니다.

---

조금 다른 것을 시도하고 싶다면 ZeroC 의 ICE 플랫폼이 있습니다 . 오픈 소스이며 생각할 수있는 거의 모든 OS에서 지원되며 C ++, C #, Java, Ruby, Python 및 PHP에 대한 언어 지원이 있습니다. 마지막으로 운전하기가 매우 쉽습니다 (언어 매핑은 각 언어에 자연스럽게 맞도록 조정됩니다). 또한 빠르고 효율적입니다. 장치 용 컷 다운 버전도 있습니다.

---

분산 컴퓨팅은 일반적으로 복잡하며 휠을 재발 명하는 대신 기존 라이브러리 또는 프레임 워크를 사용하는 것이 좋습니다. 이전 포스터는 이미 이러한 라이브러리와 프레임 워크를 열거했습니다. 필요에 따라 매우 낮은 수준 (예 : 소켓) 또는 높은 수준의 프레임 워크 (예 : CORBA)를 선택할 수 있습니다. 일반적인 "이 사용"대답은있을 수 없습니다. 분산 프로그래밍에 대해 교육을 받으면 작업에 적합한 라이브러리 또는 프레임 워크를 선택하는 것이 훨씬 쉬워집니다.

분산 컴퓨팅을 위해 널리 사용되는 C ++ 프레임 워크 인 ACE와 CORBA ORB TAO (ACE를 기반으로 함)가 있습니다. ACE http://www.cs.wustl.edu/~schmidt/ACE/ 에 대한 아주 좋은 책이 있으므로 살펴보실 수 있습니다. 조심해!

---

내가 아는 모든 OS에서 지원되고 거의 모든 언어로 액세스 할 수있는 파이프를 사용하는 것보다 더 간단하지 않습니다.

이 튜토리얼을 확인하십시오 .

---

localhost FTW에 대한 TCP 소켓.

---

파이썬에는 꽤 좋은 IPC 라이브러리가 있습니다. https://docs.python.org/2/library/ipc.html

---

Xojo는 IPCSocket 클래스 와 함께 내장 된 크로스 플랫폼 IPC 지원을 제공합니다 . 분명히 다른 언어로 "구현"할 수는 없지만 Xojo 콘솔 앱에서 사용하고 다른 언어에서 호출하여이 옵션을 매우 간단하게 만들 수 있습니다.

---

google protobufs are a really bad idea with you want easy to maintain and debug code. its too easy for people to abuse it and use it to pollute your code. the proto files are nice, but its basically the same thing as a structure header file, and the code it generates is complete crap making you wonder if it really a covert attack tool to sabotage software projects instead of automating them. After you use it for a while its almost impossible to remove it from your code. you are better off just using a header file of fix format structures that are easily debugged.

if you really need compression, switch to an address/data mapping of filing structures remotely... then packets are just a bundle of address/data pairs... also a structure that is very easy to automate with your own perl scripts that produce code that is human readable and debugable

참고 URL : https://stackoverflow.com/questions/60649/cross-platform-ipc