HTTP POST Problem mit Chrome, Opera, Safari
-
Ja, Timeout müsste man noch irgendwie machen.
Dabei kann es leicht sein, dass die "schonendste" Methode die ist, alle paar zig Sekunden mal eine Liste mit allen Connections durchzuackern, und zu gucken welche man killen möchte.
Dann braucht man die Liste natürlich.Für Server die nicht mit tausenden gleichzeitigen Connections klarkommen müssen, wäre es aber sich auch vertretbar, wenn jede Connection ihren eigenen Timer hat.
Oder der Server könnte nen "Heartbeat" Timer haben, und diesen der Connection im Konstruktor mitgeben. Die Connection hängt sich dann in das "Tick" Signal (oder wie auch immer das heisst) dieses einen zentralen Timers. Die Liste verwaltet der Timer dann implizit (bzw. das Signal).
-
@sowiso:
Nochwas anderes...
Es ist allgemein viel einfacher, wenn man für jede Connection einen eigenen Thread macht. Weil man dann nämlich mit blocking IO arbeiten kann, und nicht für jede Kleinigkeit ne State-Machine basteln muss.Irgendwann skaliert das zwar nimmer gut, aber bis etliche hundert gleichzeitige Connections ist es kein Problem (Erfahrungswert).
Wie das mit Qt geht, müsstest vermutlich diesem Beispiel entnehmen können:
http://www.trinitydesktop.org/docs/qt4/network-threadedfortuneserver.htmlUnd noch ein Vorteil von "1 Thread pro Connection": man kann andere blockierende Aufrufe verwenden, ohne dass man dadurch gleich den gesamten Server ausbremst. Oft will man diverse Funktionen diverser anderer Libraries verwenden, wo es einfach keine asynchrone Alternative gibt. Mit einem "1 Thread für alle" Server bremst man sich damit den ganzen Server aus, wenn diese Funktionen mal blockieren. z.B. weil sie auch Disk-IO warten o.ä. Oder man muss diese Aufgaben in einen Thread-Pool auslagern, was zwar gut funktioniert (und dann auch nicht mehr bremst), dafür aber einiges an Aufwand darstellt.
Der Nachteil: man kann nicht mehr einfach so auf gemeinsam genutzten State zugreifen, da ja nun mehrere Threads parallel laufen. Man muss sich dann also selbst darum kümmern, die Zugriffe entsprechend zu synchronisieren.
Und vergiss meine Frage bezüglich deleteLater - hab mittlerweile gesehen dass das ne Qt Framework Funktion ist. Dafür andere Frage: wer löscht jetzt den QSslSocket? Hab ich das in deinem Code übersehen, oder hast du es vergessen? (Oder kümmert sich irgend ein automagischer Mechanismus des Qt Frameworks darum?)
Denn du rufst ja nur deleteLater() für die SSLServerConnection selbst auf, und in ~SSLServerConnection() löscht du den Socket ja nicht...
-
Die klasse QAbstractSocket erbt von QIODevice, und dort gibt es signals wie readyRead(), welches immer dann emited wird, wenn neue daten verfügbar sind. Sollte dann wohl ein leichtes sein, sich die zu holen.
-
Bleib mal auf dem Teppicb, bzw. im Keller!
-
KuhTee schrieb:
Die klasse QAbstractSocket erbt von QIODevice, und dort gibt es signals wie readyRead(), welches immer dann emited wird, wenn neue daten verfügbar sind. Sollte dann wohl ein leichtes sein, sich die zu holen.
Ja.... bloss warum sagst du uns das?
readyRead verwendet er doch schon längst.
Was irgendwie ein dezenter Hinweis darauf ist dass er es vielleicht kennen könnte.
Nur mal so.
-
Habs hinbekommen. Ich schaue wieviel Daten kommen müssten und wenn diese da sind mach ich weiter. Geht super! Danke für eure Tipps!
Jetzt hab ich nur noch das Problem, dass ich nicht weiß an welcher Stelle ich wieder Speicher freigebe. Kann ich einfach im Destruktor delete this; aufrufen oder ist es aufwendiger zu lösen?
Grüße
sowsio
-
Du willst im Destruktor "delete this;" machen? Öh. Überleg mal
Und wo du den Speicher freigibst, das hängt wohl davon ab wem er gehört.
Wobei ich einfach nen std::vector<char> irgendwo als Member reinpacken würde, dann musst du dir gar keinen Kopf machen wer was wann wo freigibt, weil es automatisch passiert.
-
Wie funktioniert denn das mit dem std::vector<char>
Grüße
sowiso
-
int main() { std::vector<char> buf(50000); // .resize() und .size() helfen socket.recv(&buf[0], buf.size()); // Die Elemente im Vektor liegen alle hintereinander im Speicher. } // Der Destruktor des Vektors gibt alles automatisch frei.Aber.. so etwas wusstest du noch nicht?
