HTTP POST Request langsamer machen

[Heiko (Gast)]

Hallo,

ich habe auf einem STM32 einen Webserver laufen. Funktioniert auch alles 
soweit. Als Netzwerkadapter habe ich einen Wiznet5100 im Einsatz. Ich 
kann GET und POST Requests verarbeiten.

Mein Problem ist lediglich, dass der Datenbuffer des W5100 begrenzt ist 
und ich beim Speichern einer großen Datei per POST-Request nicht 
hinterherkomme, und mir somit bei großen Dateien teilweise Daten 
verloren gehen.

Die Dateien lade ich über ein Formular aus meinem Webbrowser hoch.

Meine Frage: Ist es irgendwie möglich, die Daten bewusst langsamer zu 
schicken (evtl. mit JavaScript???).

Vielen Dank für Anregungen.

[Duenner Troll (Gast)]

Naja. Wenn dein Webserver die Seite rausgibt, und der Browser dann die 
Daten liefert, kann man ja kontrollieren wieviel kommen soll. Wenn man 
Textfelder zum Einfuellen mit einer kapazitaet von 4kB zur Verfuegung 
stellt, koennen die natuerlich kommen. Wenn ein Name hingegen nur 20 
Char lang sein darf, kommen auch nur 20 Zeichen.

Andersherum, wenn man die Webseite aus irgendwelchen Furzgruenden nicht 
anpassen kann, muss eben etwas mehr Speicher her.

[Heiko (Gast)]

Es geht um das Versenden von kompletten Dateien an den Webserver. Nicht 
um einzelne Textfelder.

[T.roll (Gast)]

Das HTTP-Protokoll verhindert sowas eigentlich. Was nutzt du für einen 
Webserver?

[(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)]

Bei einer TCP-Windowsize von 1, muss jedes Paket mit
einem Acknowledge bestaetigt werden.
Da kann eigentlich nichts zu schnell kommen...

Das solltest du mit einem Sniffer vielleicht mal pruefen
und die eigenen Quellen darauf abklopfen.

[Werists (Gast)]

>ich beim Speichern einer großen Datei

Dann hilft es evtl. die Datei in kleinere Stücke aufzuteilen.
HTML5 File hat mit der FileApi das file.slice dafür vorgesehen.

[Kaj (Gast)]

(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· schrieb im Beitrag 
#5120804:
> Bei einer TCP-Windowsize von 1, muss jedes Paket mit
> einem Acknowledge bestaetigt werden.
> Da kann eigentlich nichts zu schnell kommen...
Ich weiss nicht wie der W5100 genau arbeitet, aber da der TCP/IP-Stack 
im Chip enthalten ist, kann ich mir denken, dass das ACK automatisch vom 
W5100 gesendet wird, unabhaengig davon, ob der Nutzer die Daten nun 
schon abgeholt hat oder nicht.
Der TO kommt einfach nicht damit hinterher, die Daten mit dem STM32 vom 
W5100 abzuholen, oder er bremst das Abholen (ungewollt) aus, weil er 
moeglicherweise mit dem Speichern der Daten nicht hinterherkommt.

Heiko schrieb:
> Meine Frage: Ist es irgendwie möglich, die Daten bewusst langsamer zu
> schicken (evtl. mit JavaScript???).
Ich wuerde ja eher Versuchen die Daten schneller zu verarbeiten.

Was fuer ein STM32 ist es genau?
Wie ist der STM32 mit dem W5100 verbunden?
Wie holst du die Daten vom W5100 ab? (Interrupt, Polling)
Auf was fuer einem Medium werden die Daten dann gespeichert?
Ist der Webserver was selbstgestricktes oder was fertiges?
Wenn es ein fertiger Webserver ist, welcher Webserver ist das?
Hat der STM32 noch mehr zu tun, als nur den Webserver zu spielen?
Ist da womoeglich noch ein RTOS im spiel?

Ein paar mehr infos waeren schon ziemlich knorke...

[(º°)·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.· (Gast)]

> W5100

Ach so.
Ich dachte bei meiner Antwort an den STM32F107 oder
den TM4C1294. Tschuldigung.

Der W5100 handelt die Acks basierend auf dem zur Verfuegung
stehenden Speicher selbststaendig aus.
Vielleicht sollte Mann beim W5100 Sysinit den Readbuffer verkleinern.
Bei 3 kByte (RX-)Buffer sollten nicht mehr als 2 Pakete hineinpassen.
Bei 1.5 kByte sogar nur 1 Paket was eine TCP-Windowsize von 1
ergeben sollte.

Genau genommen sollte das nicht noetig sein.
Deswegen heisst es ja TCP-Flow-Control.
Da ist bestimmt irgendwo noch was faul.

[Noch einer (Gast)]

Und selbst wenn der Empfangspuffer überläuft. Der Empfänger sendet dann 
ein ACK für das letzte verarbeitete Paket und der Sender wiederholt die 
verloren gegangenen Pakete.

Zu Modem-Zeiten war "langsamer machen" das wichtigste Feature des TCP. 
Sender und Backbone waren schnell. Pufferspeicher war teuer. Das Gateway 
zwischen Backbone und Modem musste den Sender ausbremsen.

[Jim M. (turboj)]

Heiko schrieb:
> Mein Problem ist lediglich, dass der Datenbuffer des W5100 begrenzt ist
> und ich beim Speichern einer großen Datei per POST-Request nicht
> hinterherkomme, und mir somit bei großen Dateien teilweise Daten
> verloren gehen.

Deine TCP/IP Implementation ist kaputt. Die muss das eigentlich 
abhandeln können, d.h. bei vollem Puffer das (IP-)Paket wegschmeissen. 
Wegen fehlendem ACK kommt dann bald ein Retransmit.

Das sollte der W5100 eigentlich von sich aus machen, wenn man empfangene 
TCP Daten nicht "sofort" abholt.

[Jan L. (ranzcopter)]

Heiko schrieb:
> Es geht um das Versenden von kompletten Dateien an den Webserver. Nicht
> um einzelne Textfelder.

da kenne ich eigentlich nur "Transfer-Encoding: chunked" - allerdings 
geht das in Richtung Browser->Server nicht mit einem normalen 
HTML-Formular; nur per Javascript lassen sich Header einfügen.
Und dann muss das natürlich auch der Webserver unterstützen...