2009-08-26 10 views
5

Ich mache eine Chat-Anwendung, die mit langem Polling funktioniert, um einen "Push" von Server zu Client zu emulieren.Was ist ein sicherer Zeitraum, den ich warten kann, bevor ich auf einen Browser antworte, ohne ein Timeout zu bekommen?

Grundsätzlich fragt der Browser nach Updates, und ich antworte, wenn es etwas Neues gibt. Ansonsten halte ich die Verbindung offen, ohne zu antworten, bis etwas zurückgeschickt wird.

Jetzt, wenn 30 Sekunden vergangen sind und ich nichts gesendet habe, dann sende ich eine Antwort, im Grunde gesagt "NoNews", und der Client wird erneut abfragen.

Was ich tun möchte, ist natürlich diese Verbindung zu halten, ohne so lange wie möglich zu antworten, bevor der Browser einfach Timeout und geben Sie mich auf ... Ich habe keine gute Dokumentation über die Client Timeout gefunden ist für jeden Browser, und es scheint nicht, dass es für alle von ihnen das gleiche ist ...

Hat jemand von Ihnen eine lange Polling-Anwendung gemacht?
Irgendwelche Ideen, was die längste sichere Zeitüberschreitung sein könnte?

Danke!

Antwort

2

Der Browser sollte eine Zeitüberschreitung auf einem XHR erkennen und eine andere Anfrage stellen.

Update:

Erkennen von Timeouts auf einer XHR ist tatsächlich kompliziert, da es nicht eingebaute in ist aus irgendeinem Grund. Natürlich müssen Sie auch 502/503 Antworten zu handhaben, etc ..

+0

Interessant, wie kann ich das tun? Kann der Server dies auch erkennen? (ASP.Net 2.0) Ich weiß, dass ich technisch überprüfen kann, ob der Client noch verbunden ist, aber ist das 100% genau? Meine Sorge ist diese Race-Bedingung: Der Client wird Timeout, eine Nachricht wird für den Benutzer ankommen, der Server wird es an die Verbindung senden es hat einen Griff zu, die Nachricht geht nirgends, weil es im Client abgelaufen ist, die Bei einer neuen Anfrage des Clients wird eine leere Nachrichtenwarteschlange angezeigt, und die Nachricht ist verloren ... –

+0

Auf der Serverseite verursacht eine zeitüberschreitende Verbindung einen Fehler, wenn Sie versuchen, in den Socket zu schreiben. Wie Sie das erkennen, hängt von der serverseitigen Technologie ab, die Sie verwenden, und ASP.Net ist mir nicht sehr vertraut. Wahrscheinlich wird der Response.Write (oder was immer es jetzt ist) eine Art von Fehler erzeugen. Client-Seite, müssen Sie etwas mehr Arbeit zu tun, habe ich meine Antwort mit einigen Links aktualisiert, die Sie hilfreich finden können. –

+0

Sie können veranlassen, dass der Client eine ACK sendet, wenn er eine Nachricht erhält. Wenn Sie also eine Nachricht zurücksenden und keine Bestätigung erhalten, lassen Sie sie in der Warteschlange, bis sie sich wieder verbindet. – kibibu

1

Die Lese-Timeout zwischen den Browsern variiert. Zum Beispiel sind dies Standardwerte für IE,

Internet Explorer 4.0 and Internet Explorer 4.01 - 5 minutes 
Internet Explorer 5.x and Internet Explorer 6.x - 60 minutes 
Internet Explorer 7 and Internet Explorer 8 - 60 minutes 

Wie Sie sehen können, wird es größere Überstunden.

In langen Polling ist Timeout Ihr Freund. Sie sollten es ausnutzen, anstatt es zu vermeiden. Timeout bedeutet, dass Sie LONGEST Polling mit dem Browser möglich machen. Timeout ist ein Fehler, den Sie auch ohne langes Polling verarbeiten müssen, so dass keine zusätzliche Belastung entsteht.

Sie mögen vielleicht auch meine Antwort auf diese Frage,

polling a HTTP server from J2ME client

Auch wenn es für einen mobilen Client, die meisten Regeln gelten für AJAX langen Polling lesen. Insbesondere denke ich, dass Sie von einem Benachrichtigungssystem profitieren werden, da die Abfrage nur für die Ereignisbenachrichtigung verwendet wird und alle Inhalte weiterhin normal abgerufen werden.

+0

Danke für die Antwort, das ist sehr interessant ... Wo haben Sie gefunden diese Timeout-Werte für IE? Ich konnte nichts dergleichen finden ... Wenn das in der Tat wahr ist, dann würde meine Anwendung nicht richtig in IE 7/8 arbeiten, da meine aktuelle typische Wartezeit 30 Sekunden + ein wenig Overhead ist ... –

+0

Siehe http://support.microsoft.com/kb/181050 –

+1

+1, 30s ist, wo Sie beginnen, in Schwierigkeiten zu laufen. Auch Opera trifft hier Grenzen. Wir verwenden 25s in WebSync, um mögliche geringfügige Unterschiede zu vermeiden. – jvenema