Hallo,
wenn man sich über SslSocket mit einem Server verbindet und große Antworten(Rückgesendete Daten) erhält, sind die auf eine bestimmte Größe beschränkt.
Also nehmen wir an, die Antwort ist 10000 Bytes groß und ich rufe waitForReadyRead und readAll() auf, dann sind aber nur eine bestimmte Anzahl an Bytes da.
Sagen wir z.b. 1448. Also muss man das nochmal aufrufen, solange bis der Timeout der waitForReadyRead abgelaufen ist, um alle Daten zu lesen.
Ist das eine EIgenschaft von Qt oder senden die Server das wirklich in so kleine Happen? Weil eigentlich würde die ReadBufferSize für alle 10000 Byte langen.
Was wäre da eine angemessene Timeout-zeit, wenn das eine Serversache ist? Momentan hab ich 100ms.
QSslSocket Lesezeit
Re: QSslSocket Lesezeit
Nein, die Server können das ganze in sehr großen Blöcken senden, nur auf dem Weg zum Empfänger passiert etwas, was zum Thema Netzwerkgrundlagen gehört und z.B. in der Wikipedia nachgelesen werden kann. Und 100ms Netzwerk-Timeout ist überhaupt nichts, normalweise hat man im Netzwerk Timeouts von 30 Sekunden.
Re: QSslSocket Lesezeit
ok, aber 30sekunden ist doch vollkommen übertrieben.
Wie willst du da feststellen, dass du alles erhalten hast?
Da wartest du ja am Ende jedes mal 30 Sekunden.
Wie willst du da feststellen, dass du alles erhalten hast?
Da wartest du ja am Ende jedes mal 30 Sekunden.
Re: QSslSocket Lesezeit
1. Ich hoffe nicht dass Du versuchst die Daten selber zu entschluesseln, das erledig ja Qssl Socket fuer dich 
DU kannst nicht einfach Daten unkoordiniert ueber TCP schicken. TCP garantiert dir nur:
- Das alle Daten ankommen (wenn nicht, gibts nen TCP Error)
- das deine Daten in richtiger Reihenfolge kommen
- Das Daten innerhalb eines WarteZyklyses versendet werden (Normal was um 100 ms) und dementsprechend auch ankommen werden.
TCP garantiert nicht:
- das deine "Packetgroessen " gleich bleiben
- das die Intervalle in denen Du daten versendest, auch eingehalten werden.
TCP kann daten sammeln, und sie zu Packeten geeigneter groesse zusammenfassen.
TCP kann nachrichten bis zu einer bestimmten Spanne verzögern, um auf nachfolgende Nachrichten und damit groessere / Optimalere Packete zu kommen. Diese SPanne liegt üblicher weisse im bereich von 100ms, kann aber abgepasst werden. 30sek sind wirklich nen timeout, wenn deine Verbindung abbreisst.
Das heisst du brauchst nen eigenes Flussprotokoll ....
DU musst also entweder die Laenge übermitteln ....
oder es muss eindeutig im Datenstrom erkennbar sein, das dein "Block" zu Ende ist (Termination).
Meist wird eine Kombination aus beidem eingesetzt.
Es wird ein Header geschickt, der terminiert ist, dannach kommt der Datenstrom.
Die meisten Protokolle bei TCP sind Textbasiert ...
Die termination ist üblicher weisse der Zeilenumbrauch
udn Binardaten werden dann base64 codiert uebertragen ...
macht nur pi * Daumen nen Overhad von 1/4 aus , bei dir kaem der verschluesselungsaufwand noch hinzu.
Dafuer erhalt man ein stabiles und durch "mithoeren" leicht debugbares Protokoll
(meist entwickelt man soweiso erst ohne SSL, und erweitert dann um SSL wenn das eigentliche Protokoll stabil ist).
Ciao ...
Auf timeout warten iss IMHO immer der letzte Weg.Also muss man das nochmal aufrufen, solange bis der Timeout der waitForReadyRead abgelaufen ist, um alle Daten zu lesen.
DU kannst nicht einfach Daten unkoordiniert ueber TCP schicken. TCP garantiert dir nur:
- Das alle Daten ankommen (wenn nicht, gibts nen TCP Error)
- das deine Daten in richtiger Reihenfolge kommen
- Das Daten innerhalb eines WarteZyklyses versendet werden (Normal was um 100 ms) und dementsprechend auch ankommen werden.
TCP garantiert nicht:
- das deine "Packetgroessen " gleich bleiben
- das die Intervalle in denen Du daten versendest, auch eingehalten werden.
TCP kann daten sammeln, und sie zu Packeten geeigneter groesse zusammenfassen.
TCP kann nachrichten bis zu einer bestimmten Spanne verzögern, um auf nachfolgende Nachrichten und damit groessere / Optimalere Packete zu kommen. Diese SPanne liegt üblicher weisse im bereich von 100ms, kann aber abgepasst werden. 30sek sind wirklich nen timeout, wenn deine Verbindung abbreisst.
Das heisst du brauchst nen eigenes Flussprotokoll ....
DU musst also entweder die Laenge übermitteln ....
oder es muss eindeutig im Datenstrom erkennbar sein, das dein "Block" zu Ende ist (Termination).
Meist wird eine Kombination aus beidem eingesetzt.
Es wird ein Header geschickt, der terminiert ist, dannach kommt der Datenstrom.
Die meisten Protokolle bei TCP sind Textbasiert ...
Die termination ist üblicher weisse der Zeilenumbrauch
udn Binardaten werden dann base64 codiert uebertragen ...
macht nur pi * Daumen nen Overhad von 1/4 aus , bei dir kaem der verschluesselungsaufwand noch hinzu.
Dafuer erhalt man ein stabiles und durch "mithoeren" leicht debugbares Protokoll
(meist entwickelt man soweiso erst ohne SSL, und erweitert dann um SSL wenn das eigentliche Protokoll stabil ist).
Ciao ...