OnSite InstantMessenger

[prego]

Heyho

Ich plane gerade eine Instant Messaging Funktion für eine Comunity Seite. Nun gäbe es ja verschiedene Ansätze das zu realiseren. Mein Gedanke bisher wäre folgender:

- User ist eingeloogt
- Per XMLHTTPRequest wird in einem Interval eine Schnittstelle aufgerufen, die zurück gibt ob eine InstantMessage vorliegt
- Wenn eine Nachricht vorligt wird ein DIV angezeigt das die Nachricht enthält inkl der Möglichkeit zu antworten.
- Nachrichten werden per XMLHTTPRequest an den Server geschickt und dort in einer Tabelle zwischengespeichert, bis sie abgeholt werden.

Funktional denke ich ist das ok so. Das einzige was mir nicht ganz passt ist, das ja dann jeder Client alle (zb) 10 Sekunden einen Request an den Webserver absetzt. Ist das verkraftbar?

Bzw. welche Möglichkeiten gäbe es noch solch ein Vorhaben zu lösen?

Danke für eure Ideen.

[Happy Nihilist]

Re: OnSite InstantMessenger

Original geschrieben von prego
Heyho

Ich plane gerade eine Instant Messaging Funktion für eine Comunity Seite. Nun gäbe es ja verschiedene Ansätze das zu realiseren. Mein Gedanke bisher wäre folgender:

- User ist eingeloogt
- Per XMLHTTPRequest wird in einem Interval eine Schnittstelle aufgerufen, die zurück gibt ob eine InstantMessage vorliegt
- Wenn eine Nachricht vorligt wird ein DIV angezeigt das die Nachricht enthält inkl der Möglichkeit zu antworten.
- Nachrichten werden per XMLHTTPRequest an den Server geschickt und dort in einer Tabelle zwischengespeichert, bis sie abgeholt werden.

Funktional denke ich ist das ok so. Das einzige was mir nicht ganz passt ist, das ja dann jeder Client alle (zb) 10 Sekunden einen Request an den Webserver absetzt. Ist das verkraftbar?

Bzw. welche Möglichkeiten gäbe es noch solch ein Vorhaben zu lösen?

Danke für eure Ideen.

Inwieweit das performant ist, kann ich nicht sagen. Ich weiß nicht wieviele Benutzer du erwartest und selbst wenn, wie hoch die Grenze dafür ausfallen könnte.

Was mir allerdings aufgefallen ist, dass es Probleme damit geben könnte, wenn du die Nachrichten nach dem ausliefern direkt wieder aus der Datenbank löschst (was ich aus dem "zwischenspeichern" entnehme). Bedenke, dass ein Rechner/Browser immer abstürzen kann und man so die Nachrichten evtl. nicht immer lesen kann, obwohl sie ausgeliefert wurden.

[prego]

Last: Es ist davon auszugehen das hundert oder mehr Leute gleichzeitig auf der Seite sind.

Zwischenpeicher: Ist richtig. Ausserdem nehm ich mir damit die Möglichkeit einer MessageHistory

Danke.

[Happy Nihilist]

100 Benutzer sind ja nicht wirklich besonders viel, da muss man wohl keinen großen Wert auf die Performanz legen.

Eine kleine Idee, die mir eben noch gekommen ist: Du könntest den "Refresh-Wert" ja dynamisch bestimmen. Führt der Benutzer keinen Dialog, liegt er bei 15 Sekunden. Ist er in einem Gespräch, liegt er bei 10 Sekunden und verringert sich mit jedem weiteren Gespräch um eine weitere Sekunde auf maximal 5 Sekunden. So vermeidest du zumindest einen Teil des Overheads und dem Benutzer scheint dein System flotter.

[wahsaga]

Re: Re: OnSite InstantMessenger

Original geschrieben von Happy Nihilist
Was mir allerdings aufgefallen ist, dass es Probleme damit geben könnte, wenn du die Nachrichten nach dem ausliefern direkt wieder aus der Datenbank löschst (was ich aus dem "zwischenspeichern" entnehme). Bedenke, dass ein Rechner/Browser immer abstürzen kann und man so die Nachrichten evtl. nicht immer lesen kann, obwohl sie ausgeliefert wurden.

Da kann man den Client ja auch noch mal eine Rückmeldung geben lassen - "Nachricht wurde empfangen und angezeigt".

Wird AFAIK beim simsen ja auch ähnlich gemacht - SMS wird an Handy zugestellt, Handy gibt Rückmeldung, "ja, ist (fehlerfrei) angekommen", System weiß jetzt, diese Meldung ist zugestellt, es braucht kein weiterer Versuch unternommen zu werden.


Evtl. würde ich noch über eine Beschränkung ungelesener Nachrichten nachdenken - kaum jemand möchte, nach dem er aus seinem zweiwöchigen Urlaub zurückkommt, erst mal mit 1537 Messages zugeschüttet werden ...

[prego]

Die Sache soll ja sowieso nur funktionieren wenn der User online ist. Eine Speicherung der Nachrichten soll in diesem Sinne nicht stattfinden. Ich muss also auch schauen, ob ich wirklich ne history mache oder nicht.

Mit den hundert hab ich eben vielleicht ein bischen zu niedrig gegriffen - es können durchaus mehr werden. Ich will halt nicht jeden einfach alle 10Seks nen Request machen lassen, weis nicht was die apaches dazu sagen.

Ansonsten, wenn ihr noch irgendwelche Einfälle habt - her damit

Danke.

[Happy Nihilist]

Re: Re: Re: OnSite InstantMessenger

Original geschrieben von wahsaga
Da kann man den Client ja auch noch mal eine Rückmeldung geben lassen - "Nachricht wurde empfangen und angezeigt".

Wird AFAIK beim simsen ja auch ähnlich gemacht - SMS wird an Handy zugestellt, Handy gibt Rückmeldung, "ja, ist (fehlerfrei) angekommen", System weiß jetzt, diese Meldung ist zugestellt, es braucht kein weiterer Versuch unternommen zu werden.


Evtl. würde ich noch über eine Beschränkung ungelesener Nachrichten nachdenken - kaum jemand möchte, nach dem er aus seinem zweiwöchigen Urlaub zurückkommt, erst mal mit 1537 Messages zugeschüttet werden ...

Ich denke da einfach an ein Problem, dass ich vor kurzem mit eingebetteten Videos in Webseiten hatte. Mein Rechner hat nicht mehr auf Maus oder Tastatureingaben reagiert, sehr wohl aber auf Pings, Page Reloads und ich nehme an, dass er auch Javascript weiter ausgeführt hätte. Nachrichten, die aber angekommen wäre, während ich irgendwie auf so einer Seite gekommen bin, wären vom Browser als "empfangen" abgesegnet worden. Ich komme aber nicht um einen neustart herum und seh nix mehr.

Anyway, eine begrenzung der zu speichernden Nachrichten ist natürlich trotzdem sinnvoll.

Edit: Nochmal zur Benutzerperformanz. Alle 10 Sekunden einen Request absetzen ist wohl besser als die Verbindung offen zu lassen und zu streamen. So wird der Overhead noch größer. Und AFAIK wäre das die einzig andere Möglichkeit (ich nehme jetzt mal an, dass du auf Java-Applikationen oder sonstigen Plug-In Hokuspokus verzichten willst).

[highrise]

die geschichte mit der dynamischen refresh-rate gefällt mir...

das hätte ruhig mal einem früher einfallen können ;-)
however...

im http gehts tatsächlich nur mit regelmässigen requests oder mit ner persitent connection (streaming). ersteres halte ich für die bessere lösung, weil letzteres doch den server zielmich in die knie zwingen kann und bei manchen anbietern schon von vorneherein aus ist. (means, der apche macht die verbindung zu, auch wenn er angewiesen wird, diese zu halten.

however... wenn du wirklich viel traffic erwartest, dann solltest du mal über eine lösung mit einem anderen protokoll nachdenken.

auf der teuren seite gäbs da den flash-mediaserver (oder wie die kiste heißt), auf der preiswerten, aber durchaus brauchbaren seite fällt mir spontan Jabber ein, was auch server PUSHs kann und inzwischen ausgereift und offiziell ist. Das allerdings nicht ohne applets.

so do what ya like....

greetz, high

[prego]

Hey,

danke nochmal für deine Antwort - es ist schon implementiert. XMLHTTPRequest Request alle 5 Seks - die dynamische Request Zeit hab ich jetzt noch nicht drin. Folgt aber.


Wer schauen will: http://www.studylounge.de - man muss sich allerdings anmelden.