![두 파일 설명자(클라이언트) 간의 통신](https://linux55.com/image/162432/%EB%91%90%20%ED%8C%8C%EC%9D%BC%20%EC%84%A4%EB%AA%85%EC%9E%90(%ED%81%B4%EB%9D%BC%EC%9D%B4%EC%96%B8%ED%8A%B8)%20%EA%B0%84%EC%9D%98%20%ED%86%B5%EC%8B%A0.png)
파일 설명자를 이해하는 방법과 한 파일 설명자에서 데이터를 읽고 처리한 다음 다른 파일 설명자로 보내는 방법을 이해하는 데 어려움을 겪고 있습니다.
서버로서 연결을 수락하고, 데이터를 수신하고, 데이터를 처리한 다음 이를 다른 클라이언트에 전달할 수 있어야 합니다.
나는 어제 epolling에 대해 배웠고 클라이언트-서버 네트워크를 만드는 데 내 전략이 올바른지 알고 싶습니다.
epollfd를 만들었습니다. 나는 이를 에지 트리거(EPOLLET) 및 비차단(사용: flags |= 0_NONBLOCK
및 fctnl(epollfd, F_SETFL, flags)
.
이제 내 의도는 networkfds(클라이언트 소켓) 배열을 만들고 연결/메시지를 수신하는 것입니다.
- 새로운 데이터에 대한 알림 받기
- 데이터 읽기
- 데이터 처리
- 일부 데이터를 다른 소켓에 씁니다.
Linux Man과 온라인에서 찾은 모든 예제는 소켓에서 데이터를 읽는 방법에 대한 정보만 제공합니다. 내 디자인이 어리석고 동시에 많은 클라이언트와 통신하도록 하면 실패할까봐 걱정됩니다. .
NGINX(웹서버는 epolling을 사용하고 있습니다)라는 글을 읽고 여기에 물어보기로 했습니다.
누구든지 도와줄 수 있나요?
편집 1: 목록(struct epoll_event *events)에 (많은) 소켓을 갖고 epoll_wait()를 통해 액세스할 계획입니다.
// If I understand correctly:
int ndfs = epoll_wait(epollfd, events, MAX_EVENTS, -1);
// Puts some events in the <events> array and an int in ndfs
nfds
events
이제 for 루프를 사용하여 반복할 수 있는 사용 가능한 fd 수가 포함되어야 합니다 . 매뉴얼에서 배운 내용입니다.
그 중 하나로부터 메시지를 받으면 이를 처리하고(즉, 내용을 읽고 결정을 내리고) 결국 다른 소켓에 대한 쓰기를 트리거할 수 있기를 원합니다.
멀티스레딩을 방지하기 위해 이렇게 합니다. 이것이 가능합니까?
답변1
질문은 "누구에게 편지를 쓰고 싶나요?"입니다.
두 개의 클라이언트 소켓이 있다고 가정하면, 소켓_fd1에서 읽기(또는 recv()), 그리고 소켓_fd2에서 쓰기(또는 보내기())가 쉽습니다. 그렇게 간단합니다.
C에서는 클라이언트에 "응답"할 필요가 없습니다.
클라이언트(또는 다른 클라이언트)에 응답해야 하는지 여부는 구현하려는 프로토콜/애플리케이션에 따라 다릅니다.
더 많은 소켓이 열리면 유일한 질문은 "데이터가 어디로 가는가?"입니다.
모든 클라이언트 소켓에 동일한 데이터를 보낼 수도 있습니다. fd를 테이블/목록/무엇이든 저장하고 각 항목 "fd"에 대해 send(fd, buf, size, flags)를 호출합니다.
(채팅 서비스를 작성하려고 하셔서 받은 사람을 제외한 모든 사람에게 보내는 것 같네요 :)
보낼 사람을 선택하는 것이 더 복잡한 경우 각 고객에 대한 추가 정보가 포함된 구조화된 테이블을 사용하여 결정을 내리세요.
이것이 귀하의 문제를 해결하기를 바랍니다.
답변2
다음 사항을 충분히 구별하지 못할 수도 있습니다.
파일 설명자(fd) 및
소켓.
"networkfds"를 언급하셨습니다. NFS 파일이 어떤 경우에는 특별할 수 있는 것처럼 경계에 따라 다르다고 생각합니다. 파일이 아니고 NFS 파일입니다.
내가 아는 한 상태 저장 TCP 프로토콜로 인해 소켓이 fd를 폴링할 필요가 없기 때문에 이것이 중요합니다. (더 확실하다면 굵은 글씨로 표시하겠습니다.)
원시 UDP 소켓 쌍은 fd 쌍과 유사합니다. 연결이 준비되었지만 데이터 흐름을 구성하는 방법은 무엇입니까? "인터넷" 프로토콜 TCP의 편재성을 설명합니다(IP는 아래 계층에 불과하며 더 정적이고 중요합니다. Wikipedia를 참조하세요!).
그렇다면 당신의 디자인은 바보인가? 정의에 따르면, 약간 원시적입니다. TCP/IP와 비교. 파일 설명자는 IO 스트림의 단일 접촉 지점이며 소켓은 인터넷 시대의 고급 플러그입니다. 등은 connect
소켓에서만 작동합니다.
이것이 당신에게 이해가 됩니까? 나는 귀하의 질문을 절반 정도 따를 수 있으며 너무 멀지 않기를 바랍니다. 제발 말해줘.
답변3
알았어 친구들. 내 문제에 대해 결론을 내렸습니다. 상황에 따라 다릅니다.
응용 프로그램에 따라 다릅니다. 나는 공부했다epoll 전용/다중 스레드 전용/작업자 스레드가 있는 epoll에 대한 일부 벤치마크.
내 결론은 이것이 가장 의미가 있기 때문에 내 프로젝트에서 epoll 및 작업자 스레드를 사용할 것이라는 것입니다. epoll_wait
fd를 읽기/쓰기에 사용할 수 있을 때 가장 빠른 fd 검사기/선택기이지만 실제로는 작동합니다(데이터 디코딩/분석 및 처리). 동시에(즉, 스레드 사용)