[C#] Wie Post Requests teilw. mit multipart-Formular und Queue

[CHRiSNEW]

Moin liebes WHF,

ich helfe einem Kumpel bei einem kleinen Projekt aus und da dort leider eine unsexy Mischung aus proprietäre Hardware, komische Software und Windows herumköchelt, muss ich mich leider da beugen und in die C# und die wunderliche Microsoft-Welt eintauchen.

Ich will folgendes erreichen:

• HTTP Post Request, teilweise mit Datei-Upload, abschicken.
• Muss asynchron im Hintergrund laufen.
• Darf auf KEINEN Fall den Haupt-Thread blockieren.
• Die Queue sollte persistent sein, damit nach einem Programm-Neustart keine Jobs verloren gehen.
• Sollte der Post Request failen (5xx Fehler, keine Konnektivität), muss der Jobs mit zeitlichem Versatz später versucht werden.
  

Kennt jemand da eine relativ fertige Lösung?

Ich hab bisher nur das Uploaden hingefummelt und eigentlich gedacht, das wäre async, aber dennoch blockiert der Haupt-Thread, wenn das Posten an sowas wie No Route To Host scheitern.

Ich kann mir nicht vorstellen, dass es sowas nicht bereits als Library oder so geben sollte.

Danke für soliden Input.

PS: NUTZ $andereProgrammierspracheOderAnderesBetriebsystem GEHT NICHT. Das habe ich schon ausgiebig evaluiert...

[winfreak]

Fertig kenne ich da leider nix :|

[CHRiSNEW]

Wenigstens was für die Queue? Wie gesagt, HTTP Post hab ich ja schon halbwegs, nur dass es doch blockiert. Das könnte ich vllt noch fixen.

[mrshadowtux]

Kann man da nichts in Richtung Ajax machen?

[CHRiSNEW]

Das ist keine Browser-Webanwedung-Kiste. Das ist rein Hardware über Software ansprechen. Nur ich brauch halt noch HTTP wegen paar anderen Sachen, die die Hauptanwendung nicht blockieren darf, aber zuverlässig arbeiten muss.

[niwax]

Schau dir mal ThreadPool.QueueUserWorkItem an für die asynchronen Sachen. Dann ist nur nicht garantiert, dass sie in der gleichen Reihenfolge ausgeführt werden. Als Ausfallsicherung kannst du alle aktuellen Jobs in ne Datei speichern. Wenn der Upload gestartet wird, markierst du ihn in der Datei als gestartet bzw fehlgeschlagen (mit Uhrzeit/Datum), wenn er erfolgreich ist löschst du ihn. Du kannst bei einem Absturz oder auch von Zeit zu Zeit prüfen, in welchem Zustand das Programm ist und alte Jobs neustarten

[CHRiSNEW]

Okay, ThreadPool Worker klingt nicht verkehrt! Ich schau es mir mal an. So einen ähnlichen Ansatz mit Datei schreiben und schauen, ob die es noch gibt, hatte ich auch schon in Erwägung gezogen.

[niwax]

Wenn das ganze keine besonderen Performanceanforderungen hat, kannst dir für die Datei mal Serialisierung anschauen, das geht auch mit den Listen- und Stacktypen.

[gandro]

Habe sehr wenig Erfahrung mit C#/.NET, etwas Senf möchte ich trotzdem dazugeben, aber ich hab mich mal länger mit In-Memory Thread Pool Queues auseinandergesetzt: Die Dinger sind für viele gleichzeitig arbeitende Threads optimiert, mit komplexen Locking-Mechanismen, CPU-Cache-Optimierung etc. Wenn solche Queues die bei jedem Request in Dateien serialisiert verliert man praktisch alle genannten Vorteile, weil da immer ein globales Lock genommen werden muss. Du willst die Requests ja eigentlich nicht im Memory vorhalten, sondern auf einem persistenten Speicher.

Darum: Da Persistenz bei dir wichtiger scheint als Performance (und dafür sind solche Queues häufig optimiert) würde meinen Fokus viel eher auf Persistenz getrimmte Messaging-Queues widmen, wie z.B. Rabbit MQ. Selbst eine kleine Datenbank (SQLite z.B. mit einem Thread der INSERT macht, und den Worker-Threads die SELECT/DELETE machen) dafür zu missbrauchen funktioniert in der Regel relativ robust. Garantiert nicht die schnellste Lösung, dafür robust und persistent, und vermutlich weniger Gefrickel als eine In-Memory-Queue manuell in Dateien zu dumpen und sicher zu stellen dass die synchronisiert bleiben.

[CHRiSNEW]

Ja, mir geht es eher um Persistenz als um Geschwindigkeit. Ich schau mir auch mal Rabbit MQ et cetera oder eventuell sqlite. Das würde sogar etwas Flexibilität ins Spiel bringen. Danke!