Chat über Webservice - blockierende Aufrufe oder pollen?

*Q* 1

Hallo zusammen,

ich will einen ASP.NET-Webservice schreiben, der u.A. von einer Anwendung benutzt wird, um einen Chat zwischen verschiedenen benutzern anzubieten.
Jetzt könnte man einfach alle paar sekunden (z.B. mit einem Timer) gucken, ob neue Nachrichten da sind.
Das wird vermutlich auch funktionieren, hat aber 2 Nachteile: 1. Verzögerung, 2. mehr Kommunikation mit dem Server, als nötig.

Ich hab dann mal ein bischen was zu asynchronen Webservices gelesen.
Die Idee ist es einen Webservice asynchron aufzurufen. Der eigentliche Aufruf (der asynchron durchgeführt wird), blockiert dann beim server solange, bis neue Nachrichten da sind und kehrt erst dann zurück. Und falls zulange nichts kommt kann der aufruf auch timouten und dann z.B. null oder ähnliches zurückgeben.

Eigentlich hört sich das gut an und ist vermutlich auch nicht schwer zu implementieren (einfach ne wait condition benutzen).
Allerdings habe ich bedenken, das ich Probleme kriege, weil die Anzahl der Threads eines Webservices soweit ich weiß begrenzt ist.

Wenn ich jetzt für jeden Benutzer einen eigenen Thread starte, der solange blockiert, bis etwas neues da ist, dann könnte es ja passsieren, dass irgendwann keine neuen anfragen mehr angenommen werden, weil alle threads, die den webservice vom server aus bedienen vergeben sind. Ist das so, oder ist die Sorge unberechtigt?

Kennt ihr noch andere Alternativen?

KingKarl

hab zwar keinen account, aber ich glaube facebook pollt und wenn die das machen, kanns so schlecht nicht sein. bei den ewigen verbindungen bekommst auch ein problem mit deinem favicon... und eine seite die scheinbar ewig läd, ist auch nicht so toll!

*Q* 1

wie oft pollen ist sinnvoll? so alle 3-5 sekunden mal nachgucken, obs was neues gibt? oder ist das schon zuoft?

Edit: Zur seite die ewig läd: Der webservice soll (zumindest primär) von einer Desktop-Anwendung aus aufgerufen werden und nicht von einer webseite. Ändert aber wahrscheinlich auch nichts.

KingKarl

Q schrieb:

Ändert aber wahrscheinlich auch nichts.

doch schon, wenns keinen ladebalken gibt

keine ahnung welches intervall am besten ist. evtl. gehts auch über flash, da gehen sockets, oder zumindest sowas ähnliches.

@edit: also server->flash->js->html->js->flash->server->...

PRIEST

Facebook holt sich erst Daten wenn der Server sagt es sind neue verfügbar.

Nimm node.js und/oder websockets und lass die Finger von diesem *** MS-Kram...

dispy

Wenn das sowieso primär von Desktop-Anwendungen verwendet werden soll - was spricht dann dagegen, für jeden Client eine eigene Verbindung aufzubauen? (wie es IRC eben auch erfolgreich tut? )
Du solltest dann eben einen extra Server auf einem anderen Port verwenden und es nicht auf dem HTTP-Prozess laufen lassen.

Für Chat über Webseiten kannst du auch was Aktuelleres wie Websockets benutzen - sofern der Browser das dann eben unterstützt. Wobei viele Frameworks dann als Fallback die Poll-Variante anbieten.

MfG