-
DFN-ProjektMulticast-Distribution-System – MDiS
Abschluß bericht
15.2.2002
Erstellt durch:Deutscher WetterdienstKaiserleistr. 4263067
Offenbach
Herr KnottenbergHerr KiehlHerr Lö ser
Durchführung des Projektes in Zusammenarbeit
mit:TelliqueKommunikationstechnik GmbHBerliner Straße 26D-13507
Berlin
Universität BremenTechnologiezentrum InformatikBereich Digitale
Medien und NetzeBibliotheksstraße, MZH 5180D-28359 Bremen
Das Vorhaben wurde aus Mitteln des Bundesministeriums fü r
Bildung, Wissenschaft, For-schung und Technologie (BMBF) durch den
Verein zur Förderung eines Deutschen For-schungsnetzes e. V.
(DFN-Verein) finanziert.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 1
1 INHALT
1 INHALT ________________________________________________ 12
EINLEITUNG ____________________________________________ 32.1
PROBLEMSTELLUNG 32.2 ZIELSETZUNG 43 HINTERGRUNDINFORMATIONEN
__________________________ 63.1 MULTICAST 63.1.1 Prinzip
______________________________________________ 63.1.2 Vorteile
_____________________________________________ 73.1.3
Anwendungsgebiete ___________________________________ 8
3.2 STANDARDISIERUNG 94 MULTICAST-DATEIVERTEILUNG Ü BER RDIST
MIT MTP/SO____ 124.1 RDIST 124.2 DESIGN VON MDIST 144.2.1 Ü
bertragung der Datei-Informationen _____________________ 144.2.2
Benö tigte Dateien der Server ___________________________ 154.2.3
Datenübertragung ____________________________________ 164.2.4
Verwendung von rdist zur abschließenden Fehlerbehebung ___ 164.2.5
Programmdokumentation zu mdist _______________________ 174.2.6
Protokollbeschreibung_________________________________ 174.2.7
Bewertung des Ergebnisses ____________________________ 18
5 MULTICAST-DATEIVERTEILUNG DURCH tq®-TELLICAST ______ 195.1
PRODUKTAUFBAU tq®-TELLICAST 195.2 FUNKTIONSWEISE 205.2.1
Initialisierung / Announcements _________________________ 205.2.2 Ü
bertragung ________________________________________ 20
6 ANWENDUNGSFALL DWD _______________________________ 226.1
DATENVERTEILUNG IM DWD 226.1.1 Beteiligte
Netzstrukturen_______________________________ 22
6.1.1.1 Primärnetz _____________________________________________
226.1.1.2 Sekundärnetz ___________________________________________
22
6.1.2 Datendistribution über AFD_____________________________
236.1.3 ISDN-Failover _______________________________________
24
6.2 GEPLANTE DATENÜ BERTRAGUNG Ü BER MULTICAST 256.2.1
Vorgesehener Einsatzbereich___________________________ 256.2.2
Anforderungen ______________________________________ 26
6.3 ZIELARCHITEKTUR 276.3.1 Integration von tq® -TELLICAST und
AFD___________________ 276.3.2 Schnittstelle zur Datenübertragung:
MD ___________________ 28
6.3.2.1 Schnittstelle auf Senderseite
_______________________________ 286.3.2.2 Schnittstelle auf
Empfängerseite ____________________________ 29
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 2
6.4 GESICHERTE DATENÜ BERTRAGUNG 306.4.1 Forward Error
Correction ______________________________ 306.4.2 Negative
Acknowledgements (NAK)______________________ 30
6.4.2.1 Bandbreitenkontrolle für
NAK_______________________________ 306.4.3 Steuerung von
Retransmissions _________________________ 326.4.4 Realisierung des
ISDN-Backups_________________________ 32
6.5 BANDBREITENMANAGEMENT BEI MEHREREN SENDERN 336.6
SCHNITTSTELLE ZUM MDIS-GUI 346.7 REALISIERUNG IM RAHMEN DES
PROJEKTES 356.7.1 Tests
______________________________________________ 356.7.2 Festlegung
der Multicast-Channel _______________________ 35
6.8 INBETRIEBNAHME 366.9 BEWERTUNG DES ERGEBNISSES 367
PROJEKTERGEBNIS ____________________________________ 388 ABKÜ
RZUNGSVERZEICHNIS/GLOSSAR____________________ 409
ABBILDUNGSVERZEICHNIS ______________________________ 43
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 3
2 EINLEITUNG
2.1 PROBLEMSTELLUNGDurch die hohe Popularität des Internets, die
steigende Bedeutung von In-formationsaustausch in der Wirtschaft
und die Entwicklung bandbreitenin-tensiver Verfahren zur Ü
bertragung von Multimediadaten ist die effektiveNutzung der
vorhandenen Netzkapazitäten ein entscheidender wirtschaftli-cher
und technischer Faktor.Multicasting, die simultane Datenübertragung
an mehrere, ausgewählteEmpfänger, stellt daher auf Grund der
resultierenden Bandbreiten- undKostenreduzierung eine Form des
Internet-Datenaustausches dar, die im-mer mehr an Bedeutung gewinnt
und zukünftig ein zentraler Service in derInternetlandschaft sein
wird.Die notwendige Netzinfrastruktur zur Ü bertragung von
Multicast-Paketenist derzeit bereits verfügbar und kann z. B. zur
ungesicherten Ü bertragungvon Audio- oder Videodaten problemlos
genutzt werden. Kern des Multi-cast-Backbones in Deutschland bildet
dabei das Deutsche Wissenschafts-netz (WiN/B-WiN).Trotz der
vorhandenen Infrastruktur und der vielfältigen Vorteile von
Multi-cast – Verringerung der Netzlast, Reduzierung der Ü
bertragungsverzö ge-rung und deutlich geringere Belastung der
sendenden Rechner – nutzenbisher nur wenige Dienste die Ü
bertragung von Dateien über Multicast.Grund dafür ist, dass die
gesicherte Datenübertragung oberhalb des Best-Efford-IP-Dienstes
immer noch sehr aufwendig ist.Die technische Grundlage für den
Einsatz von Multicasting auf den Proto-kollebenen bis zur
Vermittlungsschicht (ISO/OSI Ebene 3) ist heute schonvollständig
gegeben. Auch ATM bietet mit Punkt-zu-Mehrpunkt-VCs dienotwendigen
Voraussetzungen, um beispielsweise unterhalb der LAN-Emulation 1.0
grundlegende Multicast-Funktionalität zu realisieren. DerEinsatz
von Multicast wird jedoch dadurch eingeschränkt, dass eine
stan-dardisierte, universell verfügbare und problemlos benutzbare
Transport-plattform für die gesicherte Ü bertragung von Daten über
Multicast (ReliableMulticast) fehlt. Marktfähige Software für die
gesicherte Ü bertragung vonDateien über Internet liegt nur begrenzt
vor und weist oftmals erheblicheNachteile gegenüber den
Unicast-Protokollen auf.Die in den USA gegründete IP Multicast
Initiative, der auch Großunterneh-men wie Microsoft, Netscape und
Cisco angehö ren, konzentriert ihre Akti-vitäten auf
Gruppenkommunikation und die ungesicherte Ü bertragung vonAudio-
und Videodaten. Innerhalb der IETF, dem Standardisierungs-„Gremium“
des Internets, werden zugleich in mehreren Arbeitsgruppen undin
einer speziellen Researchgruppe (IRTF) gezielt Verfahren zur
gesicher-ten Datenübertragung diskutiert. Ergebnisse dieser Gruppe
oder gar ent-sprechende Internet-Standards kö nnen jedoch erst
mittelfristig erwartetwerden.Bisher steht Anwendungen, die von den
Vorteilen einer Multicast-Ü bertragung profitieren wollen, als
standardisiertes Transportprotokoll der
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 4
Schicht 4 nur UDP mit der von ihm angebotenen ungesicherten Ü
bertra-gung von Datagrammen zur Verfügung. Viele Anwendungen sind
aller-dings darauf angewiesen, dass die gesendeten Daten lückenlos
bei denEmpfängern ankommen. Dies hat zur Entwicklung von
spezialisierten Pro-tokollen, aufbauend auf UDP, geführt, die die
Dienste von UDP entspre-chend anwendungsspezifisch erweitern. Die
Protokollentwicklung ist jedochaufwendig und gerade für komplexe
Mehrpunktsituationen einer kleinenGruppe von Spezialisten
vorbehalten. So muss bei der Entwicklung vielerAnwendungen heute
noch auf die Verwendung von mehreren Punkt-zu-Punkt-Verbindungen
(„TCP-Fanouts“) zurückgegriffen werden.Auf dieser Basis ist bisher
nur eine sehr begrenzte Anzahl an kommerziel-len Produkten zur
gesicherten Multicastübertragung entwickelt worden. Zunennen wären
hier die Produkte der Firmen Kencast, The Fantastic Corpo-ration,
Deuromedia und Starlight Networks. Aber auch diese Produkte bie-ten
nur einen Bruchteil des für den universellen Einsatz von
Multicasterforderlichen Funktionsumfanges und erfordern eine
spezielle Implemen-tierung auf die Gegebenheiten des jeweiligen
Anwenders. So ist der Ein-satz von IP-Multicast zur gesicherten
Datenübertragung für eine sehr breiteGruppe an potentiellen
Anwendern nur über Eigenentwicklung mö glich.
2.2 ZIELSETZUNGAls Pilotprojekt für die allgemeine Nutzung von
gesicherter Datenübertra-gung über Multicast wird im Rahmen des
Projektes MDiS durch die FirmaTellique Kommunikationstechnik GmbH
und das Technologiezentrum In-formatik der Universität Bremen eine
Plattform zur Verfügung gestellt, diefür verschiedenartige
Anwendungen den Einsatz von zuverlässiger
Multi-cast-Datenübertragung ermö glicht. Kern der Plattform ist das
von der Telli-que Kommunikationstechnik GmbH entwickelte
MulticasttransportprotokollMTP/SO. MTP/SO entspricht den
Empfehlungen des Internet RFC 1301und stellt quasi ein TCP-Pendant
für Mehrpunktkommunikation dar.Im Rahmen von MDiS werden zwei Mö
glichkeiten des Einsatzes vonMTP/SO demonstriert, die beide als
Beispielanwendung die Distributionvon Dateien zum Ziel haben:
• Entwicklung von mdistEines der unter Unix am häufigsten
verwendeten Unicast-Dateiverteilsysteme ist rdist. Im Rahmen von
MDiS wird rdist als Basisfür die Entwicklung eines
Multicast-Dateiverteilsystem unter Nutzungvon MTP/SO verwendet.
Damit wird ein Tool erstellt, durch dass sichMTP/SO einfach in
bestehende, bewährte Systeme integrieren lässt.Nutzer von rdist kö
nnen ohne Ä nderung ihrer bestehenden Systemkon-figuration
Multicast nutzen.
• Piloteinsatz beim DWDFür den Piloteinsatz beim DWD wird zur
Dateiverteilung die von Telli-que auf Basis von MTP/SO entwickelte
Datendistributionssoftware tq® -TELLICAST verwendet. Ü ber tq®
-TELLICAST werden zusätzliche Servi-cefunktionen zur Verfügung
gestellt, die eine Einbindung in Datendistri-butionssysteme wie das
AFD des Deutschen Wetterdienstesentscheidend erleichtern und zudem
über Kompression, Verschlüsse-lung etc. die zentralen Vorteile von
Multicast intensivieren.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 5
Die aktuelle Implementierung von tq® -TELLICAST FileBroadcast
wirdvon Tellique im Rahmen des Projektes in erweiterter Form
bereitgestelltund zusätzlich den Einrichtungen des DFN-Vereins zur
wissenschaftli-chen Nutzung auf der Infrastruktur des Deutschen
Wissenschaftsnet-zes zur Verfügung gestellt. Auf Basis von tq®
-TELLICAST wird durch dasProjekt eine Plattform für
Dateiübertragung als Beispielanwendungentwickelt, die es erlaubt,
Dateigruppen automatisiert auf prinzipiell be-liebig viele
Empfängersysteme zu replizieren. Diese Plattform wird vom Deutschen
Wetterdienst (DWD) als Pilotnut-zer im Rahmen von MDiS erprobt.
Dazu wird das entwickelte Multicast-Distributions-System in die
zentrale Infrastruktur des DWD eingebun-den. Ziel ist unter anderem
die Ü bertragung von im MeteorologischenRechenzentrum in Offenbach
erstellten Modelloutputs (Vorhersageda-ten in hoher Auflö sung) an
6 dezentrale Niederlassungen mit Regional-zentrale sowie in einem
späteren Stadium die Verteilung von kleinerenDatenbeständen an ca.
50 weitere Niederlassungen des DWD. DieDatenraten für die
Verteilung an die dezentralen Niederlassungen in-nerhalb des
Primärnetzes sollen dabei auf einen wesentlichen Teil derderzeit
zur Verfügung stehenden 34 Mbit/s ansteigen. Angesteuert wirddiese
Ü bertragung durch das bereits bestehende Automated File
Distri-butor (AFD) des DWD.
Pilotnutzer im Projekt ist der DWD, langfristig wird jedoch eine
universelle-re Nutzung von reliable Multicast in den Netzen des
DFN-Vereins ange-strebt. Die Tellique Kommunikationstechnik GmbH
und dasTechnologiezentrum Informatik der Universität Bremen kö nnen
durch ihrebisherige direkte Mitarbeit in den Gremien des IETF dafür
garantieren,dass deren derzeitige Forschungsergebnisse in das
Design des beim DWDim MDiS-Projekt zu implementierenden
Multicast-Systems einfließen. Es istweiterhin anzustreben, die
Ergebnisse des für den DWD durchgeführtenProjektes auch in die
Standardisierung einzubringen und damit zur weite-ren universellen
Verbreitung von Multicast in der gesicherten Datenüber-tragung
beizutragen.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 6
3 HINTERGRUNDINFORMATIONEN
3.1 MULTICAST
3.1.1 PrinzipMulticast ist die simultane Verteilung von Daten
von einem Sender an meh-rere definierte Empfänger. Die Daten
brauchen dabei nicht an jeden Emp-fänger einzeln verschickt zu
werden, sondern werden nur einmal in dasNetz „eingestellt“.
Netzkomponenten, wie beispielsweise Router, leiten dieDaten an alle
Empfänger weiter. Dabei leitet bei Bedarf ein Router
bei-spielsweise Kopien eines eingehenden Paketes auf mehreren
anderen In-terfaces („in verschiedene Richtungen“) weiter. Auf den
einzelnenÜ bertragungsstrecken werden die Pakete unabhängig von der
Empfänger-anzahl daher nur einmal übertragen (sofern keine
Paketverluste auftreten).Dadurch wird die Netzauslastung, aber auch
die Belastung des sendendenServers (der sonst so viele Kopien
versenden müsste, wie es Empfängergibt) vermindert.
1
11
222
345
34
34
34
Unicast-Verteilung von einem Sender an 5 Empfä nger
Sender4
3
2
1
4
1
1
2
1
23
1
2
4
3
3
4
2
5
4
3
5
3
4
M
Multicast-Verteilung von einem Sender an 5 Empfä nger
Sender
5
4
3
2
1
M
M
M
M
M
M
M
M
M
M
M
M
MM
MM
M
M
M
Abbildung 1: Unicast und Multicast im Vergleich
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 7
Ein Endpunkt kann auf einer speziellen Multicastadresse Daten
empfangenund senden. Hierfür ist im IP-Adressraum der Nummernraum
224.0.0.0 bis239.255.255.255 vorgesehen („Klasse-D-Adressen“).
Daten, die an eineMulticast-Adresse gesendet werden, werden von
allen Rechnern empfan-gen, die auf dieser Adresse Daten empfangen
wollen.Häufig wird bei Multicast UDP als Transportprotokoll
eingesetzt. TCP ist alsTransportprotokoll für Multicast-Anwendungen
nicht geeignet, da die Pro-tokollmechanismen (z.B. die für
Verbindungsauf- und -abbau und fürEmpfangsbestätigungen) eine
einfache Zweierbeziehung voraussetzen.Eine typische
Multicast-Anwendung ist z.B. die Ü bertragung von Audio-und
Videoinformationen; hier wird auch im Unicast-Fall UDP
eingesetzt.Bei der Verteilung von Daten, bei denen es nicht auf die
Echtzeitfähigkeitankommt, sondern auf dem Empfang aller Daten in
der richtigen Reihen-folge, muss ein anderes Transportprotokoll als
UDP eingesetzt werden (o-der auch der Dienst von UDP,
Fehlererkennung undAnwendungsadressierung, durch ein weiteres
Protokoll ergänzt werden).Hierfür kann das
Multicast-Transportprotokoll MTP/SO verwendet werden.Bei MTP/SO
gibt es einen Master, der steuert, wann welcher Sender Datensenden
darf. Empfängt der Master ein Paket, so gilt es als allgemein
emp-fangen. Empfänger, die die Daten nicht erhalten haben kö nnen
bei ande-ren Kommunikationspartnern diese Daten erneut anfordern.
DurchSteuerpakete vom Master ist genau festgelegt, in welcher
Reihenfolge Pa-kete an die einzelnen bei den Kommunikationspartnern
laufenden Anwen-dungen ausgeliefert werden dürfen.
3.1.2 VorteileDurch die Nutzung von Multicast ergeben sich unter
anderem die folgen-den Vorteile:
• Verringerung der Netzlast und damit insbesondere im
Weitverkehrsbe-reich oftmals erhebliche Einsparungen sowohl für die
Anwender alsauch für die Netzbetreiber.
• Deutliche Verringerung der Ü bertragungsverzö gerung, da die
Datennur einmal übertragen werden, während der Sender bei Unicast-Ü
bertragungen die Daten hintereinander an die einzelnen
Empfängersenden müsste.
• Reduzierte Belastung der sendenden Rechner. Da die Daten nur
ein-fach auszusenden sind, kann ein Rechner simultan auch Tausende
vonEmpfängern erreichen – oftmals wird so eine breitbandige
Versorgunggroßer Ü bertragungsgruppen überhaupt erst mö glich.
Multicast entwickelt sich durch diese Vorteile zu einer
Schlüsseltechnologiefür die Datenübertragung des beginnenden 21.
Jahrhunderts.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 8
3.1.3 AnwendungsgebieteDie mö glichen Anwendungsgebiete sind
vielfältig und beinhalten z. B.
• Versorgung verteilter Organisationen mit aktuellen
Informationsbestän-den
• Realisierung von verteilten/replizierten Datenbanken
• Verteilte/replizierte Dateisysteme
• Softwareverteilung/Softwareupdates
• Groupware, Shared Applications, Audio-/Video-Konferenzen
• Ü bertragung von Daten vom „Information Service Provider“ an
Abon-nenten
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 9
3.2 STANDARDISIERUNGDie massenhafte Verbreitung von
Reliable-Multicast-Anwendungen im In-ternet setzt neben einer
Multicast-Infrastruktur standardisierte Protokollevoraus. Dabei
sind Normen vor allem in zwei Bereichen erforderlich:
• Transportprotokolle für Reliable Multicast
• Geeignete Sicherheitsstandards für große GruppenIn beiden
Bereichen stellte sich Mitte der 1990er Jahre schnell heraus,
daßvor Beginn einer Standardisierung zunächst offene
Forschungsfragen zulö sen waren. Die Aktivitäten wurden daher nicht
sofort in die IETF getra-gen, sondern erst einmal in der Internet
Research Task Force (IRTF) bear-beitet, bis sich jeweils so etwas
wie ein Grundkonsens herausschälte.Abbildung [[[2]]] zeigt dies im
Ü berblick.Die Arbeiten im Bereich des Transportprotokolls in der
IRTF bezogen sichzunächst auf die Entwicklung einer gemeinsamen
Taxonomie, um über-haupt einmal der mö glichen Vielfalt der
Protokolle Herr zu werden. Späterkonzentrierte sich die Reliable
Multicast Research Group (RMRG) auf fürdie Staukontrolle
(congestion control) von Multicast-Strö men geeigneteVerfahren
sowie die Mindestanforderungen, die an solche Verfahren zustellen
sind (Fairness).
MSECuTake up and standardize SMUG work
SMUGuSecurity setup (LKH)–GDOI–GSAKMPuSource authentication
Multicast Security
RMTubulk data transfer– unidirectional– bidirectionalt NORMt
TRACK
RMRGuearly workucongestion control
Reliable Multicast
IETFIRTF
MSECuTake up and standardize SMUG work
SMUGuSecurity setup (LKH)–GDOI–GSAKMPuSource authentication
Multicast Security
RMTubulk data transfer– unidirectional– bidirectionalt NORMt
TRACK
RMRGuearly workucongestion control
Reliable Multicast
IETFIRTF
Abbildung 2: IRTF- und IETF-Aktivitäten in Transport und
Security
Diese Arbeiten waren Ende 1999 so weit fortgeschritten, dass
am16.12.1999 die reliable multicast transport WG (RMT) in der IETF
einge-richtet werden konnte. Dieser Arbeitsgruppe wurde jedoch eine
klare Be-schränkung auf den Bereich des Massendatentransports (bulk
transfer) mitauf den Weg gegeben, da man die Lö sung des
Staukontrollproblems fürden allgemeineren Fall noch nicht absehen
konnte. Damit konnte diese
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 10
Arbeitsgruppe mit ihren Protokollen nicht den Grad an
Flexibilität erreichen,den MTP/SO auszeichnet.RMT entschied sich
wegen der immer noch hohen Zahl von mö glichentechnischen
Alternativen nach einiger Diskussion dafür, die
grundlegendenMechanismen der Protokolle in Form von Building Blocks
(BBs) zu entwi-ckeln, von denen dann mehrere in Protocol
Instantiations (PIs) referenziertund zu einem konkreten Protokoll
ausentwickelt werden sollen.
uTFMCCuPGMCC
uLCCCongestion Control
uGRAu(GRA for CC?)Router Assist
uNORM –(FEC, NORM)uTRACK –(FEC, NORM, TREE)
uALC (LCT)Protocols (PIs)
uFECuNORMuTREE
uFECuLCT
Protocol BBs
Two-wayOne-way
uTFMCCuPGMCC
uLCCCongestion Control
uGRAu(GRA for CC?)Router Assist
uNORM –(FEC, NORM)uTRACK –(FEC, NORM, TREE)
uALC (LCT)Protocols (PIs)
uFECuNORMuTREE
uFECuLCT
Protocol BBs
Two-wayOne-way
Abbildung 3: Das Arbeitsprogramm der IETF-Arbeitsgruppe RMTDie
Arbeiten der RMT-Gruppe spalteten sich schnell in eine auf
Einweg-kommunikation basierende Vorgehensweise
(Digital-Fountain-Modell – eswird kontinuierlich gesendet,
Empfänger kö nnen jederzeit beginnen zuempfangen, bis sie genug
Bits haben, um den Inhalt zu rekonstruieren)und eine klassischere
auf Zweiwegkommunikation basierende Vorgehens-weise. Da für erstere
noch nicht so viele technisch sinnvolle Protokolle aufdem Markt
sind, konnte das Unternehmen Digital Fountain recht schnellEinigung
über diese Protokolle erzielen; dementsprechend sind die Doku-mente
heute (Anfang 2002) bereits in der Nähe des Working Group
LastCall.
Komplexer ist die Situation in der Zweiwegkommunikation. Hier
muß zu-nächst zwischen der klassischen gruppenorientierten
Kommunikation mitnegativen Bestätigungen (NACK-Oriented Reliable
Multicast, NORM) undkomplexeren auf positiven Bestätigungen
beruhenden baumbasierten An-sätzen (Tree-based ACK, TRACK)
unterschieden werden. Nach extensiverDiskussion wurde klar, daß die
TRACK-Lö sung eine Obermenge derNORM-Lö sung werden sollte. Drafts
für beide Normen liegen vor, bedürfenaber noch weiterer Ü
berarbeitung.Eine weitere Schwierigkeit liegt in den
Staukontrollalgorithmen für denZweiwegefall. Neben dem in der RMRG
entwickelten TCP-friendly multi-cast congestion control (TFMCC)
trat mit der SIGCOMM 2000 PGMCC aufden Plan, eine schneller
reagierende Variante der TFMCC-Grundidee, dieaber entsprechend auch
hö here Fluktuationen in der Datenrate mit sichbringt.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 11
Zusammenfassend lässt sich sagen, dass (Stand Anfang 2002) eine
Normfür den Zweiwegfall noch nicht absehbar ist. Wegen der
schwierigen wirt-schaftlichen Situation und der allgemeinen
Desillusionierung bezüglich ei-nes mö glichen Internet-weiten
Einsatzes von Multicast-Technologien wirddie Normung gegenwärtig
auf kleiner Flamme vorangetrieben. Für die ab-sehbare Zukunft ist
das auf RFC1301 basierende Protokoll MTP/SO des-wegen auch
weiterhin als lebensfähige Grundlage für die Entwicklung
vonProdukten im Bereich der Zweiwege-Multicastkommunikation
anzusehen.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 12
4 MULTICAST-DATEIVERTEILUNG Ü BER RDIST MIT MTP/SO
Dieser Abschnitt beschreibt die Entwicklung eines Programms für
die Ver-teilung von Daten per Multicast.Es wäre ein einfaches
Vorhaben gewesen, auf der Basis des ja bereitsrecht
leistungsfähigen Multicast-Transportprotokolls MTP/SO eine
simpleDateiverteilanwendung zu entwickeln. Es bietet sich aber an,
Dateivertei-lung per Multicast genau dort zu verwenden, wo bereits
heute Dateivertei-lung per Unicast im Einsatz ist. Das heute am
häufigsten verwendeteProgramm für diesen Zweck ist das Programm
rdist. Als Namen für dieseszu entwickelnde Programm wählen wir
mdist, da mdist auf dem Quelltextvon rdist basiert.Im folgenden
wird zunächst das Programm rdist beschrieben, welches alsBasis für
mdist verwendet wird. Daran anschließend erfolgt die Beschrei-bung
des Programms mdist, dass über MTP/SO auf Grundlage von rdistdie
Verteilung von Dateien realisiert.
4.1 RDISTRdist wurde im Zusammenhang mit 4.3BSD entwickelt und
ist deswegen inseiner ursprünglichen Form Bestandteil fast aller
modernen UNIX-Systeme. Diese „klassische“ Variante von rdist hat
allerdings einigeschwerwiegende Mängel, so dass heute meist eine
stark verbesserte Ver-sion im Einsatz ist.Basis dieses Projektes
zur Verteilung von Daten über Multicast ist dasProgramm rdist in
der Version 6.1.5. Das Programm dient zur automati-sierten
Verteilung von Daten eines Quellrechners an mehrere Zielrechner.In
einer Konfigurationsdatei kö nnen die Dateien, auch ganze
Verzeichnis-se, angegeben werden, die über das Netz verteilt werden
sollen. Hierbeikö nnen auch Abweichungen auf den einzelnen
Zielrechnern mit angege-ben werden, wie z.B. ein anderes
Zielverzeichnis oder das Ü berspringenbestimmter Dateien oder
Verzeichnisse. Zusätzlich kann noch angegebenwerden, ob neuere
Dateien auf dem Zielrechner überschrieben und aufdem Quellrechner
nicht mehr vorhandene Dateien auf dem Zielrechnergelö scht werden
sollen.Eine weitere wichtige Funktion von rdist ist das Ausführen
von Program-men auf den Zielrechnern nach erfolgreicher Verteilung.
Bei Verteilung vonProgrammen und Bibliotheken eines Linux-Systems
kann mit dieser Funk-tion beispielsweise hinterher automatisch die
Bibliotheken-Datenbank mitdem Aufruf ldconfig auf den aktuellen
Stand gebracht werden.Die Komplexität der Funktionalität von rdist
spiegelt sich in der Konfigurati-onsdatei, dem
Verteilungsmechanismus und dem Programmquelltext wi-der. An vielen
Stellen sind Fallunterscheidungen und Funktionen
mitAusnahmeregelungen zu finden.Beim Start des Programms werden
rdist, die Konfigurationsdatei und e-ventuelle Ä nderungen zu
dieser auf der Kommandozeile übergeben. DieKonfigurationsdatei wird
mit einem mit Hilfe des Parser-Generators yacc(bzw. heute meist
bison) erzeugten Parser in eine C-Datenstruktur übertra-
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 13
gen. Diese Datenstruktur wird nun weiter in die Befehle jedes
Kommandosfür jeden einzelnen Zielrechner zerlegt, immer unter
Berücksichtigung derper Kommandozeile übergeben Ä nderungen. Am
Ende dieser Verfeinerungsteht eine Funktion, die genau ein Kommando
auf einem Zielrechner aus-führt.Das Programm startet nun für jeden
Zielrechner einen eigenen KindPro-zess1, der einen Server2 auf dem
ihm zugewiesenen Zielrechner startet.Diese beiden Prozesse auf
Quell- und Zielrechner tauschen nun Informati-onen und Daten für
das jeweils zu bearbeitende Kommando aus.Der Prozess auf dem
Quellrechner überprüft anhand der Konfiguration, wiedie Datei auf
dem Zielrechner heißen soll und fordert Informationen überdiese
Datei an. Anhand dieser Informationen wird entschieden, ob die
Da-tei übertragen werden muss oder nicht. Die Entscheidung, ob die
Datei ü-bertragen wird oder nicht, liegt beim Zielrechner, denn nur
der rdist-Prozess auf dem Quellrechner weiß, ob neuere Versionen
auf dem Ziel-rechner durch die Version auf dem Quellrechner
überschrieben werdensollen.Falls es sich bei dem Gegenstand der
Verteilung um ein Verzeichnis han-delt, wird anhand des Ä
nderungsdatums überprüft, ob sich neuere Dateienin dem Verzeichnis
befinden. Ist das Verzeichnis geändert worden, gehtrdist rekursiv
alle Dateien innerhalb dieses Verzeichnisses durch und über-prüft
wieder jede einzelne Datei.Dieser Informationsaustausch ist durch
ein auf ASCII basierendes Protokollrealisiert. Als Verbindung
zwischen den Prozessen wird die Standardein-und -ausgabe verwendet.
Ein Kommando besteht aus genau einer Zeile,die mit einem Code für
die Art des Kommandos beginnt. Danach schicktder Server entweder
eine positive (ACK) oder negative (REJ) Bestätigungoder
angeforderte Informationen.Entscheidet der Client, dass die Datei
übertragen werden muss, so teilt eres dem Server mit und startet
die Dateiübertragung.Ist ein Kommando komplett abgearbeitet,
überprüft der Client, ob noch an-dere Kommandos für diesen Server
vorliegen. Ist dies der Fall, werdendiese Kommandos ebenfalls von
diesem Client-Server-Paar bearbeitet.Ein großer Nachteil dieses von
rdist verwendeten Dateiverteilverfahrens ist,dass für jeden Rechner
die Datei separat auf dem Netz übertragen wird.Dieser Nachteil
motiviert die Entwicklung eines auf Multicast basierendesProgramms
zur Dateiverteilung.
1 Dieser KindProzess auf dem Quellrechner wird im folgenden
Client genannt.2 Der Server auf dem Zielrechner ist der
rdist-Daemon rdistd.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 14
4.2 DESIGN VON MDISTUm die Funktionalität von rdist mö glichst
weitgehend zu erhalten, wurdennur wenige Ä nderungen am
Original-Quelltext vorgenommen. Stattdessenwurden separate C-Module
entwickelt, die spezielle Einsprungpunkte fürdie veränderte Aufgabe
von mdist enthalten. Ü ber das Setzen einer Vari-able wird der
mdist-Teil im Programm aktiv. Durch diese „minimal
invasive“Vorgehensweise kann mdist relativ leicht an eine neue
Version von rdistangepaßt werden, sollte der Autor eine
überarbeitete Version verö ffentli-chen3.Ein Hauptproblem war, die
Punkte im Quelltext zu finden, an denen mdist-spezifische
Funktionalität statt des bestehenden rdist-Codes ausgeführtwerden
muss. Das Programm rdist ist stark auf die Unterschiedlichkeit
derZielrechner ausgerichtet. Ein Client überträgt alle jeweils für
ein spezifi-sches Ziel erforderlichen Daten. Bei Multicast sind
aber die einzelnen Ziel-rechner bei der Datenübertragung nicht
unterscheidbar, jeder empfängt dieDaten und muss selbständig
entscheiden, ob es sie annehmen muss odernicht. Daher wurden zwei
grundlegende Design-Ä nderungen vorgenom-men:
• Die Intelligenz, welche Daten übertragen werden müssen,
wurdevom Client zum Server verlagert. Hierzu benö tigt der Server
Infor-mationen über die Kommandos, die Ausnahmeregelungen, Namenauf
dem Quell- und Zielrechner und die Parameter auf der Kom-mandozeile
für eventuelle Ä nderungen.
• Die Ü bertragung der Daten wird komplett am Ende
durchgeführt,nachdem alle Server ihre Liste der Kommandos erhalten
haben.
Kurz bevor die Aushandlung beginnt, welche Daten übertragen
werdensollen, wird in den mdist-Teil des Programmes gesprungen.
Statt mit demZielrechner jede einzelne Datei auszuhandeln und dann
gleich zu übertra-gen, werden dem mdist-Prozess auf dem Zielrechner
die Konfigurations-informationen über diese Aufgabe übermittelt.
Dann wird diese Aufgabeunterbrochen und die Konfigurationsdatei
weiter bearbeitet.Ist die Konfigurationsdatei komplett abgearbeitet
worden, beginnt die Aus-handlung, welche Daten übertragen werden
sollen und danach die eigentli-che Ü bertragung. Der Multicast-Teil
von mdist besteht aus drei Phasen: dieÜ bertragung der
Dateiinformationen vom Client an den Server, die Antwortder Server
mit der Liste der von ihnen benö tigten Dateien und die
eigentli-che Datenübertragung aller benö tigten Dateien vom Client
zu den Servern.
4.2.1 Ü bertragung der Datei-InformationenDer Client ermittelt
eine Liste aller in der Konfiguration angegeben Dateienund
Verzeichnisse. Die Liste besteht nur aus den Namen der Dateien
aufdem Quellrechner; die Umsetzung auf die Dateinamen auf den
Zielrech-
3 Dies ist natürlich nur in begrenztem Umfang m ö glich.
Substantielle Ä nderungen am Design von rdist
erfordernwahrscheinlich ebenfalls eine Ü berarbeitung von mdist, da
mdist auf die internen Datenstrukturen von rdist zu-rückgreift.
Glücklicherweise kann rdist heute als weitgehend stabiles Programm
angesehen werden.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 15
nern kö nnen diese anhand der per Unicast ausgetauschten
Informationenselbständig ermitteln.Zu jeder Datei und jedem
Verzeichnis werden folgende Daten ermittelt undübertragen:
• Name auf dem Quellrechner
• Typ: Verzeichnis, Link oder reguläre Datei
• Dateigrö ße
• Ä nderungsdatum
• Rechte
• Besitzer, sowohl der Name als auch die systeminterne
Kennziffer(UID)
• Gruppe, ebenfalls der Name und die KennzifferDie Ü bertragung
der Namen und Kennziffern bei Besitzer und Gruppe sindnö tig, da
unter Umständen bei einigen Zielrechnern die Kennziffer und
beianderen der Name erhalten bleiben soll, falls diese auf dem
Zielsystemnicht übereinstimmen.Auf Serverseite werden diese
Informationen der anfangs übertragenenKonfiguration zugeordnet bzw.
verworfen, wenn die Datei auf diesem Ser-ver nicht benö tigt wird.
Auf dem Server nicht existierende Verzeichnissewerden in diesem
Schritt angelegt, da an dieser Stelle schon alle relevan-ten
Informationen ausgetauscht wurden.Rdist ist in der Lage, Softlinks
bei der Ü bertragung aufzulö sen. Dadurchkö nnen Softlinks, die auf
Dateien verweisen, die außerhalb des zu vertei-lenden
Verzeichnisses liegen, ebenfalls mit übertragen werden. Es
mussallerdings darauf geachtet werden, dass durch die Softlinks
keine Schleifenbei Verweisen auf Verzeichnisse entstehen. Diese
Funktionalität ist inmdist nicht mehr vorhanden. Dies ergibt sich
aus dieser Art des Informati-onsaustauschs. Bei der Ü bertragung
dieser Informationen werden erst alleDateien an alle Server
geschickt, bevor diese antworten, da es ansonstenzu unnö tigen
Verzö gerungen kommt, wenn erst alle Antworten jeder
Dateiabgewartet werden müssen. Um Schleifen bei Softlinks auf
Verzeichnissezu vermeiden und da es unter Umständen sowohl Server
gibt, die Softlinksaufgelö st haben wollen als auch solche, für die
dies nicht vorgenommenwerden soll, wurde auf diese nicht sehr oft
benö tigte Funktionalität ver-zichtet, da sie das Protokoll sehr
verkompliziert und verlangsamt hätte.
4.2.2 Benö tigte Dateien der ServerNach der Ü bertragung aller
Dateiinformationen wird der Server aktiv undmuss die Liste der von
ihm benö tigten Dateien zurückschicken. Anhandder Konfiguration und
der mö glichen Dateinamen des Quellrechners wer-den die aus Sicht
der Zielrechner zu verwendenden Dateinamen ermittelt4.
4 Je nach Komplexität der Konfiguration kann eine Datei des
Quellrechners an mehreren Stellen beimZiel zu speichern sein.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 16
Nachdem diese Zuordnung durchgeführt ist, wird ermittelt, ob
diese Dateineu übertragen werden muss. Hierbei werden vier Ü
berprüfungen durch-geführt:Die Konfiguration kann eine Liste von
auszuschließenden Dateien und re-gulären Ausdrücken über den
Dateinamen enthalten. Ist der Dateiname indieser Liste, dann wird
keine weitere Ü berprüfung durchgeführt, sonderndie Datei als nicht
benö tigt markiert.Handelt es sich um ein Verzeichnis, das noch
nicht existiert, so wird derDateiname in die Liste der
anzufordernden Dateien aufgenommen. DerClient weiß bei Anforderung
eines Verzeichnisses, dass er alle Dateien undUnterverzeichnisse
dieses Verzeichnisses ebenfalls übertragen muss.Ist die Datei
innerhalb eines noch nicht existierenden Verzeichnisses oderist sie
die selbe Quelldatei wie eine schon als benö tigt markierte Datei,
sowird die Datei in die Liste der zu übertragenen Dateien
aufgenommen, abernicht in die Liste der Anforderungen, die an den
Client geschickt werden.Schließlich werden die weiteren
Informationen über die Quell- und die Ziel-datei ausgewertet.
Hierzu werden Grö ße, Ä nderungsdatum und die Optio-nen der
Konfiguration überprüft. Falls die Datei übertragen werden
muss,wird sie in die Liste der benö tigten und anzufordernden
Dateien aufge-nommen.Die so erstellte Liste der Dateien und
Verzeichnisse des Clients wird nunan diesen zurückgesendet und die
eigentliche Datenübertragung kannstarten.
4.2.3 Datenü bertragungNachdem alle Server die Liste der von
ihnen benö tigten Dateien übertra-gen haben, beginnt die Ü
bertragung aller benö tigten Dateien selbst. AmAnfang wird der
Dateiname auf dem Quellrechner und die Grö ße übertra-gen. Danach
wird diese Datei übertragen und dann die nächste Datei
be-arbeitet.Jeder Zielrechner empfängt alle Dateien. Er muss dann
selbständig ent-scheiden, ob er sie speichern muss oder nicht. Die
Informationen über dieRechte, die diese Datei bekommt, erhält der
Server aus den Informationen,die in Phase 1 ausgetauscht
wurden.
4.2.4 Verwendung von rdist zur abschließ enden
FehlerbehebungWährend der Multicast-Ü bertragung kann durch längere
Ausfälle der Multi-cast-Konnektivität der Fall auftreten, dass ein
oder mehrere Zielrechner dieÜ bertragung nicht komplett erhalten.
Sie ziehen sich bei Problemen ausder Multicast-Ü bertragung zurück
und melden dem Client, dass sie dieDaten nicht empfangen kö
nnen.Nachdem die Multicast-Ü bertragung abgeschlossen ist, wird die
Variable,die den mdist-Teil des Programms aktiviert, auf die
Verwendung des rdist-Protokolls zurückgesetzt. Danach wird das
Programm mit den nicht abge-schlossenen Operationen als rdist noch
einmal gestartet; damit werden et-waige Lücken der Multicast-Ü
bertragung automatisch behoben.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 17
4.2.5 Programmdokumentation zu mdistDer mdist-Teil des Programms
besteht aus vier C-Modulen: mtp, mclient,mserver und mparser.Der
mtp-Teil sorgt für die Multicast-Ü bertragung auf Basis der
Bibliothekmtpso. Er enthält Hilfsfunktionen für die Initialisierung
eines mtpso-Multicast-Sockets und für das Senden und Empfangen von
Daten. DieseFunktionen werden vom mserver und dem mclient
verwendet.Die Module mclient und mserver enthalten den eigentlichen
mdist-Teil desProgramms. Sie enthalten die Funktionen, die vom
Original-rdist ange-sprungen werden. Für die Parsierung der
Datenströ me für den Informati-onsaustausch wird das Objekt mparser
verwendet. Es enthält Funktionen,um interne Datenstrukturen in
Zeichenketten und zurück zu übersetzen.
4.2.6 ProtokollbeschreibungDie Unicast- und die verschiedenen
Phasen der Multicast-Ü bertragung set-zen verschiedene Protokolle
für die Datenübertragung ein. Die Ü bertra-gung der Konfiguration
und der Dateiinformationen ist ein auf ASCIIaufsetzendes,
zeilenorientiertes Protokoll. Die verschiedenen Informatio-nen
werden durch Leerzeichen getrennt, Zahlen in menschenlesbarerForm
übertragen. Zeichenketten, die wiederum Leerzeichen enthalten kö
n-nen, enthalten eine zusätzliche Längenangabe, um sie wieder
korrekt ext-rahieren zu kö nnen.Jede Zeichenkette beginnt wie bei
rdist auch mit einem Zeichen, welchesdie Art der Zeile beschreibt.
Die einzelnen Codes sind in der nachfolgen-den Tabelle
aufgelistet.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 18
4.2.7 Bewertung des ErgebnissesMdist ist ein auf der Basis von
rdist entwickeltes System zur Dateiverteilungper Multicast. Der
Ansatz, nicht ein vö llig neues Tool zu entwickeln, son-dern auf
rdist einzusetzen, bietet Anwendern von rdist eine sehr
einfacheMigrationsstrategie in Richtung Nutzung von Multicast zur
Dateiverteilung.Projekte, die z.B. im Wissenschaftsnetz des DFN grö
ßere Dateien regel-mäßig verteilen wollen, erhalten mit mdist ein
Tool, das die benö tigtenBandbreiten deutlich reduzieren kann.Rdist
ist natürlich nicht das einzige Tool zur Dateiverteilung, das als
Basisfür die Entwicklung von mdist hätte dienen kö nnen. Ein
anderes heute weitverbreitetes Programm zur Dateiübertragung ist
rsync. Statt rdist hätteauch rsync auf Multicast-Verteilung
angepaßt werden kö nnen. Im Gegen-satz zu rdist ist rsync aber
allein auf die Verteilung ausgerichtet und hatweniger
Sonderfunktionen für den Einsatz in grö ßeren Netzen; so kannrsync
beispielsweise nach erfolgreicher Verteilung nicht Programme
zurendgültigen Installation der verteilten Dateien ausführen. Die
grundsätzli-che Idee von rsync, durch Ü berprüfung partieller
Prüfsummen der Dateiin-halte Ü bertragungskapazität einzusparen
(Tridgell, A. and Mackerras, P.,„The rsync algorithm“. Technical
Report TR-CS-96-05, Dept. ComputerScience, ANU, 1996), bietet im
Multicast-Fall auch weniger Vorteile.Die Entscheidung, rdist als
Basis für das Programm mdist zu verwenden,ist jedoch nicht nur mit
Vorteilen verbunden. Einerseits wird in vielen Infra-strukturen
heute rdist eingesetzt und dementsprechend ist in vielen
Orga-nisationen signifikanter Aufwand investiert worden in die
Entwicklung vonrdist-Konfigurationsdateien, die nun mit mdist
einfach unverändert über-nommen werden kö nnen. Die
Funktionsvielfalt von rdist macht auch mdistzu einem mächtigen
Werkzeug für die Verteilung von Daten.Diese Funktionsvielfalt und
die damit einhergehende Komplexität ist ande-rerseits auch einer
der grö ßten Nachteile des entstandenen Systems. DerQuellcode von
rdist ist an vielen Stellen sehr verwickelt und daher
unüber-sichtlich. Da die Intelligenz bei mdist im Server und nicht
wie bei rdist imClient steckt, mussten allerlei Funktionen neu
implementiert werden. Durchdie Komplexität ist es auch sehr
schwierig, alle denkbaren Spezialfälle zutesten, weil sie abhängig
von der jeweiligen Anwendung sind und derPhantasie der Anwender bei
der Anwendung der rdist-Konfigurationssyntaxkaum Grenzen gesetzt
sind.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 19
5 MULTICAST-DATEIVERTEILUNG DURCH tq®-TELLICAST
5.1 PRODUKTAUFBAU tq®-TELLICASTtq® -TELLICAST ist ein
Multicastübertragungssystem, das auf MTP/SO
alsMulticast-Transportprotokoll basiert. Es besteht aus
verschiedenen Modu-len, die die Ü bertragung unterschiedlicher
Inhalte ermö glichen:
Abbildung 4: Produktmodule von tq®-TELLICASTDer modulare
Produktaufbau ermö glicht den Einsatz des Systems in einerVielzahl
unterschiedlicher Einsatzbereiche und zugleich den gezielten
Ein-satz auf die jeweilige Content-Art angepaßter Module für das
jeweiligeProjekt. Für den Einsatz im DWD wird die Funktionalität
von tq® -TELLICASTauf das Modul FileBroadcast beschränkt.Alle
Module von tq® -TELLICAST weisen neben bzw. durch die Verwendungvon
MTP/SO die folgenden Sevicefunktionen auf, die zugleich die Basis
fürdie Einbindung in das Dateiübertragungssystem des DWD
darstellen:
• zeit- und prioritätenkontrollierte Steuerung durch einen
zentralen Sche-duler
• Ü bertragung in logischen Kanälen (Channel), die u. a. die
Festlegungvon maximalen Bandbreiten pro Channel erlauben
• zentrale Bandbreitensteuerung (Ü berwachung der
Gesamtband-breite,Koordinierung paralleler Sendeaufträge)
• Datenkomprimierung „on the fly“, d. h. während der Ü
bertragung undsomit ohne zusätzliche Verzö gerung
• Datenverschlüsselung „on the fly“
• gesicherte Datenübertragung mit gezielten Retransmissions
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 20
• Ü berwachung durch ein webbasiertes Interface und
Log-Dateien
• Ausgabe von für das Accounting relevanten Daten in spezifische
Datei-en
5.2 FUNKTIONSWEISEDer tq® -TELLICAST Sender ermö glicht die
Multicast-Ü bertragung von Da-teien an mehrere Empfänger. Die Daten
werden als Dateien, Dateiver-zeichnisbäume oder – für Datenströ me
wie z. B. Bö rsenticker – alstransparenter Datenstrom
übermittelt.Die Ü bertragung erfolgt auf einer per-Channel-Basis,
d. h. der physikali-sche Kanal kann in viele logische Channel
unterteilt werden. Für jedenChannel werden über Channel Files
spezifische Parameter wie Bandbreite,Kompression etc. festgelegt.
Die Channel Files enthalten auch eine Refe-renz auf ein oder
mehrere Recipient Files. Die Recipient Files sind Emp-fängerlisten.
Alle Empfänger in den durch das Channel File
referenziertenRecipient Files kö nnen die Daten dieses Channels
empfangen.
5.2.1 Initialisierung / AnnouncementsÜ ber einen Announcement
Channel informiert der Sender die Empfängerkontinuierlich über alle
anstehenden Ü bertragungen. Dazu gehö rt bei-spielsweise die:
• Ankündigung aller Ü bertragungen vor dem Datenaustausch,
• Verteilung der Datenschlüssel für verschlüsselte Ü
bertragungen und
• Auffordern der Empfänger, Bestätigungen für die erhaltenen
Daten zusenden.
Insgesamt hat der Announcement-Channel die Aufgabe, die Menge
der aufden Empfängern zu konfigurierenden Daten mö glichst klein zu
halten unddie notwendigen Informationen stattdessen automatisch vom
Sender zuempfangen.
5.2.2 Ü bertragung
SenderDie Ü bertragung wird durch sogenannte Job Files
angesteuert. Als Jobwird die Ü bertragung einer bestimmten
Datenmenge an eine spezifizierteGruppe von Empfängern bezeichnet.
Ein Job File definiert die Parameter,die für die Administration und
Ausführung einer spezifischen Datenübertra-gung notwendig sind.Der
tq® -TELLICAST Sender liest kontinuierlich neue Job Files aus dem
Ver-zeichnis „jobs/incoming“ ein. Ein neuer Job wird ausgewertet
und kontrol-liert, mit Systemparametern erweitert und in das
Verzeichnis„jobs/scheduled“ verschoben.Solange ein Job aktiv ist,
verbleibt er im Verzeichnis „jobs/scheduled“. Deraktuelle Zustand
der Jobs wird regelmäßig in den Job Files im
Verzeichnis„jobs/scheduled“ zwischengespeichert. Dies ermö glicht
die Fortführung der
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 21
Ü bertragung nach einem Neustart des Systems an weitgehendst der
sel-ben Stelle, an der die Unterbrechung erfolgte.Nachdem ein Job
beendet wurde, wird das entsprechende Job File in dasVerzeichnis
„jobs/done“ verschoben, um das Ende der Ü bertragung anzu-zeigen.
Job Files im Verzeichnis „jobs/done“ werden nicht länger vomSystem
verwendet und kö nnen entfernt oder geändert werden.
tq®-TELLICAST SenderMTP/SO
jobs/incoming
job/scheduled
jobs/done
FIFO Queue (Messages)
Files
data
channels
send.log
accounting.dat
JOB
recipients
tq®-TELLICASTEmpfä ngerMTP/SO
recv.log
data
send.ini
recv.ini
Ann
ounc
emen
tcha
nnel
Abbildung 5: Dateienü bertragung mit tq®-TELLICAST
EmpfängerBeim Systemstart ö ffnet der Empfänger den allgemeinen
AnnouncementChannel und wartet auf die Verteilung von Schlüsseln
(bei aktivierter Da-tenverschlüsselung), Ü bertragungsankündigungen
und Empfangsaufforde-rungen. Erfolgt eine Empfangsaufforderung, so
werden die Daten auf demangekündigten Kanal empfangen.Die
empfangenen Dateien und Verzeichnisse werden unter dem selbenNamen
und unter den selben Unterverzeichnissen abgelegt, die auch
derSender benutzt, jedoch in Relation zu einem kanalspezifischen
Startver-zeichnis, das pro Empfänger gesondert konfiguriert werden
kann.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 22
6 ANWENDUNGSFALL DWD
Kernbestandteil des Projektes MDiS war die Realisierung von
Multicast-Datenübertragung innerhalb der bisher über AFD
erfolgenden Datenver-teilung des DWD.Dieses Kapitel gibt zunächst
einen groben Ü berblick über die zugrunde lie-gende
Kommunikationsinfrastruktur des DWD und die Anforderungen, dievon
Seiten des DWD an eine Multicast-Datenverteilung gestellt
werden.Auf dieser Basis wird dann die Zielarchitektur
vorgestellt.
6.1 DATENVERTEILUNG IM DWDIm Folgenden wird ein Ü berblick über
die Kommunikationsinfrastruktur unddie Datenverteilung innerhalb
des DWD gegeben, sofern diese für MDiSrelevant sind.
6.1.1 Beteiligte Netzstrukturen
6.1.1.1 Primärnetz
Das Primärnetz verbindet ringfö rmig die Zentrale des DWDs in
Offenbachmit den 6 dezentralen Niederlassungen mit Regionalzentrale
in Essen,Hamburg, Potsdam, Leipzig, München und Stuttgart. Die
Standleitungendes Primärnetzes haben im derzeitigen Ausbau eine
Bandbreite von 34MByte/s, von denen 8 Mbit/s zur Datenverteilung
der angebundenen ande-ren Behö rden des Bundesministeriums für
Verkehr, Bau- und Wohnungs-wesen (BVBW) reserviert sind.Den
überwiegenden Anteil der Datenübertragung innerhalb des
Primärnet-zes macht die Datenversorgung der dezentralen
Niederlassungen mit Re-gionalzentrale aus, wobei die
Datenbanktransaktionen nur einengeringeren Anteil ausmachen,
während die Dateiverteilung den grö ßtenTeil des Datenvolumens benö
tigt (im Endausbau bis 12 Gbyte Daten).In Rückrichtung von den
dezentralen Niederlassungen mit Regionalzent-rale an die Zentrale
in Offenbach erfolgt die Ü bertragung von Messdaten,z. B. der
Radarstandorte. Die benö tigte Bandbreite ist jedoch viel
geringerals die für die Produktverteilung von der Zentrale an die
Niederlassungenmit Regionalzentrale.
6.1.1.2 Sekundärnetz
Das Sekundärnetz verbindet weitere grö ßere Standorte des DWDs
überStandleitungen mit den dezentralen Niederlassungen mit
Regionalzentrale.Dies sind vor allem Flugwetterwarten,
Radarstandorte und Observatorien.Die Bandbreite dieser Verbindungen
ist mit 64 kbit/s geringer als die desPrimärnetzes. Es erfolgt je
nach der Auslegung des Standortes eine Ü ber-tragung von der
Zentrale an die Standorte und/oder Ü bermittlung vonMessdaten an
die Zentrale.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 23
Abbildung 6: Primärnetz und Sekundärnetz des DWDs
6.1.2 Datendistribution ü ber AFDAFD ist ein vom DWD
entwickeltes Dateidistributionssystem, das sowohldie
Datenübertragung innerhalb des Primär- und Sekundärnetzes als
auchTeile der Kundenversorgung und des internationalen Austausches
vonmeteorologischen Daten steuert und durchführt.Ü ber den
Automated File Distributor (AFD) werden die Produkte von
derZentrale in Offenbach aus an alle Niederlassungen verschickt.
Dabei be-achtet AFD die physikalische Ringstruktur des
Primärnetzes, indem dieDaten von Regionalzentrale zu
Regionalzentrale weitergereicht werden. Sosendet die Zentrale die
Daten nur an die beiden nächstgelegenen Regio-nalzentralen. In
einer Regionalzentrale werden die Daten sowohl regionalverteilt als
auch sofort an die auf dem Ring nachfolgende
Regionalzentralegesendet. Dadurch erfolgt die Verteilung der Daten
in die DWD-Fläche ü-ber zwei „Halbringe“, nämlich über Essen und
Hamburg nach Potsdam undüber Stuttgart und München nach Leipzig.Bei
dieser Verteilstruktur ergeben sich Probleme bei Ausfall einer
Regio-nalzentrale, da dann die auf dem Ring nachfolgenden
Regionalzentralennicht versorgt werden. In diesem Fall werden die
Daten vom Endpunkt ei-nes „Halbringes“ an die nachfolgende
Regionalzentrale, also z. B. vonPotsdam nach Leipzig, gesendet.
Dies ist durch einfache Operatoranwei-sungen am jeweiligen AFD zu
erreichen.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 24
Jede Niederlassung besitzt einen Backup-Rechner für den Rechner,
aufdem die Daten eingehen. Die Zugangsdaten und Zielverzeichnisse
diesesRechners sind mit denen des eigentlichen Empfangsrechners
identisch.Der Backup-Rechner wird von AFD versorgt, sobald der
ursprünglicheEmpfangsrechner ausfällt.
6.1.3 ISDN-FailoverBei Ausfall von Standleitungen des
ATM-basierten AFD-Systems werdendie Daten an die betroffenen
Rechner über ISDN übertragen. Die ISDN-Ü bertragung wird mit einer
sehr viel geringeren Bandbreite als die primäreAFD-Ü bertragung
realisiert (unter Einsatz von Kanalbündelung bis zu2Mbit/s zu einem
Standort).Die Datenserver empfangen nicht nur über das interne
ATM-Interface di-rekt Daten aus dem Primärnetz, sondern sind
zusätzlich über ein Ethernet-Interface an das lokale LAN
angebunden, über das sie u.a. auch die imFailover-Fall über ISDN
übertragenen Daten empfangen kö nnen.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 25
6.2 GEPLANTE DATENÜ BERTRAGUNG Ü BER MULTICAST
6.2.1 Vorgesehener EinsatzbereichMulticast soll zunächst nur für
die DWD-interne Datenübertragung einge-setzt werden. Für die Ü
bermittlung von Daten an Kunden kann diesesVerfahren ggf. in einer
späteren Ausbaustufe und evtl. kombiniert mit Sa-tellitendiensten
erweitert eingesetzt werden.Im Rahmen von MDiS soll die
Multicast-Datenübertragung im Primärnetzrealisiert werden. Das
Sekundärnetz wird im Rahmen des Projektes nurversuchsweise und
voraussichtlich zunächst nur an einem Standort durch-geführt, mit
dem Ziel, die Einsetzbarkeit in diesem Bereich
sicherzustellen.Damit ergeben sich folgende Einsatzbereiche für
Multicast:
• Ü bertragung von Daten von der Zentrale in Offenbach an die
Daten-Server in den Niederlassungen mit Regionalzentrale.
• Ü bertragung der von den Stationen des Sekundärnetzes an den
Regi-onalzentralen eingehenden Daten von den Regionalzentralen an
dieZentrale in Offenbach.
Die Ü bertragung der Daten erfolgt auf Sendeseite über
Vermittlung durchAFD, d. h. es wird eine
Datei-/Verzeichnis-basierte Schnittstelle definiert,über die AFD
einzelne Ü bertragungsaufträge an das Multicastsystem wei-tergibt.
Dabei ist es alternativ mö glich, auch direkt von anderen
Systemen(außer AFD) Daten zur Ü bertragung an das Multicastsystem
weiter-zugeben.Auf Empfängerseite sind zunächst die Daten-Server
als Empfänger vorge-sehen. In einem späteren Schritt (außerhalb des
MDiS-Projektes) werdendirekt die Applikationsrechner als
zusätzliche Empfänger eingerichtet. DieÜ bertragung erfolgt
parallel an beide Daten-Server, da dies über Multicastkeine Erhö
hung der Bandbreite gegenüber der Ü bermittlung von Daten aneinen
einzelnen Rechner darstellt und so eine hohe Ausfallsicherung
er-reicht werden kann.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 26
6.2.2 AnforderungenFür die Realisierung des Multicastsystems
ergeben sich folgende grundle-gende Anforderungen von Seiten des
DWDs:
• Jede Regionalzentrale muss als Empfänger und als Sender
fungierenkö nnen, d. h. das System muss mehrere Sender zulassen,
die zentralkoordiniert werden.
• Eine Ü bertragung muss parallel an mehrere Rechner in den
Regional-zentralen erfolgen kö nnen.
• Auf den Zielrechnern werden die Daten vom Multicastsystem in
einempro Ü bertragungschannel definierbaren Zielverzeichnis
angelegt. Eineweitere Unterverteilung erfolgt bei Bedarf durch
AFD.
• Die Ü bertragung der Daten muss bandbreitengesteuert und
prioritäten-gesteuert erfolgen kö nnen.
• Die ISDN-Ü bertragung als Backup muss realisierbar sein.
• Das Multicastsystem soll eine Schnittstelle zum Abfragen von
Zu-standsinformationen bieten. Ziel ist es, über ein Graphical User
Inter-face (GUI) die Sendezustände der beteiligten Rechner abfragen
zukö nnen. Das GUI wird vom DWD ähnlich dem AFD GUI entwickelt.
• Die unterschiedlichen Bandbreiten für das Sekundärnetz und das
Pri-märnetz sowie für eine Failover-Ü bertragung über ISDN müssen
durchdie Definition mehrerer Channel (Multicast-Ü
bertragungsgruppen) undpotentiell unterschiedlicher Bandbreiten pro
Ü bertragungsgruppe abge-bildet werden kö nnen.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 27
6.3 ZIELARCHITEKTUR
6.3.1 Integration von tq®-TELLICAST und AFDZiel des zu
entwickelnden Multicast-Distributionssystems ist es, angesteu-ert
durch AFD, einen gesicherten Multicast-Ü bertragungsdienst für
mehre-re Gruppen anzubieten und dadurch neben z. B. Unicast-FTP
einenweiteren Ü bertragungspfad zur Verfügung zu stellen.MTP/SO
setzt dabei auf UDP auf. Zwischen dem Service-Layer vonMTP/SO, tq®
-TELLICAST, und AFD wird zur Schnittstellensteuerung ein
A-daptation-Layer implementiert, der im folgenden als
Multicast-DistributionLayer (MD) bezeichnet wird.
AFD
IP
FTP
TCP
UDP
Adaptation-Layer(MD = Multicast-Distribution)
MTP/SO
tq®-TELLICAST
Abbildung 7: Schichtenmodell zur Einbindung von Multicast in
AFDDie folgenden Ausführungen beschreiben darauf aufbauend die Ü
bergabeder Daten vom AFD-System über MD an tq® -TELLICAST und die
Rückmel-dung des Sendeerfolgs von tq® -TELLICAST über MD an das zu
entwickeln-de MDiS-GUI.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 28
6.3.2 Schnittstelle zur Datenü bertragung: MDDie Schnittstelle
zwischen AFD und tq® -TELLICAST ist ein neu zu imple-mentierender
Prozess „Multicast Distribution Layer“ (MD) und ein bereitsnach
Channeln organisierter Dateibaum.
6.3.2.1 Schnittstelle auf Senderseite
AFD (oder zukünftig auch andere Systeme) stellen die zu
übertragendenDateien auf Sendeseite in Channel Directories ein. Für
jeden definiertenÜ bertragungschannel wird hierfür auf Sendeseite
ein Channel Directoryvorgesehen (siehe Abbildung 8).Der Prozess MD
scannt die Channel Directories (einschließlich enthaltenerDateien
und Unterverzeichnisse) kontinuierlich. Alle dort neu erkannten
o-der modifizierten Dateien werden zu Sendeaufträgen (Jobs)
zusammen-gefasst und über Job-Files zur eigentlichen Multicast-Ü
bertragung an tq® -TELLICAST übergeben.Entsprechend der genutzten
Channel-Directories überträgt tq® -TELLICASTdie Dateien auf dem
jeweiligen Ü bertragungs-Channel.Die GUI (oder alternativ auch ein
anderer Prozess) verbinden sich über ei-nen TCP-Server-Port mit dem
MD und rufen die Daten zum aktuellenStand der Ü bertragungen über
ein ASCII-basiertes Protokoll ab.
JOBs
AFD GUI
Multicast Distribution MD
tq®-TELLICASTSender
(MTP/SO)
FilesTCP/ASCII
AFDEinstellen
von Dateienzur Ü bertragung(ggf. als Links)
ChannelDirectories
Scannen
Löschen
Namenskonvention:.* = temporäre Dateien
Lesen
Multicast-Ü bertragung
ChannelDefinitionen
ReceiverDefinitionen
MD-SEND.INI
Abbildung 8: Schnittstellen zwischen AFD und tq®-TELLICAST
Sender
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 29
6.3.2.2 Schnittstelle auf Empfängerseite
Empfängerseitig empfängt tq® -TELLICAST den
Multicast-AnnouncementChannel sowie die für diesen Empfänger
konfigurierten Multicast-Data-Channel.Welche Channel von einem
Receiver empfangen werden, kann vom Admi-nistrator durch eine
Receiver-Channel-Definitionsdatei festgelegt werden.In dieser
Definitionsdatei ist neben den zu empfangenden Channeln u.a.auch
pro Channel ein Verzeichnis konfiguriert, in das die auf
diesemChannel empfangenen Dateien abgelegt werden sollen.Der
Prozess MD hat auf Empfangsseite vorwiegend die Aufgabe, die in
ei-nem MDiS-spezifischen Format angegebenen Channel-Definitionen
sowiedie Parameter einer zentralen md-recv.ini Datei in die tq®
-TELLICAST spe-zifischen Konfigurationsdateien umzuwandeln. Dabei
kö nnen auf Emp-fangsseite, ebenso wie auf Senderseite, die Angaben
in der ChannelDefinitionsdatei überwiegend auch zur Laufzeit ohne
einen Neustart derMD/ tq® -TELLICAST Prozesse vom Operator geändert
und neu übergebenwerden.tq® -TELLICAST legt die empfangenen Dateien
direkt in dem für den jeweili-gen Channel angegebenen Verzeichnis
ab. In diesem Verzeichnis stehensie für andere Anwendungen zur
Nutzung oder AFD zur weiteren Vertei-lung zur Verfügung. Ein Lö
schen dieser Dateien erfolgt durch AFD oderzukünftig ggf. auch
alternative Systeme.
Multicast Distribution MD
tq®-TELLICASTReceiver(MTP/SO)
Files
AFDLöschen
durch AFDoder„ Nutz-
anwendungen“
ChannelDirectories
Scannen
Namenskonvention:.* = temporäre Dateien
Schreiben
Multicast-Ü bertragung
ChannelDefinitionen
MD-RECV.INI
ISDN Fallback Control
Abbildung 9: Schnittstellen zwischen AFD und tq®-TELLICAST
Receiver
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 30
6.4 GESICHERTE DATENÜ BERTRAGUNGDie gesicherte Ü bertragung der
Daten durch MDiS ist, neben der gleich-zeitigen Ü bertragung an
Daten-Server und Backup-Rechner, durch vierMechanismen
gewährleistet:
• Forward Error Correction (FEC),
• Anforderung von Datenpaketen über „Negative
Acknowledgements“(NAK),
• Retransmission auf Grundlage von Acknowledgements und
• das ISDN-Backup-System des DWD.
6.4.1 Forward Error CorrectionFEC gewährleistet den Ausgleich
von Ü bertragungslücken auch bei Fehleneines Rückkanals, wie z. B.
bei Satellitenübertragungen. Vorteil im zu-nächst ausschließlich
terrestrischen Einsatz des DWD ist, dass Ü bertra-gungsfehler
(fehlende Pakete) durch den Einsatz von FEC behobenwerden kö nnen,
ohne dass einer oder sogar mehrere der Empfänger expli-zite NAKs
(negative Empfangsbestätigungen) an den Sender zurücksen-den
müssen.Der Sender generiert auf Ebene von MTP/SO FEC
Redundanzpakete ausden Daten mehrerer Datenpakete, die zusammen mit
den eigentlichenDaten übertragen werden, und aus denen sich
fehlende Datenpakete er-rechnen lassen.Die Generierung der
Redundanzpakete erfolgt „on the fly“ und unmittelbarwährend der Ü
bertragung.
6.4.2 Negative Acknowledgements (NAK)Wenn einzelne Datenpakete
nicht empfangen werden, fordert der Empfän-ger das Paket durch
Senden eines NAKs neu an. Das fehlende Paket wirddaraufhin noch
einmal übertragen. Diese Kontrolle des Datenempfangswird auf der
Ebene von MTP/SO realisiert.
6.4.2.1 Bandbreitenkontrolle für NAK
Der Verbrauch von Bandbreite durch NAK-gesteuerte
Paketanforderungenist schwer vorhersehbar. Starke Empfangsstö
rungen einzelner Empfängerkö nnen zu einer hohen Belastung der
Bandbreite des Channels führen, vorallem wenn sehr viele Empfänger
zum Empfang eines Channels berechtigtsind.Für diese großen
Empfängergruppen kann die Belastung des Sendersdurch die
Beantwortung von NAK-Anfragen durch Repetitoren verringertwerden.
Als Repetitoren werden Empfänger bezeichnet, die nicht nur dieDaten
empfangen, sondern außerdem gegenüber anderen Empfängern alsSender
fungieren und deren NAK beantworten. Die Bandbreite zum Sen-der hin
wird damit entlastet, da der Sender nur noch die NAK des
Repeti-tors erhält, während die NAK aller Empfänger im
Einzugsbereich desRepetitors von diesem beantwortet werden.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 31
Die NAKs werden von den Empfängern, die dem Repetitor
zugeordnetsind, zunächst mit einer geringen TTL (time to live;
Anzahl der Router, dieein Datenpaket passieren kann) gesendet.
Dadurch ist gewährleistet, dasssie nur bis zum Repetitor übertragen
werden und den Sender nicht mehrerreichen. Nur in dem Fall, dass
der Repetitor ausfällt und die fehlendenDatenpakete nicht an den
Empfänger überträgt, sendet dieser die NAKsnoch einmal mit hö herer
TTL aus, so dass eine Anfrage beim Sender er-folgt
Sender
Empfä nger
Empfä nger
Empfä ngerEmpfä nger/
Repetitor
Empfä nger
Empfä nger
Empfä nger
Empfä nger
Sender
ohne Repetitor mit Repetitor
Abbildung 10: NAK-Retransmissions ohne und mit RepetitorIn die
Regulation der Gesamtbandbreite für die Ü bertragung und die
Da-tensicherung pro Ü bertragung muss sowohl die Bandbreite der
NAK-Retransmissions zwischen Sender und Empfängern als auch die
zwischenRepetitoren und Empfängern einbezogen werden. Dies erfolgt
durch dieKonfiguration eines festen erlaubten Prozentsatzes der
Gesamtbandbreitefür jeden der erwähnten Datensicherungsmechanismen
pro Channel. Da-bei wird der Prozentsatz der Bandbreite für FEC und
Packet Retransmissi-on von der im Sender konfigurierten maximalen
zulässigen Bandbreite fürden Channel abgezogen, wobei die
FEC-Bandbreite konstant von FEC ge-nutzt wird, während die für
Packet Retransmission nur im Bedarfsfall abge-zogen wird, d. h. die
Bandbreite steht sonst für die eigentliche Ü bertragungzur
Verfügung.Die Bandbreite für Repetitor Packet Retransmission wird
im Gegensatz da-zu auf die momentane Bandbreite des Channels
aufgerechnet. Der Anteilan Repetitor Packet Retransmission kann in
allen Repetitorgruppen indivi-duell konfiguriert werden.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 32
Cha
nnel
band
brei
te
% Bandbreite fü r FEC
% max. genutzte Bandbreite fü r Repetitor Packet
Retransmission
% max. genutzte Bandbreite fü r Packet Retransmission
lokal max.hinzugefü gtm
ax.
genu
tzte
Ban
dbre
ite
/ C
hann
el
Abbildung 11: Einteilung der Channelbandbreite unterBerü
cksichtigung von Datensicherungsmechanismen
6.4.3 Steuerung von Retransmissionstq® -TELLICAST kann so
konfiguriert werden, dass die Empfänger den voll-ständigen Empfang
der übertragenen Dateien durch Acknowledgementsbestätigen. Fehlen
die Acknowledgements von einzelnen oder mehrerenEmpfängern, kann
die Ü bertragung von tq® -TELLICAST wiederholt werden.Dabei kann in
den Job Files eine maximale Anzahl an Ü bertragungswie-derholungen
konfiguriert werden.Für die Multicastübertragung in MDiS ist es
wünschenswert, dass dieSteuerung der Retransmissions von MD und
nicht von tq® -TELLICAST vor-genommen wird. tq® -TELLICAST
überträgt daher die Daten nur einmal. Dieeingegangenen
Acknowledgements für diese Ü bertragung werden von MDaus dem Job
File ausgelesen, sobald dieses im „jobs/done“-Verzeichniserscheint.
Retransmission an die Empfänger, die den Empfang der Datennicht
bestätigt haben, erfolgt durch die Generierung eines neuen Job
Filesdurch MD. Dies hat die folgenden Vorteile gegenüber der
automatischenRetransmission durch tq® -TELLICAST innerhalb eines
einzigen Jobs:
• Der Status der Ü bertragung wird nach jeder einzelnen Ü
bertragung anMD weitergegeben und kann an die GUI nach Anfrage
weitergeleitetwerden.
• Die Priorität der Retransmissions kann gegenüber der Priorität
derErstübertragung herabgesetzt werden. Da für den Wetterdienst
beson-ders die letzten, aktuellen Daten wichtig sind, kö nnen
dadurch neu ein-gehende Sendeaufträge vor den Retransmissionen
alter Datenübertragen werden, weil sie die hö here Priorität
besitzen.
Die Empfängerliste für die Retransmission kann gezielter auf die
Empfän-ger beschränkt werden, die keine Acknowledgements gesendet
haben.
6.4.4 Realisierung des ISDN-BackupsDie Daten werden über 2
verschiedene Multicastadressen auf 2 Channelnvon tq® -TELLICAST
gesendet:
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 33
• Die wichtigsten Daten werden konstant über einen
Multicast-Channelgesendet, der sowohl über ATM als auch über ISDN
geroutet werdenkann, und der im normalen Betrieb über ATM und bei
Bedarf automa-tisch über ISDN geroutet wird.
• Die weiteren Daten werden über einen zweiten Channel
übertragen, dernur über ATM geroutet wird, daher über ISDN/Ethernet
nicht empfan-gen werden kann und somit auch keine Bandbreite der
ISDN-Verbindung in Anspruch nimmt.
Solange über ATM empfangen werden kann, gehen alle Daten über
ATMohne Verzö gerung bei den Empfängern, d. h. den Daten-Servern,
ein.Wenn ATM ausfällt, ist über das ISDN-Backup eine Notversorgung
mit denwichtigsten Daten gewährleistet.Die Multicastempfänger auf
den Daten-Servern, die im Normalbetrieb aufden Empfang über das
ATM-Interface eingestellt sind, kö nnen den Ausfallder ATM-Ü
bertragung über den Announcementchannel von tq®
-TELLICASTregistrieren. Der Announcementchannel wird immer von
allen Empfängernkonstant empfangen. Daher kann er als Indikator für
den Ausfall des Net-zes dienen. Registriert der Empfänger, das er
den Announcementchannelüber ATM nicht mehr empfängt, so wird der
Empfang über das Ethernet-Interface auf ISDN umgestellt.
6.5 BANDBREITENMANAGEMENT BEI MEHREREN SENDERNFür alle Sender
des Systems wird ein gemeinsames Bandbreitenmanage-ment realisiert.
Ein Sender wird dabei zum Master-Sender und reguliert
dieGesamtbandbreite. Die anderen Sender teilen dem Master-Sender
ihrenBandbreitenbedarf mit und bekommen von diesem entsprechend der
aktu-ellen Verfügbarkeit Bandbreite zugewiesen.Welcher Sender das
Bandbreitenmanagement übernimmt, wird zwischenden Sendern
automatisch ausgehandelt. Jeder Sender bekommt über
dieKonfigurationsdatei eine Priorität zugewiesen. Die Sender
tauschen sich ü-ber die Priorität aus und weisen die
Master-Funktion dem Sender mit derhö chsten Priorität zu.Der
Master-Sender teilt den anderen Sendern über den
Announcement-channel in regelmäßigen Abständen mit, an welche
Adresse die Anfragenfür Bandbreite gesendet werden sollen. Wenn
dieses Signal ausbleibt, wirdautomatisch ein neuer Sender als
Master-Sender festgelegt.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 34
6.6 SCHNITTSTELLE ZUM MDIS-GUIDie Schnittstelle zwischen dem
Sender-seitigen MD / tq® -TELLICAST undder Sendekontrolle über das
GUI (Graphic User Interface von AFD) bildetebenfalls das MD.Die GUI
(oder alternativ auch ein anderer Prozess) verbinden sich über
ei-nen TCP-Server-Port mit dem MD und rufen die Daten über ein
ASCII-basiertes Protokoll ab. MD lässt dabei eine Abfrage nur von
Rechnern zu,die in einer GUI-Rechnerliste des MD eingetragen
sind.MD liest die an das GUI zu übermittelnden Daten über den
Sendeerfolg derÜ bertragung aus den tq® -TELLICAST Job Files im
„jobs/done“-Verzeichnisaus.
GUI MD tq®-TELLICAST
jobs/done
Abfrage Abfrage
Abbildung 12: Abruf von Informationen ü ber die Multicast-Ü
bertragung durch das GUI
Ein zentrales GUI kann die notwendigen Daten der einzelnen
MD-Prozesseentweder ebenfalls direkt oder (performanter) analog zu
AFD von den ein-zelnen GUIs abfragen.Von MD werden die
Informationen über den Sendeerfolg wie folgt über-mittelt:
• pro Empfänger
• als noch zu übertragende Dateien
• als noch zu übertragende Bytes Unabhängig vom Rhythmus und Art
der vom GUI angefragten Informati-onsübergabe überträgt MD bei
jeder Rekonfiguration eine aktuelle Emp-fängerliste und
Channel-Liste an das GUI.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 35
6.7 REALISIERUNG IM RAHMEN DES PROJEKTESNach der
Konzeptionierung erfolgte Mitte des Jahres 2001 die Bereitstel-lung
des um den Prozess „Multicast Distribution Layer“ erweiterten
Multi-castübertragungssystems tq® -TELLICAST durch die Firma
Tellique.Aufgabe des DWD war anschließend der Test dieser Software
und darauffolgend die Aufnahme der routinemäßigen Datenverteilung
über Multicast.
6.7.1 TestsDie Funktionsfähigkeit der gelieferten Software wurde
durch die Firma Tel-lique auf zwei O200-Rechnern – einem Sender und
einem Empfänger –vorgeführt. Nach den ersten
Konfigurationsversuchen und Tests wurde dieTestumgebung um drei
Linux-PCs erweitert. Die fünf Rechner - eine O200dient als Sender -
befinden sich in drei Subnetzen und bieten so eine Test-plattform
für die betriebliche Konfiguration des DWD. Bei den
einführendenTestläufen ermittelte Fehler wurden von Tellique nach
Meldung beseitigt.Die Tests auf Datenintegrität der
Multicast-Verteilung sind noch nicht be-endet. Hierfür wurde ein
Testsystem entwickelt, dass eine definierte Anzahlvon binären
Dateien generiert und diese dem MDiS übergibt. Auf denEmpfängern
wird nach der Datenübertragung die Vollständigkeit und Integ-rität
der Dateien automatisch geprüft. Dieser Test wird mehrfach und
mitunterschiedlichen Dateigrö ßen durchgeführt. Auch wechselt der
Senderzwischen den fünf Rechnern.Ein Bestandteil der Testprozeduren
sind Durchsatztests, in denen dieLeistung des Multicastsystem
gemessen und teilweise Vergleichsmessun-gen mit der DWD-eigenen
operationellen Fileverteilung per FTP-Protokollvorgenommen
werden.In einer zweiten Testgruppe werden Stö rungen im Netz und
auf den Rech-nern simuliert und die korrekte Reaktion der
Multicastdatenverteilung aufdiese Problemsituationen verifiziert.
Diese Test sind für den DWD beson-ders wichtig, da im Gegensatz zu
üblichen Anwendungen von Multicast-Verteilung (z.B.
Video-Konferenzen), bei denen der Verlust einzelner UDP-Pakete
akzeptiert werden kann, bei der Dateiverteilung im DWD
mittelsMulticast keine Datei verloren gehen bzw. verfälscht werden
darf. Deshalbwird dieser Test mit aller Sorgfalt durchgeführt und
ist noch nicht abge-schlossen.
6.7.2 Festlegung der Multicast-ChannelDie Festlegung der
Multicast-Channel ist ein iterativer Prozess, bei dem
diemeteorologisch-technischen Anforderungen (z.B. Zeitverhalten der
Daten-verteilung; Prioritäten bestimmter Datenarten) und die
heterogene Netz-werkleistungssituation (unterschiedlich
leistungsfähige Anbindung vonDienststellen, die teilweise dieselben
Daten benö tigen) abgestimmt werdenmüssen. Für die für das Projekt
vorgesehene Versorgung der Regional-zentralen mittels Multicast
scheint die Festlegung zunächst eine einfacheAufgabe zu sein. Für
eine Planung des Gesamtnetzes ist aber eine diffe-renzierte Planung
der Multicastkanäle erforderlich, bei der das Auslas-tungsverhalten
der nur mit 64 kBit/sec realisierten Stichverbindungen mitzu
berücksichtigen ist. Da die bisherige Fileverteilung die Daten
entspre-
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 36
chend ihrer jeweiligen Priorität über eine oder nur maximal
einige wenigelogische Verbindungen von Knoten zu Knoten
transportiert, fehlen Erfah-rungswerte über das Stauverhalten der
notwendigen grö ßeren Anzahl vonMulticastdatenströ men an den Ü
bergangspunkten zwischen schnellen undlangsamen Netzabschnitten.
Die Festlegung der Multicastchannel wird zurZeit als Vorbereitung
für die Inbetriebnahme parallel zu den Tests vorge-nommen und ist
bisher noch nicht abschließend erfolgt.
6.8 INBETRIEBNAHMEDa die Testphase noch nicht abgeschlossen
werden konnte, kam eine In-betriebnahme während der Laufzeit des
Projektes noch nicht in Frage.Noch nicht entschieden ist außerdem
die Frage, ob die Versorgung derkleineren Standorte von der
Zentrale in Offenbach aus erfolgen soll, oderob es besser ist, in
jeder Regionalzentrale einen Multicastsender einzu-richten, der die
an dieser Regionalzentrale angeschlossenen Standorte
desSekundärnetzes versorgt. Im ersten Fall würden die Daten, um den
teilwei-se engen zeitlichen Versorgungsanforderungen gerecht zu
werden, zwei-mal gesendet werden – einmal für die Regionalzentralen
und einmal mitgeringerer Bandbreite für die Standorte des
Sekundärnetzes. Im zweitenFall würde ein deutlich hö herer
Konfigurationsaufwand – für jede Regional-zentrale ein eigener
Channel zur Versorgung der angeschlossenen Stand-orte – und eine
zusätzliche Ü bergabefunktion an den Multicastsender ander
Regionalzentrale benö tigt werden.
6.9 BEWERTUNG DES ERGEBNISSESDie bisher vorliegenden
Testergebnisse zeigen, dass das unter MDiS ent-wickelte
Multicastsystem für eine Datendistribution innerhalb des
DWDsgeeignet ist. Allerdings erfordert eine erfolgreiche Nutzung
noch einenKonfigurations- und Planungsaufwand für die Umstellung
des Systems vonSeiten des DWD.Ausgangspunkt der Planungen des DWD
für den Betriebseinsatz warendie effektivere Nutzung der Netzwerk-
und Rechnerresourcen und die Ein-sparung von Konfigurations- und
Betreuungsaufwand durch eine Zentrali-sierung der Steuerung der
Datenverteilung.Die als primäres Projektziel geplante Umstellung
der Datenverteilung vonder Zentrale zu den Servern auf den
Dienststellen bringt dem DWD zu-nächst nicht den erwarteten Nutzen,
da der Aufwand für die Datenvertei-lung auf die unterschiedlichen
Anwendungen auf den Servern bzw. dieUnterverteilung auf die Rechner
der Dienststellen bleibt. Die durch die Auf-gabe des Hub-To-Hub
Systems eingesparten Betreuungs-aufwände wer-den voraussichtlich
durch den Betreuungsaufwand für die Multicast-Anwendung kompensiert
werden. Eine wirksame Minderung des Aufwan-des kann nur durch die
direkte Multicastversorgung der Anwendungen mitden für sie
relevanten Informationen erreicht werden. Die dafür erforderli-che
Migration der DWD-Anwendungen war im Projekt nicht vorgesehenund
ist nur auf mittlere Sicht umsetzbar. Zur Zeit wird eine Zwischenlö
sungrealisiert, bei der Multicastempfänger auf allen zu
versorgenden Rechnerninstalliert und lokal die Zuordnung der Daten
zu den Anwendungen vorge-nommen wird.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 37
Eine Minderung der Netzlast im Primärring gegenüber der
Unicast-Datenverteilung war von vorneherein nicht zu erwarten, da
das Hub-to-Hub-System des DWD eine Art „simulierte
Multicastverteilung“ im Primär-ring bewirkte. Die Daten wurden
jeweils von Niederlassung zu Niederlas-sung weitergereicht, anstatt
von der Zentrale an jede Niederlassungeinzeln versendet zu
werden.Seit dem Sommer 2001 wurden in einer Studie des BMVBW die Mö
glich-keiten zur Harmonisierung der europäischen meteorologischen
Satelliten-verteildienste untersucht. Dabei stellte sich heraus,
dass die Ü berlagerungder terrestrischen Netze des DWD durch eine
Multicast-Datenverteilung ü-ber eine hochverfügbare
Satellitenstrecke für die Grundversorgung derDWD-Dienststellen
wirtschaftlich vorteilhaft ist. In Konsequenz beauftragteder
DWD-Vorstand der Aufbau eines derartigen Systems bis Ende 2002.Für
dieses Projekt wird die mit MDiS geschaffene Datenverteilung so
mo-difiziert, dass die Verteilanforderungen des DWD durch einen
Verbund vonterrestrischen und satellitengestützten
Multicastverbindungen abgedecktwerden kö nnen. Durch die Verwendung
von MDiS sowohl im terrestrischenNetz als auch auf der
Satellitenstrecke kann eine optimale Kompatibilitätbeider
Datenverteilsysteme erreicht werden, was den
Verwaltungsaufwanderheblich senken kann.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 38
7 PROJEKTERGEBNIS
Ziel des Projektes MDiS ist der Piloteinsatz eines gesicherten
Multicast-Dateiverteilsystems auf Basis des Transportprotokolles
MTP/SO.Pilotnutzer im Projekt ist der DWD. Der DWD bietet sich als
Pilotnutzer an,da über das AFD-System in den Standleitungen des
Primärnetzes und desSekundärnetzes des DWD große Mengen komplexer
Daten zwischen denNiederlassungen ausgetauscht werden, wobei an
mehrere Standorte iden-tische Daten übertragen werden.Die
Multicast-Dateiverteilung für den DWD wurde mit tq® -TELLICAST
Fi-leBroadcast realisiert, einer von Tellique auf Basis MTP/SO
entwickeltenSoftware für gesicherte Datenverteilung über Multicast.
tq® -TELLICASTwurde über einen Adaptationslayer
(Multicast-Distribution, MD) in die übli-che Datenverteilung des
DWD über AFD integriert.In ersten Tests konnte während der Laufzeit
des Projektes die Funktions-tüchtigkeit des Systems nachgewiesen
werden. Der DWD hat bisher je-doch die Multicast-Datenverteilung
noch nicht in den laufenden Betriebintegriert. Da die Anforderungen
an die Sicherheit und die zeitkritische Ü -bertragung beim DWD
besonders hoch sind, legt der DWD Wert darauf,zunächst
langfristigere Tests durchzuführen. Zudem erfordert die
Etablie-rung des neue System zunächst erhö hten
Konfigurationsaufwand in derUmstellungsphase, um eine optimale
Anpassung sämtlicher Parameter zugewährleisten. Der DWD wird
deshalb das System schrittweise nach denLangzeittests einführen.
Die bisher vorliegenden Testergebnisse sind je-doch schon so
positiv, dass der DWD beschlossen hat, die unter MDiSverwendete
Software zusätzlich zur Datenverteilung über die
terrestrischenNetze auch für die Satellitendistribution
einzusetzen. Damit wäre eine op-timale Kompatibilität zwischen den
Systemen gegeben.Für die Integration der
Multicast-Datendistribution in das AFD-System desDWD wurde die von
Tellique entwickelte Software tq® -TELLICAST verwen-det. Um den
universellen Einsatz von MTP/SO auch außerhalb der Einbin-dung in
tq® -TELLICAST zu demonstrieren, wurde auf Grundlage des
weitverbreiteten Unicast-Dateiverteilsystems rdist ein Tool zur
Multicast-Dateiverteilung, mdist, entwickelt. Durch die Entwicklung
von mdist ist einTool entstanden, das es Anwendern, die rdist
nutzen, ermö glicht, Daten ü-ber Multicast zu übertragen, ohne die
schon vorhandene Konfiguration vonrdist ändern zu müssen. Dadurch
kann gesicherte Multicastübertragung füreine Vielzahl von Nutzern
des Wissenschaftsnetzes des DFN interessantwerden.Weitere
Anwendungsmö glichkeiten, die sich für Nutzer des
Wissen-schaftsnetzes ergeben, sind unter anderem die Distribution
von Softwaresowie die Realisierung von FTP-Mirror und Web-Mirror.
Neben der Integra-tion in Anwendungen bietet sich IP-Multicast auch
als Unterstützung derzentralen DFN-Infrastruktur, z. B. zur
Verteilung von NetNews und zumWeb-Caching an. Um die Nutzung von
Multicast im Bereich des B-WIN zufö rdern, wird das Protokoll
MTP/SO auf Anforderung den DFN-Mitgliedernzur Verfügung gestellt,
wenn Projekte unter Verwendung von Multicast in-nerhalb des B-WIN
realisiert werden sollen. Ü ber eine BSD-Socket-
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 39
ähnliche Schnittstelle kö nnen so verschiedenartige Anwendungen
von denVorteilen von IP-Multicast profitieren.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 40
8 ABKÜ RZUNGSVERZEICHNIS/GLOSSAR
Aaccounting.dat Datei von tq® -TELLICAST, in die das System
wäh-
rend der Ü bertragungen die Informationen schreibt,welche Daten
an wen übertragen wurden.
ACK Acknowledgement, Bestätigung über den Daten-empfang, die der
Empfänger an den Sender schickt.
AFD Automated File Distributor; Dateiübertragungssys-tem des
DWD.
Announcement-Channel
Logischer Kanal (Channel), über den tq® -TELLICASTÜ
bertragungsaufforderungen und Datenschlüssel andie Empfänger
verteilt.
ASCII American Standard Code for Information Inter-change.
ATM Asynchronous Tranfer Mode; Zellbasiertes Ü
bertra-gungsverfahren.
Bbit/s Bit pro SekundeB-WiN Breitband-Wissenschaftnetz des
DFN-Vereins.bzw. Beziehungsweise
CChannel Logischer Kanal, über den tq® -TELLICAST Daten
versendet. tq® -TELLICAST teilt physikalische Kanälein mehrere
Channel auf.(Auf IP-Ebene gleichzusetzen mit einer
Multicast-Gruppe.)
Dd. h. das heißtDFN-Verein Verein zur Fö rderung des Deutschen
Forschungs-
netzes, Betreiber des WiN und B-WiN.DWD Deutscher
Wetterdienst
Eetc. Etcetera; und so weiterEthernet LAN-Protokoll IEEE
802.3
FFEC Forward Error Correction; Korrektur von Ü bertra-
gungsfehlern ohne Verwendung eines Rückkanalsdurch Berechnung
von fehlenden Datenpaketenüber Redundanzpakete.
FTP File Transfer Protocol. Eine Standardanwendung fürTCP/IP,
die nur die Fileübertragung und keinen File-zugriff beinhaltet.
GGByte Gigabyteggf. Gegebenenfalls
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 41
GUI Graphical User Interface;hier: Kontrolloberfläche des
AFD-Systems desDWD.
IIETF Internet Engineering Task Force – Standardisie-
rungsorganisation des Internets.Invitation Empfangsaufforderung
für eine Datenübertragung
auf einem bestimmten Channel, die der tq® -TELLICAST Sender über
den Announcementchannelan die tq® -TELLICAST Empfänger sendet.
IP Internet ProtokollIRTF Arbeitsgruppe der IETF zur Entwicklung
von Stan-
dards zur gesicherten Datenübertragung.ISDN Integrated Services
Digital Network; digitales Daten-
übertragungsnetz.K
kbit/s Kilobit pro SekundeL
LAN Local Area Networklog.dat Datei von tq® -TELLICAST, in die
Fehlermeldungen
und Systemstatusmeldungen während des Betriebsvon tq® -TELLICAST
geschrieben werden.
MMByte/s Megabytes pro SekundeMDiS Multicast Distribution
System; System zur gesicher-
ten Ü bertragung von Multicast, das im Rahmeneines DFN-Projektes
vom DWD, der Tellique GmbHund dem Technologiezentrum Informatik der
Uni-versität Bremen beim Deutschen Wetterdienst inBetrieb genommen
wird.
mdist Aus rdist und MTP/SO im rahmen von MDiS entwi-ckeltes Tool
zur Multicast-Dateiverteilung.
MTP/SO Multicast Tranport Protocol / Self Organizing; vonder
Tellique GmbH vertriebenes Transportprotokollzur sicheren
Datenübertragung über Multicast aufder Basis des RFC 1301.
Multicast Mehrpunktübertragung. Ü bertragung von einemPunkt zu
einer Gruppe.
Multicast-Backbone Multicastfähiger „Backbone“ im Internet.
PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt.
http://www.context-gmbh.de
http://www.context-gmbh.de
-
MDiS-Abschlußbericht - 15.02.2002 42
NNAK Negative Acknowledgement. Ü bertragungs-kontrolle
durch Rückmeldung vom Empfänger, wenn die er-warteten
Datenpakete vom Sender nicht empfangenwurden.
PPrimärnetz Standleitungen mit einer Bandbreite von 34
KBit/s,
die die Zentrale des DWD in Offenbach und die 6Niederlassungen
mit Regionalzentrale ringfö rmigmiteinander verbinden.
Rrdist Programm zur Unicast-Dateiverteilung unter UNIX.
SSekundärnetz Standleitungen geringerer Bandbreite, die
kleinere
Standorte des DWD mit den Niederlassungen mitRegionalzentralen
verbinden.
SMTP Simple Mail Transfer ProtokollT
TCP Transmission Control Protocol. Verbindungsorien-tiertes
Transportprotokoll, das in Verbindung mit IPeingesetzt wird.
tq®