Zeitdienste. Nik Klever FB Informatik - FH Augsburg klever@fh-augsburg.de

Transkript

1 Zeitdienste Nik Klever FB Informatik - FH klever@fh-augsburg.de

2 Zeit Astronomische Messung Sonnentag: Intervall zweier Zenitdurchgänge Sonnensekunde: Sonnentag / (24 * 3600) Langzeitabweichungen: vor 3 Mio. Jahren gab es ca. 400 Tage pro Jahr, nimmt ab infolge von Gezeitenreibung und atmosphärischem Widerstand Kurzzeitabweichungen: Turbulenzen im Erdinnern mittlere Sonnensekunde seit 1948 physikalische Messung Zählung der Übergänge des Cäsium 133 Atoms Übergänge ergeben 1 Atomsekunde eine Atomsekunde ist eine mittlere Sonnensekunde im Jahr der Einführung der Atomzeit ( ) TAI (International Atomic Time), verwaltet durch das BHI (Bureau International d Heure)

3 Abweichung trotz oder gerade wegen der genauen Zeit ergibt sich ein Problem: TAI-Sekunden sind ca. 3 Millisekunden weniger als ein mittlerer Sonnentag (wegen der Langzeitabweichung) Irgendwann käme es zur selben Situation wie 1582 als Papst Gregor 10 Tage per Dekret aus dem Kalender gestrichen hat BHI löst das Problem durch die Einführung von Schaltsekunden wenn die Abweichung zwischen TAI und Sonnenzeit auf 800 Millisekunden wächst

4 Universal Coordinated Time (UTC) Zeitsystem, das auf konstanten TAI-Sekunden basiert, aber in Übereinstimmung mit den sichtbaren Bewegungen der Sonne bleibt Grundlage für jede moderne Zeitverwaltung löst damit die ältere, astronomische Greenwich Mean Time ab Bereitstellung über Strom, Funk, Satellit

5 Uhr-Synchronisierung jede Maschine p hat einen Timer der H-mal in der Sekunde ein Interrupt veranlasst bei jedem Interrupt addiert der Interrupt-Handler 1 zum Wert C p (t) einer Software-Uhr, wobei t die UTC-Zeit ist In einer perfekten Welt gilt C p (t) = t V p,t bzw. dc/dt = 1 bzw. 1-ρ<=dC/dt<=1+ρ max. Differenz 2ρ t Synchronisation mind. alle δ/2ρ Sek. um min. Differenz δ zu erhalten

6 Algorithmus von Christian Anfrage an einen (passiven) Zeitserver Abschätzung der Verzögerungszeit durch die Netzkommunikation: (T 1 -T 0 )/2 bzw. verbessert (T 1 -T 0 -I)/2

7 Berkeley-Algorithmus Aktiver Zeitserver fragt alle Clients ab berechnet durchschnittliche Zeit und verschickt diese Zeit als aktuelle Zeit, an die sich die Clients anzupassen haben

8 Mittelwert-Algorithmen dezentrale Algorithmen z.b. Unterteilung der Zeit T in Resynchronisierungsintervalle fester Länge R Intervall i: T 0 + i R jede Maschine sendet am Anfang jedes Intervalls eine Broadcastmessage mit ihrer aktuellen Zeit und startet einen lokalen Timer alle während eines Intervalls S eingehenden Broadcastmessages werden gesammelt und zur Berechnung einer neuen Zeit hergenommen

9 Logische Uhren Für viele Zwecke ist es ausreichend, sich über dieselbe Zeit einig zu sein, ohne dass diese mit der realen Zeit exakt übereinstimmt die Uhren, die auf dieser Annahme basieren nennt man logische Uhren Lampert-Zeitstempel

10 Time Protocol Entwicklung Mills, D.L., "DCNET Internet Clock Service", RFC-778, April 1981 Postel, J., "Time Protocol", RFC-868, May 1983 Mills, D.L., "Network Time Protocol (NTP)", RFC-958, September 1985 Mills, D.L., "Network Time Protocol (version 1) - specification and implementation" RFC-1059, July Mills, D.L., "Network Time Protocol (version 2) - specification and implementation", RFC-1119, September Mills, D.L., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC-1305, March 1992 Mills, D.L., "Simple Network Time Protocol (SNTP)", RFC-1361, August 1992 Mills, D.L., "Simple Network Time Protocol (SNTP)", RFC-1769, March 1995 Mills, D.L., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC-2030, Ocotober 1996

11 Time Protocol (J. Postel, RFC 868) Whenusedvia TCP thetime serviceworksas follows: S: Listen on port 37 (45 octal). U: Connect to port 37. S: Send the time as a 32 bit binary number. U: Receive the time. U: Close the connection. S: Close the connection. The Time The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036.

12 Network Time Protocol (NTP) Entwurfsziele für die Bereitstellung eines Zeitdienstes der erlaubt, dass Clients über das Internet genau mit UTC synchronisiert werden mittels statistischer Techniken werden die unterschiedlichen und teilweise großen Verzögerungen bei der Nachrichtenkommunikation herausgefiltert der längere Verbindungsunterbrechungen übersteht mittels redundanter Server und Pfade der Clients ermöglicht, sich ausreichend häufig zu synchronisieren, damit die Abweichgeschwindigkeiten kompensiert werden können mittels einer auf eine große Anzahl von Rechner beteiligten Dienstes der gegen Störungen (mutwillig oder versehentlich) geschützt ist mittels Authentifizierung und Auswertung der Rückkehradressen

13 NTP Verteilung NIST (National Institute of Standards and Technology) schätzt, dass es Mio. NTP Server und Clients verteilt über das Internet existieren. Jedes Windows/XP hat einen NTP Client. NTP stellt Genauigkeiten von unter Zehntelmillisekunden in WANs, Submillisekunden in LANs und Submikrosekunden für Rechner mit Präzisionszeitquellen (Cäsium-Uhr, GPS Empfänger) bereit NTP Software ist auf fast alle Workstation und Server Plattformen, die heute existieren, portiert worden Die NTP Architektur, das Protokoll und die Algorithmen sind über die letzten beiden Jahrzehnte weiterentwickelt worden und bilden die Grundlage für die NTP Version 4

14 NTP-Server-Netzwerk Primär-Server (Stratum 1) direkt an eine extrem genaue externe Zeitquelle (Funk, Satellit, Atomuhr) angeschlossen Sekundär-Server (Stratum 2) weniger genaue externe Zeitquelle und synchronisiert mit Primär-Servern usw.

15 Synchronisierungsmodi NTP Server können sich in einem von 3 Modi synchronisieren Multicast-Modus, vorgesehen für die Verwendung in einem Hochgeschwindigkeits-LAN. Multicast Pakete mit der aktuellen Zeit werden versendet, von den Computern am LAN empfangen und mit einer kleinen Verzögerung wird diese Zeit gesetzt Client/Server- (oder Prozeduraufruf-) Modus, ähnlich dem Algorithmus von Christian symmetrischer Modus für den Austausch mit anderen Zeitservern oder Computern mit extrem genauem Zeitbedarf

16 genereller Nachrichtenaustausch in allen Modi werden Nachrichten via UDP ausgetauscht jede Nachricht enthält Zeitstempel neuerer Nachrichtenereignisse: die lokalen Zeiten, als die vorhergehende NTP-Nachricht m zwischen dem Paar gesendet (T i-3 ) und empfangen (T i-2 ) wurde sowie die lokalen Zeiten, als die aktuelle Nachricht m übertragen wurde (T i-2 und T i )

17 Peer 1 Peer 2 Peer 3 NTP Übersicht (nach Mills) NTP Messages Filter 1 Filter 2 Filter 3 Selection and Clustering Algorithms Combining Algorithm Timestamps Clock Discipline Algorithm Loop Filter P/F-Lock Loop Mehrfache Server/Clients stellen Redundanz und Diversität her. Uhren Filter selektieren den besten Wert aus einem Fenster von 8 Zeitstempeln. Schnitt- und Vereinigungs-Algorithmen holen die besten richtiggehenden Uhren heraus und verwerfen falschgehende. kombinierte Algorithmen berechnen einen gewichteten Durchschnitt aller Zeitstempel. Schleifenfilter und variabler Frequenz Oszillator (VFO) implementieren eine hybride Phasen/Frequenz-begrenzte (P/F) Rückkopplungs-Schleife um Jitter und Wander zu minimieren VFO

18 NTP Subnetze (nach Mills) S3 S3 S3 S2 S2 S2 S2 * * S4 S3 S3 S1 S1 S1 S1 S2 * * S2 S1 S2 S1 * Workstation (a) Clients (b) Clients (c) * to buddy (S2) (a) Workstations benutzen den Multicast Modus mit mehreren Abteilungsservern (b) Abteilungsservers benutzen den Client/Server Modus mit mehreren Campus Servern und symmetrischen Modus untereinander. (c) Campus Server benutzen den Client/Server Modus mit bis zu 6 unterschiedlichen externen Primärservern und symmetrischen Modus untereinander und externen Sekundärservern (buddy).

19 NTPv3 (RFC 1305) Die Hauptmotivation für die Version 3 war, die Analysis und das Implementierungsmodell für neue Anwendungen zu verfeinern um den gesteigerten Netzwerkgeschwindigkeiten bis in den Gigabit/Sekunde-Bereich hinein genüge zu leisten und erweiterte Stabilität, Genauigkeit und Präzision bereitzustellen, die für solche Geschwindigkeiten notwendig ist.

20 NTP v3 (RFC 1305) Implementierungs Modell Ziele: clock offset clock offset repräsentiert den Zeitbetrag um den die lokale Uhr geändert werden muss um mit der Referenzuhr zu korrespondieren roundtrip delay roundtrip delay stellt die Möglichkeit her, eine Nachricht zu launchen, damit sie zu einer bestimmten Zeit bei der Referenzuhr ankommt Dispersion Dispersion (Streuung) repräsentiert den maximalen Fehler der lokalen Uhr relativ zur Referenzuhr

21 NTP v4 (Draft) Benutzung der Gleitkomma Arithmetik anstelle der Fixpunktarithmetik. Neu konzipierter Algorithmus für das Zeitverhalten der die Genauigkeit, das Verhalten bei Netzwerk Jitter und die Polling Intervalle verbessert. Unterstützung für die Nanokernel Implementierung, die Nanosekunden Genauigkeit unterstützt ebenso wie verbesserte Algorithmen. Kryptographie mittels öffentlicher Schlüssel (bekannt als autokey) um die Benutzung gemeinsamer sicherer Schlüssel zu vermeiden. Automatische Server Suche (manycast mode) Schnelle Synchronisation beim Hochfahren und nach Netzwerk-Fehlern (burst mode) Neue und revidierte Treiber für Referenzuhren Unterstützung für neue Plattformen und Betriebssysteme

22 Cryptosum NTP Protocol Format (nach Mills) LI NTP Protocol Header Format (32 bits) S. VN Mode Strat Poll Root Delay Root Dispersion Reference Identifier Reference Timestamp (64) Originate Timestamp (64) Receive Timestamp (64) Transmit Timestamp (64) Extension Field 1 (optional) Prec Extension Field 2 (optional) LI leap warning indicator VN version number (4) Strat stratum (0-15) Poll poll interval (log2) Prec precision (log2) NTP Timestamp Format (64 bits) Seconds (32) Fraction (32) Value is in seconds and fraction since 0 h 1 January 1900 NTPv4 Extension Field Field Length Field Type Extension Field (padded to 32-bit boundary) Last field padded to 64-bit boundary Authenticator (Optional) Key/Algorithm Identifier Message Hash (64 or 128) NTP v3 and v4 NTP v4 only authentication only Authenticator uses DES-CBC or MD5 cryptosum of NTP header plus extension fields (NTPv4)

23 NTP Packet Header Format (nach Mills) Packet header Variables Description leap leap indicator (LI) version version number (VN) mode protocol mode stratum stratum τ poll interval (log 2 s) ρ clock reading precision (log 2 s) root delay Ε root dispersion refid reference ID reftime reference timestamp T 1 originate timestamp T 2 receive timestamp T 3 transmit timestamp T 4 destination timestamp* MAC MD5 message hash (optional) LI VN Mode Strat Poll Prec Root Delay Root Dispersion Reference Identifier Reference Timestamp (64) Originate Timestamp (64) Receive Timestamp (64) Transmit Timestamp (64) MAC (optional 160) * Strictly speaking, T 4 is not a packet variable; it is the value of the system clock upon arrival.

24 NTP Datum- und Zeitformat und wichtige Datumsangaben (nach Mills) NTP Date (signed, twos-complement, 128-bit integer) Seconds (64) Fraction (32 or 64) Era Number NTP Timestamp (unsigned 64-bit integer) Era (32) Seconds (32) Fraction (32) Year M D JDN NTP Date Era Timestamp ,657,814, ,795,583,104 First day Julian Era ,721,426-59,926,608, ,934,144 First day Common Era ,299,161-10,010,304, ,874,597,888 First day Gregorian Era ,415, First day NTP Era ,440,588 2,208,988, ,208,988,800 First day Unix Era ,441,318 2,272,060, ,272,060,800 First day UTC ,451,545 3,155,673, ,155,673,600 First day 21st century ,464,731 4,294,944, ,294,944,000 Last day NTP Era ,464,732 4,295,030, ,104 First day NTP Era ,816,788 34,712,668, ,930,

25 NTP Peer Protocol Beispiel (nach Mills) State Variables Name Description org rec xmt originate timestamp receive timestamp transmit timestamp T 1 T 2 T 3 T 4 t2 t3 t6 t7 0 0 t 1 t 1 t 2 t 3 = clock t 3 t 4 t 5. t 5. t 6 t 7 = clock t 2 = clock t 6 = clock org 0 t 1 rec t 2 t 2 xmt 0 t 3 t 2 t 3 t 1 t 4 t 5 t 5? t 6 t 3? t 6 t 7 t 5 t 6 t 7 t 8 Packet Variables Peer B State Variables Packet Header Variables Name Description t n t n+1 t n+2 t n+3 originate timestamp receive timestamp transmit timestamp destination timestamp T 1 T 2 T 3 T 4 org rec t 1 0 t 1 0 t 2 t 1 = clock t 3. t 4 = clock 0. 0 t 4 t 3? t 4 t 5 t 3. t 4 t 5 = clock t 8 t 5 t 6 t 7 t 8 = clock t 3 t 7? t 4 t 8 xmt t 1 t 1? t 5 t 5? Packet Variables Peer A State Variables

26 pool.ntp.org Pool von NTP Servern Vorteile über 220 beteiligte Server erreichbar über eine DNS Round-Robin-Verteilung ausreichend für den alltäglichen Gebrauch der Ressourcenverbrauch der großen Zeitserver wird reduzieren Nachteile es kann passieren, dass ein Server auf eine Anfrage nicht antwortet es wird seltenst der naheliegenste Server angefragt Beispiel driftfile /var/lib/ntp/ntp.drift server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org

27 SNTP v4 (RFC 2030) SNTP kann dann benutzt werden, wenn die ultimative Performance der vollen NTP Implementierung gemäß RFC 1305 nicht gebraucht oder nicht gerechtfertigt ist. SNTP v4 klärt einige Design Eigenschaften von NTP, die es erlauben, NTP Server in einem einfachen, zustandslosen remote-procedure-call (RPC) Modus zu benutzen, der eine Genauigkeit und Verfügbarkeit ähnlich dem Time Protocol von RFC 868 zur Verfügung stellt.

28 Exkurs: WEBDAV (RFC 2518) Remote Web Content Authoring (Web Distributed Authoring) Ziele: spezifiziert zusätzliche Methoden, Header und Content-types zu HTTP/1.1 für das Management der Eigenschaften von Resourcen, für die Erzeugung und das Management von Resource-Kollektionen, für die Manipulation von Namensräumen und für die Sperrung von Resourcen (zur Vermeidung von Kollisionen)

29 Datenmodell für Resource Eigenschaften Resource Eigenschaften sind Daten, die den Status einer Resource beschreiben bestehen aus einem Namen/Werte-Paar live Eigenschaften Syntax und Semantik festgelegt vom Server, z.b. Readonly Werte Werte können vom Client geändert werden aber Server checkt die Syntax dead Eigenschaften Syntax und Semantik festgelegt vom Client Server speichert die Werte nur existierende Metadaten (Beispiele) PICS, PICS-NG, RDF (W3C), Dublin Core (RFC2413) Bibliographic Records Format (RFC1807)

30 Web Resource Kollektionen Web Resource Kollektion Beschreibung von zusammengehörigen Objekten (in einer Kollektion, z.b. Dateisystemverzeichnisse) innerhalb des Namensraums eines Servers HTTP URL Namensraum Modell Der HTTP URL Namensraum ist ein hierarchischer Namensraum wobei die jeweiligen Hierarchien durch das "/" Zeichen getrennt sind. Ein HTTP URL Namensraum ist konsistent wenn er die folgende Bedingung erfüllt: für jede URL in der HTTP Hierarchie existiert eine Kollektion die diese URL als internes Mitglied (d.h. relativ erreichbar) enthält. die Wurzel oder Toplevel-Kollektion ist von dieser Regel ausgenommen. weder HTTP/1.1 noch WebDAV erfordern dass der gesamte HTTP URL Namensraum konsistent ist.

31 Beispiel (cadaver) $ cadaver dav:!> open Authentication required for Zope on server `localhost': Username: admin Password: dav:/> ls Listing collection `/': succeeded. Coll: Control_Panel 0 Mar 30 20:05 Coll: TestOrdner 0 Apr 6 15:15 Coll: temp_folder 0 May 13 13:08 acl_users 0 Mar 30 20:20 browser_id_manager 0 Mar 30 20:05 error_log 0 Mar 30 20:05 index_html 28 Mar 30 20:05 session_data_manager 0 Mar 30 20:05 standard_error_message 1227 Mar 30 20:05 standard_html_footer 18 Mar 30 20:05 standard_html_header 82 Mar 30 20:05 standard_template.pt 282 Mar 30 20:05 virtual_hosting 0 Mar 30 20:05 dav:/> cd TestOrdner

32 Sperren (Locking) Diese Empfehlung erlaubt die Sperrung mittels zweier client-seitiger Parameter: die Anzahl der involvierten Auftraggeber (exclusiv vs. gemeinsam genutzt) und den zugewiesenen Access-Typ derzeit ist nur ein Access-Typ ( write ) definiert. Die Syntax ist jedoch für das Sperren anderer Access-Typen erweiterbar.

33 Beispiel (editieren) dav:/testordner/> ls Listing collection `/TestOrdner/': succeeded. CMFI18NStaging.tar.gz 3 Mar 30 21:06 acl_users 0 Mar 30 21:06 document 191 Mar 30 21:06 examplech7 442 Apr 6 13:16 fha_logo.gif 1040 Mar 30 21:06 index_html 232 May 13 12:59 pt test 864 May 13 13:02 session 723 Apr 6 15:02 standard_html_header 82 Mar 30 21:06 standard_html_header_1 82 Mar 30 21:06 test 734 May 13 12:58 test4 0 Apr 6 13:03 veranstaltung.xml 3740 Mar 30 21:06 dav:/testordner/> edit index_html Locking `index_html': succeeded. Downloading `/TestOrdner/index_html' to /tmp/cadaver-edit-tvqhst Progress: [=============================>] 100.0% of 232 bytes succeeded. Running editor: `vi /tmp/cadaver-edit-tvqhst'... No changes were made. Unlocking `index_html': succeeded. dav:/testordner/>

34 Beispiel (locked) Fachhochschule

35 Kalender Standards Standards für Kalender- und Zeitplanung zu definieren ist kompliziert, weil Kalender- und Zeitplanung kompliziert ist. Kalender involvieren Zeit und Zeitzonen, enthalten sich wiederholende Ereignisse, Alarme, Personen, unterschiedlichste Resourcen, Ereignisse, suchen von mehreren Zeiten und/oder Resourcen an mehr als einem Ort, enthalten Sperrzeiten, erkennen Zeitfenster und enthalten viele, viele weitere Komplexitäten

36 Kalender Standards Internet Calendaring and Scheduling Core Object Specification (icalendar) RFC 2445 MIME Type text/calendar basierend auf vcal - Spezifikation icalendar Transport-Independent Interoperability Protocol (itip) RFC 2446 spezifiziert ein Internet Protocol für die icalendar Object Spezifikation um eine Zeitplanungs-Interoperabilität zwischen unterschiedlichen Kalendersystemen bereitzustellen icalendar Message-Based Interoperability Protocol (imip) RFC 2447 Spezifiziert eine Bindung vom itip Protokoll an Internet basierenden transport Calendar Access Protocol (CAP) draft beschreibt die Nachrichten, die für das Management von Kalendern notwendig sind. Diese Nachrichten werden in ical repräsentiert und beschreiben die Semantik für das Suchen von Daten u.ä. Calendaring Extensions to WebDAV (CalDAV) draft

37 icalendar (vcal) Beispiel BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//en BEGIN:VEVENT DTSTART: T170000Z DTEND: T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR

38 CALDAV (Draft) ( Spezifiziert Methoden, Header, Message Bodies, Eigenschaften und Reports für die Definition von Kalendarzugriffen als Erweiterung des WebDAV Protokolls Die neuen Protokollelemente sind dazu gedacht, WebDAV-basierte Kalender- und Terminplanung als interoperablen Standard zu etablieren der den Zugriff auf Einzelbenutzer- Kalender, gemeinsame Kalenderbenutzung (shared calendar) als auch die Veröffentlichung von Kalendern unterstützt.

39 CALDAV XML Namespace urn:ietf:params:xml:ns:caldav CalDAV Server Kalender-orientierter Rechner kombiniert mit einem WebDAV Repository Ein WebDAV Repository ist eine Menge von WebDAV Kollektionen, die - innerhalb eines eindeutigen URL Namensraums - andere WebDAV Resourcen enthält. Ein WebDAV Repository kann selbst ein CalDAV Server sein, wenn es die Funktionalität eines CalDAV Servers an jedem Punkt innerhalb der Wurzel des Repositories erfüllt. Kalenderfunktionalitäten sind nur in den Teilen des Repositories notwendig, die selbst Kalenderobjekte sind oder Kalenderobjekte enthalten.

40 >> Request << Beispiel 1 PUT /lisa/calendar/newevent.ics HTTP/1.1 If-None-Match: * Host: cal.example.com Content-Type: text/calendar Content-Length: xxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID: T182145Z @example.com DTSTART: T170000Z DTEND: T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR >> Response << HTTP/ Created Date: Thu, 02 Sep :53:32 GMT Location: Content-Length: 0 ETag: " "

41 Beispiel 2 - Request REPORT /bernard/calendar/ HTTP/1.1 Host: cal.example.com Depth: 1 Content-Type: text/xml Content-Length: xxxx <?xml version="1.0" encoding="utf-8"?> <C:calendar-query xmlns:d="dav:" xmlns:c="urn:ietf:params:xml:ns:caldav"> <D:prop> <D:getetag/> </D:prop> <C:calendar-data> <C:comp name="vcalendar"> <C:allprop/> <C:comp name="vevent"> <C:prop name="x-abc-guid"/> <C:prop name="uid"/> <C:prop name="dtstart"/> <C:prop name="dtend"/> <C:prop name="duration"/> <C:prop name="exdate"/> <C:prop name="exrule"/> <C:prop name="rdate"/> <C:prop name="rrule"/> <C:prop name="location"/> <C:prop name="summary"/> </C:comp> <C:comp name="vtimezone"> <C:allprop/> <C:allcomp/> </C:comp> </C:comp> </C:calendar-data> <C:filter> <C:comp-filter name="vcalendar"> <C:comp-filter name="vevent"> <C:time-range start=" t000000z" end=" t235959z"/> </C:comp-filter> </C:comp-filter> </C:filter> </C:calendar-query>

42 Beispiel 2 - Response HTTP/ Multi-Status Content-Type: text/xml; charset="utf-8" Content-Length: xxxx </C:calendar-data> </D:response> <D:response> <D:href> calendar/mtg103.ics</d:href> <D:propstat> <D:prop> <D:getetag>"ff11fb-23ba4d"</D:getetag> </D:prop> <D:status>HTTP/ OK</D:status> </D:propstat> <C:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT DTSTART: T130000Z DTEND: T150000Z SUMMARY:Design meeting - Part II UID: @example.com X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com END:VEVENT END:VCALENDAR </C:calendar-data> </D:response> </D:multistatus> <?xml version="1.0" encoding="utf-8"?> <D:multistatus xmlns:d="dav:" xmlns:c="urn:ietf:params:xml:ns:caldav"> <D:response> <D:href> bernard/calendar/ev102.ics</d:href> <D:propstat> <D:prop> <D:getetag>"23ba4d-ff11fb"</D:getetag> </D:prop> <D:status>HTTP/ OK</D:status> </D:propstat> <C:calendar-data>BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT DTSTART: T100000Z DTEND: T120000Z SUMMARY:Design meeting UID: @example.com X-ABC-GUID:E1CX4zp-0005Ld-21@example.com END:VEVENT END:VCALENDAR

43 Zeitkritische Anwendungen Videokonferenzen und Kooperative Systeme sind zeitkritische Anwendungen, deren Abhängigkeit von einer genauen Zeit unabdingbar sind Ein schönes Beispiel hierzu ist die Multicast Anwendung Multimedia Lecture Board mlb, zur Erzeugung und Verbreitung von Präsentationen über Multicast. Gehen die Uhren der jeweiligen beteiligten Rechner auch nur um einige Sekunden falsch, so ergibt dies entsprechende Verzögerungen in der Darstellung. (