Zasada działania chatu.

Tak jak w temacie. Czy mógłby mi ktoś wytłumaczyć ogólną zasadę działania chatu ? W internecie znalazłem wiele przeróżnych implementacji, aczkolwiek nigdzie nikt nie wytłumaczył na jakiej zasadzie taki chat ma działać.

Chodzi mi o coś mniej więcej "Wiadomości zapisujesz do pliku, strona pobiera tekst z pliku, wyświetla w ramce i odświeża się co sekundę". Wiem, że takie rozwiązanie jest zbyt łopatologiczne i po prostu złe (takie znalazłem w przykładowych skryptach tutaj ;) ), ale chodzi mi o takie wyjaśnienie. Spodziewam się, że rozwiązania tego problemu jest więcej niż jedno, ale im więcej pomysłów tym lepiej.

Ponadto, pytanie w czym najlepiej taki chat pisać ? PHP z tego co wyczytałem nie jest idealnym rozwiązaniem, aczkolwiek da się zrobić. Prosiłbym o sugestie.

Pozdrawiam

Moje rozwiązanie:

Tworzysz główny skrypt który ładuje cały czat i dodatkowy skrypt (dajmy na to) ajax.php który będzie dynamicznie serwował nowe wypowiedzi i obsługiwał wysyłanie ich.

Główny skrypt ładuje cały HTML, kontener do wypowiedzi i skrypty. Potem co kilka sekund wysyłasz dynamiczne zapytanie AJAXem (google:XMLHttpRequest) pod adres:
ajax.php?lastid=-1
Parametr lastid to ostatni znany numer ID wypowiedzi, albo -1 jeśli jeszcze go nie znamy. Skrypt ajax.php wykonuje zapytanie do bazy danych o wybranie rekordów z ID większym niż "lastid" (czyli wypowiedzi które już znamy zostaną pominięte) zwraca nam dane w formacie JSON, np.:
{"status": "NothingNew"}
Jeśli nie ma nowych wypowiedzi, albo:

{"status": "New",
"messages": [
   {"user": "Demonical Monk", "text": "Witaj."},
   {"user": "Test", "text": "WTF"}
],
"lastid": "35"
}

Jeśli z bazy wyciągnęliśmy 2 nowe wypowiedzi, z czego ostatnia ma ID równe 35. Później XHRem pytamy adres:
ajax.php?lastid=35
Potem znowu zwiększamy lastid wraz z nowymi wypowiedziami. W przypadku kiedy user chce dodać wypowiedź, po prostu XHRem wysyłamy zmienną z jego nickiem i tekstem metodą POST, żeby się dynamicznie dodało.

w php czatu nie stworzysz, co najwyżej shoutbox.

Keraj: jak to mawiał mój nauczyciel fizyki, głupoty opowiadasz ;) Bo i da się stworzyć czat, i sam shoutbox można nazwać czatem ( w końcu też umożliwia rozmowy z ludźmi ).

Jak najbardziej się da, Keraju, stworzyć pełnoprawny czat. No chyba że chciałeś powiedzieć "w samym PHP". To jednak byłoby debilne założenie, bo praktycznie nigdy nie pisze się witryn www czy aplikacji w samym PHP -- zawsze jest jeszcze HTML i powinien być CSS. No to dorzuć do tego JavaScript wraz z Ajaxem (obiektem XMLHttpRequest) i możesz zrobić pełnoprawny czat mając PHP po stronie serwera.

Zasadę działania dobrze wyjaśnił @Demonical Monk. Metoda, którą opisał, to tzw. polling. Nie jest to jedyna metoda. Jest jeszcze np. long polling, a ostatnio małą furorę robią web sockety (nie wspierane jeszcze przez wszystkie przeglądarki). Metody różnią się od siebie wydajnością, no i implementacją. Zainteresowani mogą sobie o nich pogooglać. Na początek polecałbym zwykły polling. Tym bardziej, że dla niewielkich rozwiązań powinien w zupełności wystarczyć.

dodam zeby ogolnie zainteresowac sie takim pojeciem jak "comet", do ktorego zalicza sie wlasnie "long polling" jak i technike "http streaming".

Dla javy mozna sobie obejrzec:

• Atmosphere ( https://atmosphere.dev.java.net/ )
• Grizzly ( https://grizzly.dev.java.net/ )
• Servlet 3.0 bo wspiera asynchroniczna komunikacje

• ice faces (long polling jest automatycznie obslugiwany)

• natywne API poszczegolnych web serwerow (np. Jetty - od wersji 7 obsluga tez websocketow)

bswierczynski napisał(a)

Jak najbardziej się da, Keraju, stworzyć pełnoprawny czat.
Jak dla mnie "czat", który non stop wysyła requesty, żeby sprawdzić czy ktoś coś nowego nie napisał, nie jest "pełnoprawny" i zawala niepotrzebnie transfer, a stosunek nagłówków do faktycznych wiadomości jest jak 100(ablo i więcej) do 1.

@keraj:
To możesz zastosować long-polling, co zminimalizuję liczbę żądań. Albo np. te web-sockety, które są już jak najbardziej sprawne. Nagłówki też możesz ograniczyć do minimum.

To takich rzeczy to jest Java (ta od Oracle btw)

@GhostDog:
Wiesz, mnie się wydaje, że Web Sockety sprawią, że czat javascriptowy będzie dobrym, rozsądnym rozwiązaniem. Podoba mi się poleganie na Standardach i natywna obsługa tak skomplikowanego kodu przez przeglądarkę. Silniki JavaScript także są coraz szybsze. Problemem jest obecnie sama komunikacja, a web sockety ten problem rozwiążą. Zresztą, nawet teraz w mniejszych projektach można spokojnie używać (long) pollingu.

Czy przypadkiem Campfire od 37signals nie jest oparty o zwykły JavaScript, bez Javy itp.? To całkiem duży, oblegany projekt. I działa na zasadzie chatu, w dodatku sprawnie i szybko.

Campfire chodzi na Ruby on Rails. Prototype jest prawdopodobnie uzyty po stronie clienta. Z jakiegos postu z 2006 roku wynikalo jeszcze ze Campfire uzywa zwyklego pollingu, zapewne sie to zmienilo skoro dziala to niby w "real time"
Wiekszosc przegladarek nie obsluguje websocketow, i nie jest to na razie rozsadne rozwiazanie a raczej alternatywa np. do long pollingu.

@bswierczynski nie wiem co ty się tak do strony clienta przyczepiłeś, skoro nikt ci w ogóle nie zaprzecza... ja tylko się przyczepiłem do demonicala, że php po stronie serwera czegoś takiego nie zapewni... no, chyba że znasz jakiś sposób na long polling przy użyciu php.

to akurat chyba nie trudno znalezc w sieci, chociazby http://www.zeitoun.net/articles/comet_and_php/start
w najgorszym wypadku mozna samemu zaimplementowac

bswierczynski napisał(a)

Wiesz, mnie się wydaje, że Web Sockety sprawią, że czat javascriptowy będzie dobrym, rozsądnym rozwiązaniem. Podoba mi się poleganie na Standardach i natywna obsługa tak skomplikowanego kodu przez przeglądarkę. Silniki JavaScript także są coraz szybsze. Problemem jest obecnie sama komunikacja, a web sockety ten problem rozwiążą. Zresztą, nawet teraz w mniejszych projektach można spokojnie używać (long) pollingu.

Jeśli PHP+JS wymaga mniej klepania to jest to argument. Jednak myślę, że lepiej napisać wszystko w jednym języku i że czat na Java będzie i tak wydajniejszy.

Jak dla mnie miejsce języków skryptowych jest tylko po stronie przeglądarki.

Niestety popularność PHP sprawia, że w większości jesteśmy na nie skazani.

mwili napisał(a)

to akurat chyba nie trudno znalezc w sieci, chociazby http://www.zeitoun.net/articles/comet_and_php/start
w najgorszym wypadku mozna samemu zaimplementowac
"Do an infinite loop as long as "data.txt" file is unchanged"
Cóż za optymalne rozwiązanie...

to skorzystaj z javy. linki i rozwiazania podalem wyzej. Nie chodzilo o to czy jest to optymalne, tylko czy mozliwe. Jak bys ty to rozwiazal powiedz? Chodzi mi o wstrzymanie repsonse do momentu az jakis event nadejdzie, ktory trzeba wyslac do klienta??
W javie jak bys pisal to sam, to bys musial podobnie zrobic- uzyc petli moze jakis klas z pakietu java.util.concurrent

mwili napisał(a)

to skorzystaj z javy. linki i rozwiazania podalem wyzej. Nie chodzilo o to czy jest to optymalne, tylko czy mozliwe. Jak bys ty to rozwiazal powiedz?
Po stronie serwera z Javy bym korzystał...
Mając własnego dedyka, mogę postawić własny soft i zaimplementować long polling to w czym sobie chcę... więc po co miałbym w php.
Nie mając własnego dedyka, a korzystając z usługi www na jakimś hostingu, admin wywaliłby mnie na zbity pysk za zapychanie całego serwera jednym głupim czatem w php. (poza tym na takich hostingach zazwyczaj są ustawione limity czasu wykonywania skryptów)

LongPolling blokuje thread do momentu az:

• nastapi timeout (np. 30 sekund)
• zostanie wczesniej wyslany event do klienta

Uzywajac javy uzyje sie raczej non-blocking I/O za pomoca np. servletu 3.0 albo athmospere, chociaz przy niektorych webserverach jest to nie mozliwe i zostana uzyte blokujace I/O.
W takim przpadku nawet HTTPStreaming nie bedzie ciagle blokowal watku.