![]() |
[Artikel] Auf das Netzwerk ist kein Verlass
... oder wenn einfache Dinge doch kompliziert werden. ;)
Die Überlegung, dass man sich nicht auf das Netzwerk verlassen darf und was daraus resultiert, wenn man eigentlich nur eine Datei verschieben will, hat mich zu dem obigen Artikel angeregt. Artikel: ![]() |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
schoener artikel, gefaellt mir. kann ich zum teil aus persoenlicher erfahrung bestaetigen.
habe damals aus platztmangel in panic versucht dateien uebers netztwerk zu verschieben. ging natuerlich in die hose. am ende waren von rund 3500 nur noch knapp 1000 vorhanden bzw. auffindbar. seitdem tu ich nur noch kopieren verwenden. und hinterher wird die dateianzahl und die byteanzahl in den eigenschaften verglichen. ist zwar mehr arbeit aber sicherer. bin bissjetzt auch gut damit gefahren. gruß richard |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Ich hatte mal ein ähnliches Problem, nur ging es damals um einen FTP Server. Und da ist mir die Verbindung im Durchschnitt alle 2 Minuten abgebrochen... Aber anstatt alle Dateien zu kopieren und bei Erfolg anschliessend auf dem Server zu löschen, wäre ich so nie zu einem Ergebnis gekommen, weil ich so immer wieder von neuem starten müsste. Ich habe stattdessen jede Datei einzeln behandelt, sprich kopiert, entpackt, ins Archiv gelegt (d.h. wieder gepackt), und erst dann wenn alles lief die Originaldatei auf dem Server, in meinem Fall, umbenannt. Eine Liste der zu kopierenden Dateien habe ich natürlich auch erstellt, und in einer DB Tabelle hinterlegt. Wurde eine Datei erfolgreich kopiert, so hab ich dies in der Tabelle gekennzeichnet.
Um zu prüfen, was überhaupt passierte, habe ich noch zusätzlich ein ausführliches Logfile anzulegen... Bislang kann ich auf Holz klopfen, das System klappt einwandfrei, und das schon ohne Störmeldung sein Dezember 2005. Und es werden wirklich täglich über 100 Dateien gesogen, jede einzelne um die 100 kB gross. Vielleicht kannst Du dich ja von meiner Methode noch bischen inspirieren lassen... Hier mal ein Auszug aus dem Logfile...
Code:
[17.11.05 14:14:02] - Service started
[17.11.05 14:14:03] - Connected to Database Server [17.11.05 14:14:03] - Mailcheck und FTP Download in 3 Sekunden [17.11.05 14:14:06] - Starte Checkprozedur [17.11.05 14:14:06] - Verbunden mit Mailserver [17.11.05 14:14:06] - 3 zu bearbeitende Mails auf dem Mailserver [17.11.05 14:14:06] - MsgId = <1843900361.20051117140719@***> [17.11.05 14:14:06] - Bearbeite Mail N° 1 [17.11.05 14:14:06] - Bearbeite Part 1 / 2 aus Mail 1 [17.11.05 14:14:06] - Part 1 ist ein Textpart - unwichtig [17.11.05 14:14:06] - Bearbeite Part 2 / 2 aus Mail 1 [17.11.05 14:14:06] - Part 2 ist ein Attachment [17.11.05 14:14:06] - Attachment stimmt im Format - Abrechungsprotokoll wird gespeichert [17.11.05 14:14:07] - MsgId = <104822394.20051117140725@tp-net.lu> [17.11.05 14:14:07] - Bearbeite Mail N° 2 [17.11.05 14:14:07] - Bearbeite Part 1 / 2 aus Mail 2 [17.11.05 14:14:07] - Part 1 ist ein Textpart - unwichtig [17.11.05 14:14:07] - Bearbeite Part 2 / 2 aus Mail 2 [17.11.05 14:14:07] - Part 2 ist ein Attachment [17.11.05 14:14:07] - Attachment stimmt im Format - Abrechungsprotokoll wird gespeichert [17.11.05 14:14:07] - MsgId = <1627976300.20051117140759@tp-net.lu> [17.11.05 14:14:07] - Bearbeite Mail N° 3 [17.11.05 14:14:07] - Bearbeite Part 1 / 2 aus Mail 3 [17.11.05 14:14:07] - Part 1 ist ein Textpart - unwichtig [17.11.05 14:14:07] - Bearbeite Part 2 / 2 aus Mail 3 [17.11.05 14:14:07] - Part 2 ist ein Attachment [17.11.05 14:14:07] - Attachment stimmt im Format - Abrechungsprotokoll wird gespeichert [17.11.05 14:14:07] - Disconnected from Mailserver [17.11.05 14:14:07] - ProtollkollPropertyID : 427 [17.11.05 14:14:07] - Maske: 2991883_20051031_20050531_*.DAT [17.11.05 14:14:07] - 2991883_20051031_20050531_0001-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:07] - 2991883_20051031_20050531_0002-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:07] - 2991883_20051031_20050531_0003-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:07] - 2991883_20051031_20050531_GESAMT.DAT markiert als zu runterladende Datei [17.11.05 14:14:07] - ProtollkollPropertyID : 428 [17.11.05 14:14:07] - Maske: 2994077_20051031_20050630_*.DAT [17.11.05 14:14:07] - 2994077_20051031_20050630_0001-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:07] - 2994077_20051031_20050630_0002-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_0003-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_0004-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_0005-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_0006-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_0007-01.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - 2994077_20051031_20050630_GESAMT.DAT markiert als zu runterladende Datei [17.11.05 14:14:08] - Dealing 2991883_20051031_20050531_0001-01.DAT [17.11.05 14:14:08] - Download OK [17.11.05 14:14:08] - Decrypt OK [17.11.05 14:14:08] - GZip OK [17.11.05 14:14:08] - Datei archivieren OK [17.11.05 14:14:08] - FTP Download komplett OK [17.11.05 14:14:08] - Originaldatei wurde nicht umbenannt [17.11.05 14:14:08] - Temporäre Dateien löschen OK [17.11.05 14:14:08] - Dealing 2991883_20051031_20050531_0002-01.DAT [17.11.05 14:14:08] - Download OK [17.11.05 14:14:08] - Decrypt OK [17.11.05 14:14:08] - GZip OK [17.11.05 14:14:09] - Datei archivieren OK [17.11.05 14:14:09] - FTP Download komplett OK [17.11.05 14:14:09] - Originaldatei wurde nicht umbenannt [17.11.05 14:14:09] - Temporäre Dateien löschen OK [17.11.05 14:14:09] - Dealing 2991883_20051031_20050531_0003-01.DAT [17.11.05 14:14:09] - Download OK [17.11.05 14:14:09] - Decrypt OK [17.11.05 14:14:09] - GZip OK [17.11.05 14:14:09] - Datei archivieren OK [17.11.05 14:14:09] - FTP Download komplett OK [17.11.05 14:14:09] - Originaldatei wurde nicht umbenannt [17.11.05 14:14:09] - Temporäre Dateien löschen OK [17.11.05 14:14:09] - Dealing 2991883_20051031_20050531_GESAMT.DAT [17.11.05 14:14:09] - Download OK [17.11.05 14:14:09] - Decrypt OK [17.11.05 14:14:09] - GZip OK [17.11.05 14:14:09] - Datei archivieren OK [17.11.05 14:14:09] - FTP Download komplett OK [17.11.05 14:14:09] - Originaldatei wurde nicht umbenannt [17.11.05 14:14:09] - Temporäre Dateien löschen OK usw... [17.11.05 14:14:27] - Dealing 2991883_20051117_20050531_GESAMT.DAT [17.11.05 14:14:27] - Download OK [17.11.05 14:14:27] - Decrypt OK [17.11.05 14:14:27] - GZip OK [17.11.05 14:14:27] - Datei archivieren OK [17.11.05 14:14:27] - FTP Download komplett OK [17.11.05 14:14:27] - Originaldatei wurde nicht umbenannt [17.11.05 14:14:27] - Temporäre Dateien löschen OK [17.11.05 14:14:27] - Nächster Check um 17.11.2005 15:14:06 [17.11.05 14:14:34] - Service stopped |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
@Jelly: Das Log, was ich von dem Programm schreiben lasse, ist so ausführlich, da kannst du nachher genau den Zeitpunkt bestimmen, wann die Fliege tot von der Wand gefallen ist. :mrgreen:
|
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Im Kern schreibst Du, dass eine Netzwerk-Übertragung fehlerhaft sein kann. Das ist unumstößlich richtig, aber auch irgendwie ... trivial. Sorry.
Das Netzwerk per se ist kein sicheres Medium. Aber die Software, die Du obendrauf setzt, kann diesen Makel ausgleichen und Dir eine sichere Übertragung garantieren. Damit wird das Medium "Netzwerk" aus Sicht der Anwendung wieder zu einer zuverlässigen Komponente, bei der sich zweifelsfrei feststellen lässt, ob ein Transfer geklappt hat oder nicht. |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Vorerst: Ich hab keine Ahnung von Netzwerken.
Was ich nicht verstehe: Ist es denn komplett Aufgabe der Software zu kontrollieren, ob die Übertragung erfolgreich war und wenn nicht ein Packet nochmal zu senden? Ich dachte auch die Hardware würde da mit Prüfsummen oder sonstwas arbeiten. Ich habe da vor gut 3 bis 4 Jahren mal ein Referat im Informatikkurs gehalten, welches als Thema irgendwas mit Datenübertragung hatte. Ich weiß nicht mehr, um welche Art von Datenübertragung es sich da handelte, aber da ging es auch um Verfahren, wie auf Hardwareebene Datenverlust verhindert werden konnte, in dem ständig überprüft wurde, ob auch das richtige angekommen ist. Gibt es sowas nicht? |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Ich bin der Meinung, wenn was ankommt, dann auch das Richtige. Dafür sorgt alleine schon das TCP/IP Protokoll, dass das Paket richtig ankommt, und der Client fordert im Fehlerfall das Paket nochmals an. Darum musst du dich nicht sorgen. Auch die Reihenfolge, wie die Pakete reinkommen, muss dich nicht interessieren, denn auch da sorgt das TCP/IP Protokoll, dass auf der Gegenseite wieder alles richtig zusammengeschnürt wird. Ja, es ist noch nicht mal sicher, dass die Pakete übers Internet alle den gleichen Weg verfolgen, auch wenn sie zu ein und der gleichen Datei gehören.
Was aber wenn das Netzwerk (ob LAN oder WAN ist egal... Und auch ob FTP oder sonstin Protokoll) während der Übertragung zusammenbricht. Auf Clientseite kriegst Du nur einen Fehler. Dann hast Du die Datei aber noch lange nicht. Ich denke, das ist der Punkt, den Luckie angeschrieben hat, nicht das Übertragungsprotokoll. |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
[edit]
Mist, zu langsam ;-) [/edit] Doch, auch. ;-) Wir reden hier von verschiedenen Ebenen der Daten-Übertragung. Beispiel TCP: "Recht weit unten", auf Ebene der TCP-Pakete hast Du eine sichere Übertragung, dies garantiert Dir das TCP-Protokoll. Sicher heißt hier: Es ist klar, ob ein Paket zugestellt wurde oder nicht. Mit TPC-Paketen alleine kommst Du jedoch noch nicht weit. Die Software, die dann "ein ganzes Stück weiter oben" sitzt und eine Datei kopieren will, muss dann das erledigen, was Michaels Artikel beschreibt. Und dazu gehört eben, den Status der Übertragung zu verfolgen und im Falle eines Fehlers entsprechend zu reagieren. Die Software hat alle technischen Möglichkeiten, dies zu tun - sie muss es nur tun. Datentransfer von wichtigen Daten ist eben gerade kein "Fire-and-Forget". |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Zitat:
Danke euch beiden. :) |
Re: [Artikel] Auf das Netzwerk ist kein Verlass
Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:00 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz