Maximale Nachrichtengröße bei FTP auf dem Steuerkanal

[uweb]

Bei TCP-Verbindungen beträgt die maximale 'DatenPufferLänge' 65536.

Nun frage ich mich ob das zuverlässig immer genügt um die FTP-Kommunikation auf dem Steuerkanal (command channel) in beide Richtungen abzudecken.
Vielleicht liegt es an meinem begrenzten Englisch oder an den falschen Suchbegriffen. Aber ich finde über google keine Antwort darauf.

Danke im voraus!

[NicTheQuick]

Ich verstehe das Problem nicht. Wenn eine Nachricht nicht in die 65535 Bytes reinpassen sollte, dann muss man eben mehrere Päckchen nacheinander lesen, so wie man das sowieso machen müsste.

[uweb]

Es gibt kein Problem - zumindest noch nicht.

Im Moment bin ich noch gar nicht so weit, dass ich ein Problem haben könnte.

Ich will einen Proxy schreiben und bin beim Grundgerüst.
Das Grundgerüst soll einfach nur möglichst schnell den Steuerkanal durchreichen ohne sonst irgend etwas zu tun.

Ich denke nun darüber nach genau die von Dir beschriebene Vorgehensweise wenn möglich zu vermeiden.
Dabei geht es nicht nur darum, dass ich dafür die Nachrichtengröße schon vorher wissen muß.
Sondern auch darum, dass ich, wenn möglich, den Buffer nicht ständig neu erzeugen will.
Ich würde ihn gerne am Anfang mit einer Größe von 65536 Byte erzeugen und dann nur noch überschreiben.
Nun frage ich mich ob das so zuverlässig möglich ist, oder ob ich damit rechnen muß, dass sich das irgendwann rächt.

[NicTheQuick]

Nein, das ist schon völlig korrekt und richtig so. Der beste Weg ist immer Speicher nur einmal allozieren zu müssen. Wenn du also einmal am Anfang 65535 Bytes allozierst, kannst du die immer weiter verwenden. Mach allerdings nicht den Fehler und nutze Strings dafür, sondern natürlich 'AllocateMemory()'. Leider haben schon zu viele diesen Fehler gemacht, deswegen sage ich es gleich.

[uweb]

Super, danke!

[Shamos]

@UWeb:
Das mit den Datenpuffergröße in der PB-Doku ist etwas komisch erklärt worden wie ich finde.
Denn sowohl UDP als auch TCP hat eine theoretische Blockgröße bis 65536 Bytes.

Doch das ist vollkommen Wurst, denn du überträgst eh alles per Ethernet bzw dsl und da steht
dann die MTU (Max Transfer Unit) im wege, welche bei Ethernet 1500 Bytes groß ist und
bei DSL im allgemeinen nicht größer als 1492 Bytes. Insofern würden für einen
Buffer 1500 Bytes ausreichen.

Wenn Du zusammenhängende Daten über die Länge eines Buffers hinaus empfängst
dann lies eben den gesamten Block aus und füge den Buffeinhalt immer an das Ende
eines unbegrenzten Strings an. Auswerten kannst Du diesen dann immer noch wann du willst.

[uweb]

Danke!
Das ist wohl eines der Probleme die ich noch nicht habe.
Das liegt wohl daran, dass Client, Proxy und Server momentan auf dem gleichen Rechner (via 127.0.0.1) laufen.
Vielleicht liegt es auch daran, dass die Nachrichten (immer ?) so kurz sind.
Ich hoffe ich denke an Deinen Tipp wenn die Probleme kommen.
So ganz komme ich wohl nie von der Try&Error-Methode weg.

[NicTheQuick]

Wenn Du zusammenhängende Daten über die Länge eines Buffers hinaus empfängst
dann lies eben den gesamten Block aus und füge den Buffeinhalt immer an das Ende
eines unbegrenzten Strings an.

Wenn es sicher ist, dass die Daten tatsächlich Zeichenketten sind, die im Ascii- oder Unicode-Modus vorliegen (je nach Compiler-Einstellung), dann kann man das so machen.
Ansonsten NIE auch nur daran denken das so zu machen! Es werden keine Daten in Strings gespeichert. Warum das so ist, muss ich jetzt noch mal zum hundersten mal erklären.

[uweb]

Ich habe das zwar wohl schon hundert mal übersehen, aber vermeide es auch so wenn es geht - obwohl auf dem Steuerkanal wohl tatsächlich nur Text übertragen wird.

Trotz meiner bescheidenen Englischkenntnisse bin ich hier (http://www.purebasic.fr/english/viewtop ... 12&t=51072) auf ioctlsocket_() gestoßen, womit ich die Nachrichtengröße zumindest unter Windows schon vorher ermitteln könnte um mir einen entsprechend großen Speicher zu reservieren. Dort hinein könnte ich auch ohne String mehrere Päckchen nacheinander lesen - wenn ich alles richtig verstanden habe.

Ich danke euch für die Infos.
Die ursprüngliche Frage (Maximale Nachrichtengröße bei FTP auf dem Steuerkanal) stellt sich nun angesichts von "im allgemeinen nicht größer als 1492 Bytes" leider wieder. Zumindest kam nicht nach 2 Min. die Antwort "Das steht doch da und da.". Ich brauche mich also nicht zu schämen.


Im Moment probiere ich es lokal mit der festen Größe von 65536 Byte und schaue, dass ich erst mal überhaupt zu einem lauffähigen Code komme. Das mit dem "mehrere Päckchen nacheinander" habe ich nun mehr als zuvor im Hinterkopf und greife darauf zurück wenn es nötig wird.

[Shamos]

Wenn Du zusammenhängende Daten über die Länge eines Buffers hinaus empfängst
dann lies eben den gesamten Block aus und füge den Buffeinhalt immer an das Ende
eines unbegrenzten Strings an.

Wenn es sicher ist, dass die Daten tatsächlich Zeichenketten sind, die im Ascii- oder Unicode-Modus vorliegen (je nach Compiler-Einstellung), dann kann man das so machen.
Ansonsten NIE auch nur daran denken das so zu machen! Es werden keine Daten in Strings gespeichert. Warum das so ist, muss ich jetzt noch mal zum hundersten mal erklären.

Genau von diesem Fall bin ich ausgegangen. Ansonsten sollte man das ganze selbstverständlich wie Binary-Daten behandeln.