이제 전체 서버에 socketio를 구현하지 않고 채팅하고 싶습니다.
아니요, 그렇게 할 수 없습니다. 귀하의 웹 서버 중 하나가 귀하의 채팅 서버에 연결을 시도 할 수있을 때 귀하의 서버는 사실상 전혀 모릅니다. 항상 듣고 있어야합니다.
또한 연결이없는 수신 서버가 아무 것도하지 않고 비용도 들지 않기 때문에 들어오는 socket.io 연결을 수신하는 것이 무엇을 의미하는지 오해 한 것 같습니다. 그래서, "항상 뛰는"것은 아무것도 의미하지 않습니다. 사실, 서버를 시작하고, 서버를 중지하고, 나중에 다시 시작하는 등의 비용이 더 많이 듭니다. 게다가 "전체 서버에 socketio를 구현할 필요없이"당신의 말을 듣는 것은 socket.io 서버를 청취하는 것과 관련하여 무언가가 있다고 생각하는 것처럼 들립니다. 이것은 전혀 중량감이없는 개념입니다.
게다가, 모든 시간을 듣고있는 socket.io 서버는 전혀 단점도 없습니다. 이전에 설정된 쿠키를 통해 또는 다른 인증 방법을 사용하여 들어오는 socket.io 연결을 인증하려는 경우 인증 된 사용자 만 연결할 수 있도록 인증을 구현할 수 있습니다.
저는 waitChat 및 getChat에 대해 이야기하는 내용을 따르지 않습니다. 채팅의 배경은 userA가 userB에게 배달 될 메시지를 보낼 수 있다는 것입니다. 어떻게 작동하는지에 대한 개념은 userA가 서버에 메시지를 보내고 서버가 userB에게 메시지를 전달한다는 것입니다.
분명히 userA가 서버에 메시지를 보내는 것이 쉽습니다. 그것은 여러 가지 방법으로 수행 될 수 있습니다. 문제는 서버가 userB에 메시지를 전달하는 방법입니다. 아시다시피 서버는 userB에 직접 연결할 수 없습니다. 이 작업을 수행하는 방법은 다음과 같습니다
- 하여 B가 정기적으로 폴링 서버가 새로운 무언가를 요구
- 하여 B는 폴링 "긴 폴링"하지만, 서버가 잠시 폴링 요청에 보유하고 전문화 된 버전을 사용합니다 그런 다음 데이터가 있거나 시간이 초과 된 후 클라이언트가 다시 폴링해야 할 때 반환합니다.
- userB는 서버에 지속적인 webSocket 또는 socket.io 연결을 만든 다음 서버가 해당 연결을 통해 클라이언트에 데이터를 보낼 수 있습니다. 언제든지.
웹 소켓 또는 소켓.io 연결은 훨씬 효율적이며 실제로 두 가지 폴링 방식이 매우 효율적이거나 확장 가능하지 않기 때문에 전체 개념이 개발되어 브라우저에 추가되었습니다.
기본적으로 연결된 클라이언트에 메시지를 "푸시/브로드 캐스트"하는 "무언가"가 필요한 것보다 클라이언트와 서버 간의 연결이 필요합니다. "무언가"는 클라이언트와 서버 사이의 활성 연결 인 "소켓"입니다. 두 번째 부분에서 말한 내용은 기본적으로 "소켓"구현입니다.이 프레임 워크는 이미 'socket.io'라는 프레임 워크를 가지고 있으므로 사용하십시오. – Vishrant
괜찮 았어. 그래서 socketio를 socketio로 사용할 것이지만, socketio로 연결할 때 어떻게 사용자 이름을 얻을 수 있을까? 이 문제는 socketio가 마음에 들지 않지만 현재의 빠른 설치를 결합하는 방법을 모르며 모든 소켓 연결에 대해 – anduyang
에 할당 된 ID가 있으며 어떤 사용자를 관리해야합니까? 어떤 ID를 사용하여 연결되어 있습니다. 거기에 사용할 수있는 많은 예제, 구글 채팅 예를 소켓 io와 표현에 있습니다. – Vishrant