QByteArray per TcpSocket verschicken

[Maxima]

... Es kommt häufiger vor, dass mehrere meiner Befehle dann letztendlich in einem Paket gesendet / empfangen werden ....

Deswegen konnte der ursprüngliche Ansatz von viper :

Code: Alles auswählen

 in >> receivedData;     

nicht funktionieren

[PeterLustig]

Wenn er es über einen DataStream über den Socket schickt, dann kann das "in >> receivedData;" sehr wohl funktionieren. Stichwort Serialisierung.

[Maxima]

Wenn er es über einen DataStream über den Socket schickt, dann kann das "in >> receivedData;" sehr wohl funktionieren. Stichwort Serialisierung.

Verstehe ich leider nicht, bitte erkläre das mal genauer.

[PeterLustig]

Wenn man einen QString hat, der "Hallo" enthält, und diesen über einen DataStream sendet, dann kommt auf der anderen Seite nicht "Hallo" an. Dort kommt ein QString an, der erst einmal Unicode ist (Qt ist ja Unicode, also 2 Byte pro Zeichen) und außerdem enthält er die Länge des Strings. Diese Information benutzt DataStream wieder um daraus einen QString zu konstruieren. Sendet man jetzt aber direkt "Hallo", und nicht den QString, dann kann DataStream daraus nicht einfach so einen QString konstruieren.

[Maxima]

Und das funktioniert auch für ein bytearray? Warum schicken wird dann überhaupt (quint32)mBlockSize vorneweg?

[Sephral]

Sendet man aber sehr schnell hintereinander serialisierte "Hallo"-QStrings, muss man auf der Empfängerseite darauf gefasst sein, dass man im Empfangspuffer mehrere QStrings liegen hat. Darum drehten sich die letzten paar Beiträge.

Oder wird das durch Qt etwa auch abgefangen?

[PeterLustig]

Sollte QDataStream::atEnd nicht true wiedergeben, wenn keine Daten mehr zu lesen da sind?

[Maxima]

Sollte QDataStream::atEnd nicht true wiedergeben, wenn keine Daten mehr zu lesen da sind?

Ich antworte mal so wie Du:

Könnte es nicht sein, daß trotz QDataStream::atEnd das Bytearray noch nicht komplett ist, weil der Rest mit dem nächsten Paket kommt?

[Maxima]

Oder wird das durch Qt etwa auch abgefangen?

[PeterLustig]

Sollte QDataStream::atEnd nicht true wiedergeben, wenn keine Daten mehr zu lesen da sind?

Ich antworte mal so wie Du:

Könnte es nicht sein, daß trotz QDataStream::atEnd das Bytearray noch nicht komplett ist, weil der Rest mit dem nächsten Paket kommt?

Pakete können halb ankommen?
Soweit ich weiß wird das doch durch den vierten Layer der Internetarchitektur verhindert: Gesicherte End-zu-End-Verbindung.

[upsala]

TCP/IP-Grundlagen

[PeterLustig]

Mein ich doch. Die Daten werden gebuffert bis das Paket komplett angekommen ist, und dann wird es an die Anwendungsschicht (Layer 5) übergeben. Kommen daten halb an, werden sie automatisch neu angefordert. Können die Daten nicht komplett empfangen werden, wird auch nichts an die Anwendungsschicht übergeben.

[Sephral]

Maxima spricht nicht von TCP/IP-Paketen (hier habe auch ich mich wohl etwas ungenau ausgedrückt). Es geht einfach darum dass sich auf Empfängerseite bis zur Verarbeitung der empfangenen Daten im Puffer bereits mehrere QByteArrays / QStrings oder was auch immer angesammelt haben können.

Um wieder zum Thema zu kommen:
Die Verarbeitungsroutine darf nicht davon ausgehen, dass sich im Puffer lediglich ein Datenobjekt befindet, sondern muss dazu in der Lage sein auch mehrere Informationen aus dem Puffer auszulesen.

Um mehr (bzw weniger) geht es hier nicht
So erklärt sich dann auch die Beobachtung des Threaderstellers, dass er 1000 Daten abgeschickt hat, aber nur 713 "Pakete" empfangen hat.

[PeterLustig]

Dazu nannte ich ja QDataStream::atEnd. Das mit dem TCP/IP kam dazu zustande, weil Maxima fragte ob ob das nicht auch true wiedergibt, wenn das Paket noch nicht komplett angekommen ist.

[Maxima]

Dazu nannte ich ja QDataStream::atEnd. Das mit dem TCP/IP kam dazu zustande, weil Maxima fragte ob ob das nicht auch true wiedergibt, wenn das Paket noch nicht komplett angekommen ist.

Habe ich so nicht gesagt:

Könnte es nicht sein, daß trotz QDataStream::atEnd das Bytearray noch nicht komplett ist, weil der Rest mit dem nächsten Paket kommt?