program tip

어떤 Linux IPC 기술을 사용해야합니까?

radiobox 2020. 11. 11. 19:41
반응형

어떤 Linux IPC 기술을 사용해야합니까?


우리는 아직 프로젝트의 설계 단계에 있지만 임베디드 Linux 커널에 세 개의 개별 프로세스를 갖는 것을 고려하고 있습니다. 프로세스 중 하나는 다양한 매체를 통해 장치와의 모든 통신을 처리하는 통신 모듈입니다.

나머지 두 프로세스는 통신 프로세스를 통해 메시지를주고받을 수 있어야합니다. Linux가 제공하는 IPC 기술을 평가하려고합니다. 다른 프로세스가 보낼 메시지는 디버그 로그에서 ~ 5Mbit 속도의 스트리밍 미디어에 이르기까지 크기가 다양합니다. 또한 미디어가 동시에 들어오고 나갈 수 있습니다.

이 응용 프로그램에 대해 어떤 IPC 기술을 제안 하시겠습니까? http://en.wikipedia.org/wiki/Inter-process_communication

프로세서가 400-500 Mhz에서 실행 중입니다. 크로스 플랫폼 일 필요는 없으며 Linux 만 사용할 수 있습니다. C 또는 C ++로 구현해야합니다.


나는 유닉스 도메인 소켓으로 갈 것이다. IP 소켓보다 오버 헤드가 적지 만 (즉, 기계 간 통신이 아님) 그렇지 않으면 동일한 편의성이있다.


IPC를 선택할 때 전송 버퍼 크기, 데이터 전송 메커니즘, 메모리 할당 체계, 잠금 메커니즘 구현 및 코드 복잡성을 포함한 성능 차이의 원인을 고려해야합니다.

사용 가능한 IPC 메커니즘 중에서 성능에 대한 선택은 종종 Unix 도메인 소켓 또는 명명 된 파이프 (FIFO)에 있습니다. IPC 용 Unix 도메인 소켓이 최상의 성능을 제공 할 수 있음을 나타내는 프로세스 간 통신위한 다양한 메커니즘의 성능 분석 논문을 읽었습니다 . 파이프가 더 좋을 수 있음을 나타내는 다른 곳 에서 충돌하는 결과를 보았습니다 .

소량의 데이터를 보낼 때는 단순성을 위해 명명 된 파이프 (FIFO)를 선호합니다. 양방향 통신을 위해 한 쌍의 명명 된 파이프가 필요합니다. Unix 도메인 소켓은 설정 (소켓 생성, 초기화 및 연결)에 약간 더 많은 오버 헤드가 발생하지만 더 유연하고 더 나은 성능 (더 높은 처리량)을 제공 할 수 있습니다.

자신에게 가장 적합한 것이 무엇인지 결정하기 위해 특정 애플리케이션 / 환경에 대해 몇 가지 벤치 마크를 실행해야 할 수도 있습니다. 제공된 설명에서 Unix 도메인 소켓이 가장 적합 할 수 있습니다.


Beej의 Unix IPC 가이드 는 Linux / Unix IPC를 시작하는 데 유용합니다.


아무도 dbus를 언급하지 않았다는 것을 믿을 수 없습니다.

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

http://en.wikipedia.org/wiki/D-Bus

애플리케이션이 구조적으로 단순하다면 성능이 중요한 제어 된 임베디드 환경에서는 공유 메모리를 능가 할 수 없습니다.


성능이 실제로 문제가되는 경우 공유 메모리를 사용할 수 있지만 다른 방법보다 훨씬 더 복잡합니다. 데이터가 준비되었음을 알리는 신호 메커니즘 (세마포 등)과 구조에 대한 동시 액세스를 방지하는 잠금이 필요합니다. 수정되는 동안.

장점은 많은 데이터를 메모리에 복사하지 않고도 전송할 수 있다는 것입니다. 따라서 어떤 경우에는 확실히 성능이 향상됩니다.

아마도 공유 메모리를 통해 더 높은 수준의 프리미티브를 제공하는 사용 가능한 라이브러리가있을 것입니다.

공유 메모리는 일반적으로 MAP_SHARED를 사용하여 동일한 파일을 mmap하여 얻습니다 (유지하지 않으려면 tmpfs에있을 수 있음). 많은 앱도 System V 공유 메모리를 사용합니다 (어리석은 역사적 이유로 IMHO; 동일한 것에 대한 훨씬 덜 좋은 인터페이스)


이 글을 쓰는 시점 (2014 년 11 월) Kdbus와 Binder는 리눅스 커널의 스테이징 브랜치를 떠났습니다. 이 시점에서 어느 쪽도 성공할 것이라는 보장은 없지만 전망은 둘 다에 대해 다소 긍정적입니다. Binder는 Android의 경량 IPC 메커니즘이며, Kdbus는 컨텍스트 전환을 줄여 메시징 속도를 크게 높이는 커널의 dbus와 유사한 IPC 메커니즘입니다.

"투명한 프로세스 간 통신"또는 TIPC도 있습니다. 이는 강력하고 클러스터링 및 다중 노드 설정에 유용합니다. http://tipc.sourceforge.net/


Unix 도메인 소켓은 대부분의 IPC 요구 사항을 해결합니다. 커널이이 IPC 기능을 제공하기 때문에이 경우 전용 통신 프로세스가 실제로 필요하지 않습니다. 또한, 제 생각에는 Linux에서 가장 많이 사용되지 않는 IPC 중 하나이지만 n : 1 통신이 필요한 많은 경우에 매우 편리하게 사용되는 POSIX 메시지 대기열을 살펴보십시오.

참고 URL : https://stackoverflow.com/questions/2281204/which-linux-ipc-technique-to-use

반응형