유닉스 도메인 소켓 VS 명명 된 파이프?


122

소켓이라는 이름의 유닉스를 살펴본 후 파이프라는 이름으로 생각했습니다. 나는 이름 파이프를 보았고 큰 차이를 보지 못했습니다. 나는 그들이 다르게 초기화되는 것을 보았지만 그것이 내가 알아 차리는 유일한 것입니다. 둘 다 C 쓰기 / 읽기 기능을 사용하고 AFAIK와 유사하게 작동합니다.

유닉스 도메인 소켓과 명명 된 파이프의 차이점은 무엇입니까? 언제 다른 하나를 선택해야합니까? 기본적으로 어떤 것을 사용해야합니까 (예 : deque, list 또는 필요한 경우 다른 것을 사용하는 것보다 C ++에서 기본적으로 벡터를 사용하는 방법)?

c  linux 

1
@GregHewgill : 불행히도 그 질문은 내가 묻고있는 차이보다는 "IPC가 무엇인가"에 더 가깝습니다. 글을 올리기 전에 봤는데, 링크해서 관련 말을 했어야하나요? (나에게 도움이되지

1
@acid : 예, 관련 질문을 연결하고 아직 가지고있는 질문을 설명하는 것은 항상 좋은 생각입니다.
Ben Voigt 2012

3
이 기사는 그것을 잘 요약했습니다. 신비성을 유닉스 도메인 소켓 : thomasstover.com/uds.html
콩 엄마

끊어진 링크 : techdeviancy.com/uds.html
mcdado

답변:


106

UNIX 도메인 소켓은 일반적으로 명명 된 파이프보다 더 유연합니다. 몇 가지 장점은 다음과 같습니다.

  • 통신하는 두 개 이상의 프로세스에 사용할 수 있습니다 (예 : 잠재적으로 여러 클라이언트 프로세스가 연결되는 서버 프로세스).
  • 양방향입니다.
  • 프로세스간에 커널 확인 UID / GID 자격 증명 전달을 지원합니다.
  • 프로세스 간 파일 설명자 전달을 지원합니다.
  • 패킷 및 시퀀스 패킷 모드를 지원합니다.

이러한 많은 기능을 사용하려면, 당신은 사용할 필요가 send()/의 recv()시스템 호출보다는 가족 write()/을 read().


11
다른 한편으로, 이름 파이프는 일반적인 open(2)호출을 통해 "연결"될 수 있다는 이점이 있으므로 일반적으로 파일 이름 인수 만 취하는 프로그램 간의 임시 파이프 라인을 구성하는 데 더 적합합니다.
Dolda2000

66

한 가지 차이점은 명명 된 파이프는 단방향이므로 양방향 통신을 수행하려면 둘 중 두 개를 사용해야합니다. 물론 소켓은 양방향입니다. 하나가 아닌 두 개의 변수를 사용하는 것이 약간 더 복잡해 보입니다 (즉, 하나의 소켓 대신 두 개의 파이프).

또한 위키피디아 기사는 다음과 같은 점 에서 매우 명확 합니다 . "유닉스 도메인 소켓은 바이트 스트림 또는 데이터 그램 시퀀스로 생성 될 수 있지만 파이프는 바이트 스트림 전용입니다."


명명 된 파이프는 실제로 양방향이지만 반이중 입니다. 이것은 통신이 끝 A에서 끝 B로 또는 B에서 A로 갈 수 있지만 동시에 둘다는 불가능 함을 의미합니다.


1
흠 흥미로운 +1. 바이트 스트림과 데이터 그램의 차이점을 우연히 알고 있습니까? 이 질문에 대해 이미 한 것처럼 한두 가지 예를 들었습니까?

7
@acidzombie : 데이터 그램 모드 파이프 또는 소켓은 경계를 유지하므로 한 번의 write호출 이 하나의 호출을 생성 read합니다. 스트림 모드에서 데이터는 하나의 긴 스트림으로 함께 연결될 수 있으므로 한 번에 많은 쓰기를 읽을 수 있으며 그 반대의 경우도 마찬가지입니다. (윈도우 jtoberon의 대답에 따라, 데이터 그램 파이프를 가지고 유닉스하지 않습니다)
벤 보이트

1
@BenVoigt 잘, 데이터 그램 소켓 패킷 전달은 신뢰할 수 없으므로 쓰기가 반드시 읽기 호출을 생성하지는 않습니다. 아마도 로컬 소켓의 경우이지만 귀하의 의견에서 명확하지 않습니다. 따라서 문제가 있습니다.
xaxxon

3
@xaxxon : 파이프와 유닉스 도메인 소켓 은 모두 로컬이므로 수신자가 대기열을 전혀 비우고 있으므로 무손실입니다.
Ben Voigt 2013 년

6
예, 달리 UDP 데이터 그램 유닉스 도메인 소켓이 있습니다 보장 순서대로 전달.
jtchitty
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.