@dige
ReceiveNetworkData kann folgende Ergebnisse liefern:
- die Anzahl der empfangenen Bytes, und diese stimmt mit
der gewünschten Länge (hier <buffer>) überein
- die Anzahl der empfangenen Bytes, diese ist jedoch kleiner
als die gewünschte Länge (es sind zwar schon Daten da vom
Netzwerk, aber eben noch nicht alle -- abhängig von Auslastung,
Geschwindigkeit etc)
Diesen Effekt bezeichne ich mal als Unterlänge.
- den Wert -1, es konnte nichts empfangen werden.
Das Codeschnippsel nimmt nun keine Rücksicht auf eine
mögliche Unterlänge, die bei <buffer = 128> in einem
lokalen unausgelasteten Netz selten auftreten wird, aber
doch irgendwann einmal. Bei buffer > 5000 ist das schon
anders, Unterlängen sind die Regel.
Im Falle einer Unterlänge wird die Repeat-Schleife verlassen
und der Rest wird dann dem nächsten Sendepaket vorangestellt.....
Eventuell ergibt sich ein gewisser Selbstheilungseffekt, wenn die
Procedur oft genug aufgerufen wird und so die Daten vom Netzwerk
abgeholt werden.... besser auf die Unterlänge reagieren und nur
mehr den Rest (oder wieder eine neue Unterlänge) abholen.
Wenn die Procedur zum sukzessiven Aufbau der Datei gedacht
ist, sollte auch noch ein Fileseek... nach dem Openfile hinein um ans
Dateiende zu springen, sonst überschreiben sich die 128 Byte immer
selbst.....
Vor der Procedur sollte auch noch der Event abgefragt werden,
ob überhaupt Netzwerksdaten anliegen....
Generell sollte man Dateien mit SendNetworkData - ReceiveNetworkData
nicht ohne ein Handshaking übermitteln, d.h. vor dem Senden
die Dateilänge und den Dateinamen (ist ja ev. auch interessant)
übertragen, dann die Datei zu senden und danach den Empfang zu
bestätigen (der Client sollte ja auch wissen daß die Übertragung fertig ist..)
Das Thema Network ist beliebig kompliziert .....
Cu von Team100
