Konzept um Dateien von einem Server zu laden

[RuFFnEcK]

Hallo liebes Forum,

ich weiß noch nicht genau wie ich ansetzen soll.

Es gibt ein paar Tools hier in denen ich eine aktualiserungsfkt. einfügen will. Zum einen wurden diese Tools mit .NET und zum anderen mit den MFC implementiert.
Ich will die Tools so erweitern, dass diese beim starten auf einem Server nachschauen ob es eine neuere Version bestimmter Dateien gibt und diese gegebenenfalls runterläd.
Jetzt habe ich folgende Fragen:

1. Lässt sich ein Modul implementieren, das unabhängig von MFC und .NET läuft (Klar kann ich ein eigenes Programm dafür schreiben und aus den jeweiligen Programmen heraus aufrufen.)
2. Wie realisieren ich den Server zugriff? HTTP-Anfrage? (Kenn mich in dem Bereich nicht so aus...)
3. Wie realisiere ich den Server? (Klar Server Zugriff und Server hängen natürlich direkt voneinander ab )

Wäre schon für Hilfreiche Links dankbar, hab so nichts driekt gefunden, da es sich nicht um ein konkretes Problem handelt...

Viele Dank und lieben Gruß
RuFF

 

[sheel]

1) Am ehesten eine Sourcedatei mit "normalem" C++
Kannst du ja problemlos mit MFC-Teilen zusammen kompilieren und relativ problemlos als C++/CLI in ein .NET-Programm übernehmen.

2 und 3: Da gibts viele Möglichkeiten
Nur ein Dateidownload ist vergleichsweise einfach zu realisieren.
Ich würde HTTP etc vergessen und einen normalen Socketserver schreiben, der die neue Datei eben byteweise zum Client schickt (eine Anfrage zuerst, ob überhaupt was neues zum Laden ist noch dazu, fertig)

Wenn du aber zB schon einen Apache greifbar hast, spar dir den Server und mach einen HTTP-Download...
kommt immer auf die Situation drauf an.

 

[RuFFnEcK]

Hi,
erstmal danke für deine Antwort. Ich tendiere dazu ein eigenes Tool für den Server zu schreiben und ein Modul dass ich in ein MFC Tool integriere und in ein .NET Tool.

Das ganze soll natürlich sicher sein.
Das Server Tool muss dann ja auf einen bestimmten Port hören? Gibt es schon fertige Klassen, die mir zumindest das Portlistening abnehmen?
Hast du vielleicht mal nen Link zu Hintergrund Informationen um einen Socketserver zu implementieren?

Viele Grüße
RuFF

 

[sheel]

Mit Klassen in der Winapi sieht es eher schlecht aus.
Wie weit kennst du dich mit Sockets generell schon aus?
Kennst du dich mit dem hier http://www.c-worker.ch/tuts.php schon aus oder noch nicht?

Das Portlisting ist an sich ja nicht so umständlich.
Bind, listen, accept, fertig.

Bei einem Dateiupdate arbeiten die Clients ja unabhängig voneinander, dh
Bezüglich der Auslastung könnte man problemlos immer eine bestimmte Clientanzahl von einem Thread verwalten lassen.
Wenn man alle Clients in einem Thread verwaltet, wird das ganze lahm, ein Thread pro Client wäre Resourcenverschwendung.
Also zB 16 Clients in einen Thread, für die nächsten 16 (gleichzeitigen) einen zweiten Thread usw...

Der Thread geht dann seine Clients immer der Reihe nach durch, gibt ihnen zB 1KB von der gewünschten Datei und wartet dann auf eine Rückmeldung (dass es korrekt angekommen ist), dann der nächste KB...

Die Funktion select (erklärt beim Link) ist hier gut geeignet.
Sie kann alle Sockets des Threads gleichzeitig überwachen, ob eine Rückmeldung gekommen ist, ohne den Prozessor auszulasten.
Wenn ein Client wieder was geschickt hat, kannst du ihm den nächsten KB senden und wieder select...
Und alle 100ms noch eine Prüfung dazu, ob dem Thread ein neuer Client zugeteilt wurde.

...Ich hab keine Vorstellung von deinem Wissensstand, dann könnte ich dir wahrscheinlich gezielter helfen.

 

[RuFFnEcK]

Ich plan das ganze erst noch, darum habe ich mich auch noch nicht so in die Thematik eingelesen.
Dein Posting hat mir schon sehr weitergeholfen!
Ich werde mich in deinen Link einlesen und dann hier wieder gezielt fragen^^

Ach und danke für die implemenetierungs Hinweise! Da hätte ich wahrscheinlich angefangen für jeden Client einen eigenen Thread zu erstellen, um sicher zu gehen ;-)

Ich hab grad nur überlegt wie ich das anstelle genau einen KB einer Datei zu versenden, aber ich tippe mal es gibt da fertige Funktionen****!!

Hab tausend Dank und einen schönen Tag noch,
RuFF

 

[sheel]

Ein Thread pro Socket wäre auch einfacher zu programmieren

Aber erstens ist es wie schon geschrieben vollkommen verschwendete Leistung und zweitens gibt es vom Betriebssystem aus eine Grenze, wieviel Threads maximal existieren dürfen...hab jetzt den Wert nicht im Kopf, aber definitiv viel weniger als die möglichen 65536 Sockets gleichzeitig ( )

Auch zum genau durchlesen wäre EnterCriticalSection (und was noch dazugehört) in der MSDN für die Threadsicherheit.

Ich stell mir da ein Array aus Strukturen vor, für jeden Thread eine mit:
einem Status, einer (leeren) Socketvariable und der Anzahl, wieviel Sockets der Thread gerade verwaltet.
Neben den ganzen Threads gibts ja noch einen "Hauptthread", der zum listen da ist und die Clients dann auf die anderen Threads aufteilt.
Wenn ein neuer Client kommt, sucht derer im Strukturarray nach einem Thread, der noch nicht 16 Clients hat, weist den Client der Socketvariable in der Struktur zu und setzt den status der Struktur auf einen bestimmten Wert, als Kennzeichnung dass da ein neuer Client drin ist.
Jeder Thread kontrolliert dann regelmäßig seine Struktur, ob ihm ein neuer Client zugeteilt wurde.
Falls kein freier Thread mehr gefunden wird, wird eben ein weiterer gestartet.

Über die Statusvariable können die Threads auch anderwertig gesteuert werden, zB falls der Server beendet wird um den Threads mitzuteilen, dass sie ihre Clients aufräumen und ordentlich aufhören.

Und wegen dem Kilobyte: Ich versteh das Problem nicht ganz.
Es werden die ersten 1024 Byte aus der Datei geholt, geschickt, dann die nächsten 1024 Byte...bis die Datei durchgearbeitet ist.

PS: Was willst du genau "sicher" machen? Sicher gegenüber technischem Datenverlust irgendwo im Internet oder sicher gegenüber menschlichen Abfangen etc der Daten?