Eigenes Protokoll - Prinzipieller Aufbau

[Furtbichler]

Zitat von himitsu:

...
z.B.
- vor alle Daten ein Startcode ...
- dann die Länge des ganzen Blocks
- den Namen/die Kennung des Blocks (mit Längenangabe voran oder Endemarkierung hinten dran, aber ich würde besser immer mit Längenangabe arbeiten)
- und nun die Daten, auch wieder mit Länge, welche man genausi immer mehr verschachteln könnte
- und eventuell noch eine Endemarkierung, CRC usw.

oder
- Startcode
- Datenlänge
- mit TReader/TWriter erstellter Datenblock ...
- CRC32 über Datenlänge+Datenblock

Was passiert, wenn die Datenlänge falsch übermittelt wurde?
Ich würde mindestens ein Endezeichen oder doch eine CRC verwenden.
Eine CRC/Checksum mag redundant sein, aber was passiert, wenn der Empfang in der Mitte eines logischen Streams einsetzt? Dann ist die Datenlänge undefiniert bzw. irgendeine Hausnummer (alles schon dagewesen).
In sehr störanfälligen Netzen kann es zudem trotzdem zu Übertragungsfehlern kommen, auch wenn TCP das angeblich abfängt. Allerdings ist der Fall extrem selten

Weiterhin muss bedacht werden, das Verbindungsabbrüche nicht notwendigerweise erkannt werden, d.h. beide Seiten denken, das die Verbindung ok ist. Hier können Heartbeats helfen, also eine Seite sendet 1x pro Sekunde ein kleines Paket, das von der Gegenstelle zurückgeschickt wird.

[himitsu]

Zitat von Furtbichler:

Weiterhin muss bedacht werden, das Verbindungsabbrüche nicht notwendigerweise erkannt werden, d.h. beide Seiten denken, das die Verbindung ok ist.

Das passiert selbst bei DataSnap (siehe alte Threads von mir), wobei es beim Clienten das nächste mal Knallt und er eine neue Verbindung aufbauen könnte.
Aber der Server ist da Problematischer, da er z.B. beim Beenden aus solchen angeblich noch "offenen" Verbindungen hängen bleibt, weil er denen noch Tschüs sagen will.
Aber schlimmer ist es bei den Callbacks, denn da kann es auch im Server knallen und wenn es mal richtig Knallt, dann kannst'e schnell mal die ganze Serveranwendung vergessen.