채팅 클라이언트/게시물 다시로드하지 않고 페이지

Question

사용자가 그룹을 만든 다음 해당 그룹 내에서 채팅/게시 할 수있는 사이트를 만들려고합니다. 그러나 그룹 내에서 게시물/채팅을 만들 때 사용자가 해당 그룹 내의 새 게시물/채팅을 보려면 페이지를 다시로드하지 않아도됩니다. 내 질문에이 종결 :이 작업을 수행하는 방법에 대한 최선의 의견은 무엇입니까 (언어, 웹 서비스 등)?

PHP, SQL, HTML, CSS를 잘 알고 있으며 XML, Javascript, AJAX를 잘 알고 있지 않습니다. (코드를 읽고 작동하는 방법을 충분히 알고 있지만 숙련되지 않거나 확신이 없습니다. 그 (것)들 중 하나에 책을 읽을 필요가있을 것이라는 점을 나는 느낀다.

모든 입력은 중대하게 평가 될 것입니다.

Answer 1

웹은 클라이언트가 요청하고 서버가 자원으로 응답하는 일반적인 요청/응답 모델을 처리하는 훌륭한 작업을 수행합니다. 그러나 서버가 데이터를 요청하는 클라이언트없이 클라이언트에 데이터를 보내야하는 애플리케이션의 경우 여기에서 창의적으로 파악해야합니다.

실시간 웹 기반 응용 프로그램을 쉽게 사용할 수있는 몇 가지 방법이 있습니다.

폴링 :

폴링은 클라이언트가 주기적으로 업데이트를받을하기 위해 서버에 요청을 포함한다. 이 접근 방식에는 두 가지 주요 문제점이 있습니다. 첫째, 서버가 매우 오랫동안 푸시 할 데이터가 없을 수 있습니다. 따라서 많은 대역폭이 잠재적으로 업데이트를 위해 서버를 폴링하는 데 낭비됩니다. 둘째, 폴링 속도는 응용 프로그램의 실시간 표시 방식을 결정합니다. 빠른 폴링 속도로 업데이트가 빨리 표시되지만 대역폭이 낭비됩니다. 반대로 더 긴 간격으로 폴링을 사용하면 대역폭이 줄어들지 만 단점은 업데이트가 빠르게 나타나지 않는다는 것입니다.

일반적으로

이 2012

혜성/역 AJAX 년에 채팅 응용 프로그램에 사용하는 매우 가난한 솔루션입니다 :

혜성 성공적으로 사용 된 기술이다

지난 5 년 동안 요청/응답이라는 개념을 사용하고 실시간 효과를 시뮬레이션하기 위해 해킹을 사용했습니다. Comet의 일반적인 개념은 클라이언트가 서버에 요청을하고 서버가 연결을 무기한 열어 둔다는 것입니다. 서버는 클라이언트에 보낼 업데이트가있을 때까지 기다립니다. 업데이트가 준비되면 서버는 클라이언트에 요청을 보내는 서버를 시뮬레이트하는 응답을 보냅니다. 클라이언트가 응답을 받으면 새로운 연결을 열어 프로세스가 반복됩니다.

이 기술은 대기열이 다른 작업을 위해 확보되도록하는 Continuations와 결합 될 때 일부 플랫폼에서 20,000 개가 넘는 동시 연결로 확장되는 것으로 나타났습니다.

대역폭을 절약 할 수있을뿐만 아니라 응용 프로그램이 매우 실시간으로 느껴집니다.

WebSocket을이 :

WebSocket을은 WS를 사용하여, 혜성을 대체 HTML5에 도입되었다 : http 대신 // 프로토콜을. 그러나 이것은 아직 모든 브라우저 공급 업체에서 널리 채택되지 않았으므로 프로토콜 사양과 관련하여 논의가 진행될 수 있습니다. 그것은 혜성과 같은 많은 이점을 가지고 있습니다.

---

혜성에 대한 자세한 내용은 Comet and PHP 및 the challenges of Comet in PHP을 확인하십시오. 클라이언트 측 통합의 경우 the Dojo Cometd Library을 확인하십시오.

Answer 2

나는 AJAX가 이것을하는 가장 좋은 방법이라고 말했을 것이다. 또는 다시로드하는 iframe을 만듭니다.