공개 : 나는 Faye의 저자입니다.
- Faye에 관해서는 당신이 말한 모든 것이 사실입니다.
- Faye는 대부분의 Bayeux를 구현합니다. 지금 당장 빠진 유일한 것은 서비스 채널입니다.이 채널의 유용성에 대해서는 아직 확신하지 못했습니다. 특히 Faye는 다음 사항에 큰 영향을 미치는 Bayeux의 CometD 참조 구현과 호환되도록 설계되었습니다.
- 개념적으로 그렇습니다. Faye 는 Socket.IO를 사용할 있습니다. 실제로 이에 대한 몇 가지 장벽이 있습니다.
- Socket.IO에 어떤 종류의 서버 측 지원이 필요한지, Faye 클라이언트 (노드와 Ruby에는 서버 측 클라이언트가 있음)가 모든 Bayeux 서버 (및 Faye 모든 Bayeux 클라이언트에 대한 서버)는 거래를 방해 할 수 있습니다.
- Bayeux에는 서버와 클라이언트가 특정 전송 유형을 지원하는 특정 요구 사항이 있으며 사용할 유형을 협상하는 방법을 알려줍니다. 또한 사용 방법 (예 : XHR 요청의 Content-Type이 해당 콘텐츠 해석 방법에 미치는 영향)도 지정합니다.
- 일부 유형의 오류 처리의 경우 전송에 직접 액세스해야합니다 (예 : Node WebSocket dies) 후 클라이언트가 다시 연결될 때 메시지 재전송 .
- 이것이 잘못된 것이 있으면 저를 수정하십시오-이것은 Socket.IO 문서의 피상적 스캔을 기반으로합니다.
- Faye는 단지 pub / sub 일 뿐이며 약간 더 복잡한 프로토콜을 기반으로하며 다음과 같은 많은 기능이 내장되어 있습니다.
- 서버 측 및 클라이언트 측 확장
- 채널 경로에 대한 와일드 카드 패턴 일치
- 자동 재 연결 (예 : WebSocket이 죽거나 서버가 오프라인 상태가 될 때)
- 클라이언트는 모든 브라우저, 전화 및 Node 및 Ruby의 서버 측에서 작동합니다.
Faye는 Juggernaut에 비해 훨씬 더 복잡해 보입니다. Juggernaut가 더 많이 위임하기 때문입니다. 예를 들어 전송 협상을 Socket.IO에 위임하고 메시지 라우팅을 Redis에 위임합니다. 둘 다 좋은 결정이지만 Bayeux를 사용하기로 결정한 것은 내가 더 많은 일을해야한다는 것을 의미합니다.
디자인 철학과 관련하여 Faye의 최우선 목표는 웹을 사용할 수있는 모든 곳에서 작동해야하며 사용하기에 절대적으로 사소해야한다는 것입니다. 시작하기가 정말 간단하지는 않지만 확장 성은 매우 강력한 방법으로 사용자 정의 할 수 있음을 의미합니다. 예를 들어 인증 확장을 추가하여 서버-클라이언트 푸시 서비스로 전환 할 수 있습니다 (즉, 임의의 클라이언트가 푸시하는 것을 중지). .
서버 측에서 더 유연하게 만들기위한 작업도 진행 중입니다. 클러스터링 지원을 추가하고 핵심 pub-sub 엔진을 플러그 가능하게 만들어 Faye를 Redis 또는 AMQP와 같은 다른 pub-sub 시스템의 상태 비 저장 웹 프런트 엔드로 사용할 수 있도록하려고합니다.
도움이 되었기를 바랍니다.