Hallo,

als ich in einem anderen Thread gerade erklärt habe wie die Receive-Loop in C# funktioniert ist mir was aufgefallen:

 

Es wird ja einfach in einen Puffer mit 8kiB geschrieben, allerdings wird nciht überprüft, ob auch genug gelesen wurde. Denn Read garantiert nur für 1 Byte, mehr nicht. Die Implementierung sieht dann zum Glück schonmal so aus, dass ganze TCP-Pakete auf einmal verfügbar sind.

 

Was ist heir das Problem?

1. Ihr seid darauf angewiesen, dass die Gegenseite erst dann flushed (das Paket losschickt) wenn die Nachricht komplett ist. Der brickd tut das, ihr könnt auch bei WLAN & Co. darauf achten, das so zu tun, allerdings müsste sowas dann mti in die TCP-Doku

2. Eure Pakete haben ein Größenlimit: ich bin mir nicht ganz sicher, aber entweder bei 4 kB oder spätestens 8 kB ist Schluss, dann wird jede Nachricht auf mehrere Pakete verteilt. Das heißt im Moment kann keine Nachricht durchkommen die größer ist, weil dann die Bindings daran sterben würden.

 

Möglicherweise sind diese Überlegungen für euch egal, weil ihr sagt:

1. Wir implementieren alles selber und achten darauf, dass alles in einem Paket versendet wird

2. Wir brauchen keine Nachrichten die größer sind als ein TCP-Paket

 

Kann durchaus sein, sollte aber bewusst entschieden werden ^^

 

Lösung? (wenn Lösung nötig)

1. Falls Paketlänge vorher bekannt, solange weiterlesen bis der Puffer ausreichend voll ist (scheint hier nicht zu gehen)

2. In der weiteren Bearbeitung keinen Byte-Buffer weiterreichen sondern den Stream, dann kann der Code der die Daten braucht sie vom Stream nehmen (das kann dann problematisch sein, wenn man zuerst Daten braucht die weiter "hinten" stehen)

 

LG

Jan

 

P.S.: Wenn der Java-Code genauso aussieht, dann ist dort das gleiche Problem... bei den anderen Standardbibliotheken kenne ich mich weniger aus, aber ich glaube das ist die übliche read-implementierung

Ja, das Problem von Short Reads ist mir auch schon aufgefallen. Es steht auch auf meiner TODO Liste. Und ja im Moment arbeiten alle Bindings so.