WEBVTT

00:00.740 --> 00:04.720
Mit der neuesten Hardware hier die Tonqualität für die Aufzeichnung

00:05.400 --> 00:05.920
verbessert.

00:06.200 --> 00:11.700
Wir begrüßen also auf jeden Fall auch noch mal die Leute, die sich die

00:11.700 --> 00:13.680
Übung nur auf der Aufzeichnung anhören.

00:20.600 --> 00:23.320
Und steigen damit dann auch gleich ein in die erste Aufgabe.

00:23.540 --> 00:26.300
Wie gesagt, unterbrechen Sie mich auf jeden Fall, wenn Ihnen irgendwas

00:26.300 --> 00:26.900
unklar ist.

00:28.120 --> 00:31.020
Die erste Aufgabe war im Wesentlichen das Fallbeispiel aus der

00:31.020 --> 00:31.520
Vorlesung.

00:31.520 --> 00:35.800
Ein gestresster Manager ist auf der Autobahn, steht in seinem Porsche

00:35.800 --> 00:36.360
im Stau.

00:37.460 --> 00:40.800
Sein Flug ist gebucht, alles ist erledigt und er möchte jetzt zur

00:40.800 --> 00:43.440
Planung und Durchführung seiner Reise ein verteiltes

00:43.440 --> 00:45.080
Informationssystem in Anspruch nehmen.

00:45.620 --> 00:49.440
Er hat dazu ein mobiles Endgerät dabei und möchte Daten abfragen,

00:49.580 --> 00:52.340
sowohl über seinen Flug, über die Buchung als auch über den Verkehr.

00:53.420 --> 00:57.380
Und Sie sollten als Einstiegsaufgabe, um ein paar der Begriffe mal zu

00:57.380 --> 01:00.020
wiederholen, die wichtig sind, weil sie immer mal wieder gerne

01:00.020 --> 01:02.400
nachgefragt werden, vor allem klar sein müssen.

01:02.880 --> 01:06.060
Die Dienste, die der Manager in Anspruch nehmen kann, modellieren und

01:06.060 --> 01:10.740
auf die auf den Namen Dienstfunktionalität und Dienstmerkmale im

01:10.740 --> 01:11.740
Speziellen eingehen.

01:12.160 --> 01:14.840
Danach noch die Zuordnung zu den verschiedenen Möglichkeiten,

01:14.960 --> 01:18.340
Disposition und Dispatching samt Qualitätsanforderungen.

01:20.320 --> 01:23.280
Steigen wir also da mal ein in das ganz einfache Diagramm, das hinter

01:23.280 --> 01:23.940
mir zu sehen ist.

01:24.020 --> 01:25.620
Wer ist denn der Dienstnehmer in dem Beispiel?

01:29.000 --> 01:29.540
Keine Scheu.

01:31.420 --> 01:33.340
Der Manager, selbstverständlich.

01:34.400 --> 01:36.300
Was Frau Zitterbart hier auch immer als erstes macht.

01:36.420 --> 01:38.320
Ich nehme mir auch mal lieber besser die rote Farbe.

01:39.960 --> 01:42.040
Der Diensterbringer ist in dem Fall wer?

01:45.900 --> 01:47.160
Wir nennen es immer Provider.

01:48.440 --> 01:51.340
Wir schreiben einfach mal hier rein, also der Betreiber auf jeden Fall

01:51.340 --> 01:54.980
dieses verteilten Informationssystem ist, das der Manager in Anspruch

01:54.980 --> 01:55.540
nehmen will.

01:59.050 --> 02:02.310
Und jetzt ein paar Dienstfunktionalitäten würde ich gerne hören, die

02:02.310 --> 02:05.070
der Manager in Anspruch nehmen kann bei diesem Informationssystem.

02:06.430 --> 02:07.810
Was kann er denn alles machen damit?

02:08.310 --> 02:10.110
So wie es in der Vorlesung als Beispiel dran war.

02:14.760 --> 02:17.140
Dienstfunktionalitäten sind im Wesentlichen eben die Funktion, die er

02:17.140 --> 02:18.480
von diesem Dienst erhalten kann.

02:22.730 --> 02:23.590
Was kann er machen?

02:35.260 --> 02:38.260
Er kann auf jeden Fall den Verkehrszustand abrufen, genau.

02:39.700 --> 02:41.020
Was kann er noch abrufen?

02:41.020 --> 02:45.940
War in der Aufgabenstellung auch alles erwähnt, ist auch gar nicht so

02:45.940 --> 02:46.220
schwierig.

02:48.100 --> 02:49.700
Genau, er kann seinen Flug umbuchen.

02:49.820 --> 02:52.360
Vorher kann er auf jeden Fall mal Fluginformationen abfragen.

02:53.640 --> 02:57.060
Und wie erwähnt war, kann das System auf jeden Fall auch den Flug

02:57.060 --> 02:57.540
umbuchen.

02:58.920 --> 02:59.760
Was haben wir noch alles?

03:07.150 --> 03:08.310
Das ist sehr schön, ja.

03:12.690 --> 03:14.990
Sagen wir mal, er kann die Reservierung bestätigen von dem Flug.

03:22.310 --> 03:25.430
Wir haben in der Vorlesung noch das Beispiel gebracht, er kann

03:25.430 --> 03:26.610
natürlich auch kommunizieren.

03:26.790 --> 03:30.550
Das heißt, er kann nach Möglichkeit auch seinen Gegenüber, mit dem er

03:30.550 --> 03:32.710
verabredet ist, über die Änderungen informieren.

03:32.850 --> 03:33.790
Das heißt, er kann

03:37.450 --> 03:44.150
die Kommunikation führen mit dem mit der Zielperson, die er probiert

03:44.150 --> 03:44.770
zu erreichen.

03:48.130 --> 03:49.710
Was könnte er sinnigerweise noch machen?

03:49.810 --> 03:51.130
Funktioniert sogar heute auch schon.

03:51.330 --> 03:54.250
Wenn man auf dem Weg zum Frankfurter Flughafen ist, nur sein Handy

03:54.250 --> 03:58.410
dabei hat, nicht mehr so richtig einfach nachschauen kann, während man

03:58.410 --> 04:00.690
fährt, soll man es sowieso nicht machen.

04:01.750 --> 04:03.990
Da gibt es jetzt schon einen sehr praktischen Dienst von diesem

04:03.990 --> 04:07.030
verteilten Informationssystem, für den man sich vorher registrieren

04:07.030 --> 04:07.990
kann, kennt ihn niemand.

04:09.830 --> 04:11.830
Studenten sollen heute ziemlich reich sein, ich weiß nicht, ob sie zum

04:11.830 --> 04:15.390
Frankfurter Flughafen fahren und in die Welt entschwinden.

04:20.870 --> 04:22.970
Also man kann sich heute tatsächlich schon registrieren lassen für

04:22.970 --> 04:26.750
einen SMS-Service, um per Push-Dienst informiert zu werden, wenn sich

04:26.750 --> 04:29.470
am Flug etwas ändert, zum Beispiel der Flugsteig, an dem der Flug

04:29.470 --> 04:29.950
ankommt.

04:30.770 --> 04:33.050
Im Wesentlichen also Benachrichtigungen über

04:37.990 --> 04:38.790
aktuelle Änderungen.

04:44.690 --> 04:46.810
Sie gewinnen auf jeden Fall einen Eindruck, was man mit

04:46.810 --> 04:48.110
Dienstfunktionalitäten meint.

04:48.190 --> 04:51.630
Das sind in sich abgeschlossene Funktionen, die der Dienstnutzer davon

04:51.630 --> 04:54.370
in Anspruch nehmen kann, von dem verteilten Informationssystem.

04:55.190 --> 04:57.630
Was das immer im Einzelnen ist, wir haben ein paar Beispiele jetzt

04:57.630 --> 05:00.270
aufgeschrieben, es gibt mehr, es gibt andere, ist immer

05:00.270 --> 05:01.090
Definitionssache.

05:01.190 --> 05:03.230
Aber Sie sollten wissen, wenn Sie einen Dienst in Anspruch nehmen,

05:03.330 --> 05:05.750
dann nehmen Sie von ihm eine Dienstfunktionalität in Anspruch.

05:06.550 --> 05:07.710
Erster Begriff.

05:08.710 --> 05:10.890
In der Vorlesung war es auch schon erklärt, wie die

05:10.890 --> 05:13.770
Dienstfunktionalität dann erbracht wird, ist wieder eine andere Sache.

05:14.550 --> 05:17.090
Die Dienstfunktionalität wird erbracht, indem verschiedene

05:17.090 --> 05:22.030
Dienstprimitive, das sind einzelne Schritte für diese Dienstfunktion,

05:25.170 --> 05:26.750
für diese Dienstfunktionalität

05:30.600 --> 05:35.080
wird erbracht als Ablauf von verschiedenen Dienstprimitiven

05:35.080 --> 05:35.660
nacheinander.

05:36.780 --> 05:39.400
Die sind für den Dienstnutzer normalerweise nicht so sehr von

05:39.400 --> 05:39.840
Interesse.

05:40.400 --> 05:46.860
Das Beispiel in der Vorlesung ist, wenn Sie zum Beispiel kommunizieren

05:46.860 --> 05:51.460
wollen mit Ihrem Gegenüber, das sind verschiedene Dienstfunktionen.

05:51.880 --> 05:54.680
Ablaufen tut es unten drunter aber in verschiedenen Dienstprimitiven.

05:54.960 --> 05:57.820
Sie sprechen Ihr Mobilfunknetz an, Ihre Daten werden geladen, es

05:57.820 --> 06:00.580
werden Abrechnungsdaten erzeugt, es wird das Gespräch aufgebaut.

06:01.200 --> 06:03.520
Wenn Sie die Zelle wechseln, finden Handovers statt.

06:03.720 --> 06:07.340
Das heißt, die Dienstfunktionalität wird als Prozedur gebildet aus

06:07.340 --> 06:08.060
verschiedenen Dienstprimitiven.

06:09.140 --> 06:11.280
Sehen Sie als Folie auf der Vorlesung.

06:11.780 --> 06:16.740
Nun gibt es, wir haben also jetzt hier praktisch spezifiziert, was für

06:16.740 --> 06:18.300
einen Dienst nehmen wir in Anspruch.

06:19.440 --> 06:22.300
Nun gibt es noch weitere Merkmale, nämlich wie nehmen wir die in

06:22.300 --> 06:22.740
Anspruch.

06:23.420 --> 06:25.480
Und das ist dann der Begriff Dienstmerkmale.

06:27.240 --> 06:28.440
Was haben wir denn da alles?

06:32.000 --> 06:33.660
Was wurde in der Vorlesung genannt?

06:35.520 --> 06:36.040
Ja,

06:41.820 --> 06:44.060
das wurde genannt Allgegenwart.

06:48.940 --> 06:54.060
Das heißt eben, wie Sie schon sagten, die Nutzung der Dienste von

06:54.060 --> 06:59.180
jedem Ort aus und natürlich mit jedem Gerät nach Möglichkeit.

07:03.470 --> 07:06.930
Was haben wir noch, vor allem jetzt mal in Bezug auf die Buchung, die

07:06.930 --> 07:08.290
wir gemacht haben vor dem Dienst?

07:08.390 --> 07:09.450
Was wünschen wir uns für die?

07:18.140 --> 07:22.500
Sicherheit ist gut, zähle ich mal zu weiteren Dienstmerkmalen.

07:31.130 --> 07:32.270
Bedeutungstreue ist ganz wichtig.

07:33.210 --> 07:36.630
Bedeutungstreue zählt auch zu den wichtigen Dienstmerkmalen.

07:38.330 --> 07:42.270
Wenn ich mit meinem Dienstgeber ausgemacht habe, wann mein Flug geht,

07:42.350 --> 07:45.150
und er nennt mir eine bestimmte Abflugzeit, dann muss uns beiden klar

07:45.150 --> 07:46.250
sein, was das für eine Zeit ist.

07:46.410 --> 07:48.510
Also wir dürfen uns zum Beispiel nicht in der Zeitzone irren.

07:53.830 --> 07:56.730
Das bedeutet also auf jeden Fall, ein eindeutiges Verständnis auf

07:56.730 --> 07:58.270
beiden Seiten über die Daten.

08:11.320 --> 08:14.380
Worauf ich noch hinaus wollte als Dienstmerkmal, vor allem bei der

08:14.380 --> 08:16.740
Buchung, war die Dauerhaftigkeit.

08:22.350 --> 08:24.050
Das heißt, ich erwarte natürlich, dass meine Buchung, wenn ich sie

08:24.050 --> 08:27.310
einmal getätigt habe, auf jeden Fall bleibt.

08:42.680 --> 08:46.540
Das sind so die großen Begriffe, die Sie auf jeden Fall im Hinterkopf

08:46.540 --> 08:47.280
behalten sollten.

08:47.800 --> 08:50.680
Wenn wir von einem Dienst wissen wollen, was in Bezug auf diese

08:50.680 --> 08:53.720
Dienstmerkmale, was ihn da auszeichnet, sollten Sie die parat haben.

08:54.180 --> 08:55.580
Was haben wir unten bei Sicherheit noch?

08:58.120 --> 09:07.020
Und das heißt natürlich Schutz gegen Manipulation und Verlust.

09:16.500 --> 09:17.960
Was wünschen wir uns da heute eigentlich auch?

09:18.200 --> 09:18.680
Datenschutz.

09:19.040 --> 09:22.180
Wir wissen, wenn wir in die USA fliegen heute, was mit den Daten

09:22.180 --> 09:22.560
passiert.

09:24.840 --> 09:26.240
Was weiteres noch für den Dienst?

09:26.240 --> 09:29.360
Wenn im Augenblick noch wenige Leute wissen, dass man sich als SMS

09:29.360 --> 09:32.200
-User registrieren kann, wenn es in Zukunft alle machen, was braucht

09:32.200 --> 09:33.640
man von dem Dienst als Anspruch?

09:39.860 --> 09:40.620
Meiniche nicht?

09:41.860 --> 09:43.240
Genau, er muss skalieren.

09:48.440 --> 09:49.640
Oder auch Leistung.

09:52.440 --> 09:55.020
Das heißt, er muss natürlich eine anwachsende Teilnehmerzahl

09:58.410 --> 10:01.190
verkraften.

10:06.040 --> 10:08.320
Das war im Grunde auch schon die ganze Aufgabe A.

10:08.320 --> 10:10.760
Die Funktionen, die Sie von dem Dienst wissen sollten.

10:11.840 --> 10:14.680
Es gibt Dienstnehmer und Dienstgeber, das ist relativ klar.

10:14.920 --> 10:17.220
Sie nehmen Dienstfunktionalitäten in Anspruch.

10:19.080 --> 10:20.640
Dienstfunktionalitäten werden dann wieder aufgebaut durch

10:20.640 --> 10:22.640
Dienstprimitive, da kommen wir nachher noch dazu.

10:24.360 --> 10:26.680
Und Dienstfunktionalitäten sind immer, was nehmen Sie von dem Dienst

10:26.680 --> 10:27.280
in Anspruch.

10:27.700 --> 10:30.460
Während es dann noch Dienstmerkmale gibt, die praktisch die Qualität

10:30.460 --> 10:32.300
angeben, mit der Sie diese Funktionen erhalten.

10:32.540 --> 10:34.400
Also eher, wie werden diese erbracht?

10:37.060 --> 10:38.220
Fragen noch hierzu?

10:41.400 --> 10:43.960
Wenn nein, tun wir das mal einordnen.

10:44.160 --> 10:46.860
In die Begriffe Disposition und Dispatching.

10:47.940 --> 10:50.840
Wir haben also die Merkmale von eben schon.

10:52.940 --> 10:56.560
Was haben wir denn im Sinne von der Disposition, das ja immer so ein

10:56.560 --> 11:00.020
bisschen die längerfristige Planung war, an Anforderungen an die

11:00.020 --> 11:00.840
Bedeutungstreue?

11:10.140 --> 11:12.980
Also wir haben natürlich Bedeutungstreue, wie wir es schon sagten, ein

11:12.980 --> 11:16.580
eindeutiges Verständnis zwischen Dienstnehmer und Dienstgeber.

11:17.080 --> 11:21.140
Wir wünschen uns also vor allem zuverlässige Daten für unsere Reise.

11:35.960 --> 11:38.980
Was haben wir bei all Gegenwart an die Disposition für Ansprüche?

11:39.840 --> 11:41.880
Ist das unser Hauptanspruch an die Disposition?

11:44.700 --> 11:47.860
Ich weise erneut darauf hin, Disposition war immer eher die

11:47.860 --> 11:49.040
längerfristige Planung.

11:51.280 --> 11:54.240
Da sind wir im Augenblick nicht so sehr dahinter, dass die

11:54.240 --> 11:55.360
allgegenwärtig ist.

11:55.700 --> 11:58.700
Also die können wir zuhause machen, die können wir bei einer

11:58.700 --> 12:00.320
Spedition, kann die im Büro machen.

12:01.140 --> 12:03.260
Das muss eventuell nicht überall möglich sein.

12:03.380 --> 12:07.240
Das heißt, hier sind wir eher bereit, Abstriche zu machen.

12:09.740 --> 12:11.640
Bei der Dauerhaftigkeit sind wir das nicht.

12:11.780 --> 12:15.720
Was wünschen wir uns da für meine Flugdaten?

12:21.530 --> 12:24.530
Klar, wir wollen jederzeit darauf zugreifen können, sie sollen auch

12:24.530 --> 12:25.950
jederzeit gespeichert bleiben.

12:28.330 --> 12:32.030
Rund um die Uhr, 24 Stunden den Tag, sieben Tage die Woche.

12:33.530 --> 12:36.070
Zur Robustheit und zur Sicherheit, ich habe eben schon eine Sache

12:36.070 --> 12:36.550
genannt.

12:44.380 --> 12:49.840
Wir wünschen uns, dass natürlich die persönlichen Daten von mir und

12:49.840 --> 12:51.000
meiner Reise geschützt sind.

12:57.820 --> 13:01.940
Sicherheit gegen Manipulation, Sicherheit gegen Missbrauch, alle diese

13:01.940 --> 13:02.220
Dinge.

13:02.780 --> 13:05.600
Und bei Skalierbarkeit und Leistung, also auch kein Hexenwerk.

13:06.280 --> 13:07.960
Wir müssen die Begriffe nur auf jeden Fall können.

13:08.980 --> 13:13.360
Dass wir kurze Zeiten haben, wenn wir zum Beispiel nach Flügen

13:13.360 --> 13:14.000
recherchieren.

13:17.990 --> 13:19.730
Ansonsten wechseln wir zu einem anderen Anbieter.

13:22.210 --> 13:24.810
Das sind die Ansprüche, die wir an die Disposition haben.

13:24.810 --> 13:28.370
In der Disposition eher so die mittel- bis längerfristige Planung ist.

13:28.810 --> 13:31.250
Es gab viele Beispiele, im Buch gibt es viele, in der Vorlesung gibt

13:31.250 --> 13:31.610
es viele.

13:32.050 --> 13:35.390
Die Spedition plant ihre Fahrten erstmal grob nach den längerfristig

13:35.390 --> 13:37.050
bekannten Aufträgen.

13:38.190 --> 13:42.970
Fluggesellschaften planen, Wartungstermine planen, Flugpläne und diese

13:42.970 --> 13:43.230
Dinge.

13:43.370 --> 13:45.890
Das heißt, die Disposition stellt eher Anforderungen

13:50.040 --> 13:55.500
an die Datenverwaltung.

14:00.130 --> 14:02.010
Also eigentlich eher Richtung 2.

14:02.110 --> 14:03.010
Teil der Vorlesung.

14:03.330 --> 14:07.610
Für alles, was längerfristig gebraucht wird, sprich was gespeichert

14:07.610 --> 14:11.310
wird über die Zeit hinweg, haben wir eher die Datenhaltung als

14:11.310 --> 14:12.710
Spezialgebiet.

14:14.010 --> 14:15.210
Das Ganze bei Dispatching.

14:15.470 --> 14:18.310
Ich stecke jetzt im Stau, ich brauche jetzt Informationen, ich muss

14:18.310 --> 14:19.450
jetzt meinen Flug umbuchen.

14:20.270 --> 14:23.410
Außer bei der Fluggesellschaft, das Cockpit-Team fällt jetzt aus, ich

14:23.410 --> 14:24.270
brauche jetzt ein neues.

14:24.410 --> 14:27.410
Oder bei einer Spedition, es kommt jetzt ein Anruf, es gibt noch eine

14:27.410 --> 14:29.710
neue Fahrt, der Fahrer muss jetzt sofort umplanen.

14:29.990 --> 14:31.450
Das ist genau der Unterschied zur Disposition.

14:31.730 --> 14:35.850
Das sind also die kurzfristigen Anforderungen an unseren Dienst.

14:35.950 --> 14:37.370
Was haben wir da bei Bedeutungstreue?

14:43.900 --> 14:46.060
Ein Beispiel hier ist zum Beispiel, dass wir

14:49.240 --> 14:55.740
Berücksichtigung von den aktuellsten Verkehrsinformationen haben.

15:04.650 --> 15:06.150
Anforderungen an die Allgegenwart hier.

15:10.400 --> 15:11.160
Ja, nein?

15:13.680 --> 15:14.040
Ja.

15:34.500 --> 15:37.180
Ich würde es auch eher so sehen, dass Bedeutungstreue heißt, wir sind

15:37.180 --> 15:39.600
uns einig, um welche Autobahn geht es, um welchen Weg geht es.

15:39.760 --> 15:42.140
In dem Fall heißt es eben eindeutiges Verständnis zwischen

15:42.140 --> 15:43.500
Dienstnehmer und Dienstgeber.

15:44.040 --> 15:46.240
Das eindeutige Verständnis in dem Fall halt, dass auch die

15:46.240 --> 15:47.960
Informationen wirklich aktuell sind.

15:48.120 --> 15:50.580
Also dass er mir keine Stauvorhersagen für die Ferienzeit liefert,

15:50.700 --> 15:51.960
sondern eben jetzt aktuelle.

15:52.980 --> 15:54.340
Aber ja klar, kann man diskutieren.

15:54.440 --> 15:55.800
Das kann man bei allen diesen Punkten machen.

15:59.640 --> 16:01.200
Und was haben wir bei Allgegenwart für Ansprüche?

16:01.320 --> 16:02.180
Wir haben es vorhin schon genannt.

16:03.420 --> 16:05.700
Haben wir die Ansprüche hier im Gegensatz zur Disposition?

16:12.240 --> 16:13.180
Genau, wir haben sie.

16:18.160 --> 16:20.960
Wir möchten also von überall in der Lage sein, auf aktuellste

16:20.960 --> 16:22.800
Ereignisse zu reagieren.

16:23.500 --> 16:25.260
Wie sieht es mit der Dauerhaftigkeit aus?

16:26.420 --> 16:27.980
Was ist da der Unterschied zur Disposition?

16:31.900 --> 16:34.440
Stellt sich uns die Frage, wenn wir auf aktuellste Ereignisse

16:34.440 --> 16:37.200
reagieren, dass die Sachen wirklich immer dauerhaft gespeichert

16:37.200 --> 16:37.520
bleiben?

16:44.190 --> 16:45.570
Nein, also nicht wirklich.

16:45.690 --> 16:48.930
Wir sind also bei dem Dispatching eher in der Lage, bei der

16:48.930 --> 16:51.070
Dauerhaftigkeit der Daten, Absprüche zu machen.

16:51.850 --> 16:54.770
Bei Robustheit und Sicherheit haben wir auf kurzfristige Kommunikation

16:54.770 --> 16:57.650
ebenfalls Ansprüche, die unterscheiden sich nicht besonders von der

16:57.650 --> 16:58.170
Disposition.

16:59.030 --> 17:03.810
Wir wünschen uns also auf jeden Fall keine Übertragungsfehler,

17:09.090 --> 17:12.310
keine Kommunikationsausfälle, also

17:18.860 --> 17:22.560
die gleichen Anforderungen an Robustheit und Sicherheit, nur im

17:22.560 --> 17:26.920
Gegensatz zur Datenhaltung, diesmal eben bezüglich der Kommunikation.

17:27.640 --> 17:29.820
Skalierbarkeit und Leistung unterscheiden sich ebenfalls nicht.

17:29.920 --> 17:34.780
Wir wünschen uns natürlich wieder kurze Recherchezeiten, schnelle

17:34.780 --> 17:35.280
Antwortzeiten.

17:40.250 --> 17:43.170
Und das Fazit unter das alles, auf das ich die ganze Zeit hinaus will,

17:44.370 --> 17:44.930
lautet wie?

17:45.130 --> 17:47.390
An was stellt das Dispatching eher Anforderungen?

17:47.510 --> 17:50.990
Wenn wir mal zurückschauen, Disposition stellt eher Anforderungen an

17:50.990 --> 17:54.010
die Datenverwaltung, dann wird das Dispatching wohl eher Anforderungen

17:54.010 --> 17:55.710
stellen an...

18:07.500 --> 18:07.940
exakt...

18:08.520 --> 18:10.120
an die Übertragung in diesem Fall.

18:15.060 --> 18:16.440
Soviel zur Aufgabe 1.

18:16.680 --> 18:17.560
Haben wir hier zu fragen.

18:17.860 --> 18:20.000
Also im Wesentlichen geht es auf jeden Fall um die Begriffe.

18:20.760 --> 18:23.720
Eher als Einleitung der Aufgabe gedacht, macht aber immer wieder

18:23.720 --> 18:24.460
Schwierigkeiten.

18:27.260 --> 18:30.500
Es werden immer wieder diese Dinge durcheinander geworfen und es...

18:30.500 --> 18:33.660
immer wieder mal ergibt es Probleme in Prüfungen.

18:36.780 --> 18:39.980
Aber im Grunde sind Disposition und Dispatching relativ einfache

18:39.980 --> 18:40.880
Dinge, die klar sind.

18:40.980 --> 18:43.100
Natürlich haben auch sie eben die Dienstmerkmale, die wir gerade

18:43.100 --> 18:43.940
aufgezählt haben.

18:45.740 --> 18:47.320
Gut, dann gehen wir zur Aufgabe 2.

18:49.340 --> 18:52.680
Viel Text, aber eher auch wieder eine Einleitung der Aufgabe.

18:54.120 --> 18:57.780
Wir haben ein Telekommunikationssystem und möchten eine

18:57.780 --> 19:00.100
Datenübertragung machen zwischen Kommunikationspartnern.

19:01.140 --> 19:03.120
Und dazu brauchen wir natürlich Grundfunktionen.

19:03.620 --> 19:06.400
Wir nennen es in diesem Fall mal Operationen, aber es sind eben auch

19:06.400 --> 19:10.160
wieder Funktionalitäten von dem Telekommunikationssystem, die

19:10.160 --> 19:11.380
notwendig sind.

19:11.820 --> 19:14.640
Welche Grundfunktionen sind denn notwendig, um die Datenübertragung zu

19:14.640 --> 19:15.300
gewährleisten?

19:20.840 --> 19:22.880
Fangen wir mal an, das Bild hinter mir zu füllen.

19:23.940 --> 19:25.960
Was ist in dem Fall das Telekommunikationssystem?

19:39.460 --> 19:39.860
Genau.

19:40.980 --> 19:43.540
Also wir haben hier auf jeden Fall unser Telekommunikationssystem,

19:43.860 --> 19:45.140
unser Medium, das wir benutzen.

19:50.630 --> 19:54.670
Und über das wollen wir, ich frage Sie nicht alles, die Aufgabe sagt

19:54.670 --> 19:56.750
es ja, wir wollen über dieses Daten übertragen.

20:03.230 --> 20:06.630
Das meiste davon klingt eben auch eher trivial, aber die Begriffe

20:06.630 --> 20:07.870
müssen wir auf jeden Fall können.

20:08.910 --> 20:11.790
In diesem Modell auch wieder am besten, wer ist Dienstnehmer, wer ist

20:11.790 --> 20:12.330
Dienstgeber?

20:14.730 --> 20:18.350
Wo haben wir in diesem Modell Dienstnehmer, wenn Kommunikationspartner

20:18.350 --> 20:21.290
miteinander kommunizieren wollen und ein Kommunikationssystem in

20:21.290 --> 20:21.870
Anspruch nehmen?

20:28.940 --> 20:30.000
Ist zu trivial?

20:31.260 --> 20:32.240
Unter Ihrer Würde.

20:34.020 --> 20:37.740
Man soll rein psychologisch niemanden aufrufen, aber ich sage ja

20:37.740 --> 20:38.560
nicht, dass ich fair bin.

20:49.360 --> 20:52.280
Das hängt jetzt eben von der Ansicht ab, das ist genau der Punkt, auf

20:52.280 --> 20:53.160
den ich hinaus wollte.

20:53.340 --> 20:55.020
Wir haben auf jeden Fall hier einen Dienstnehmer,

20:58.140 --> 21:00.000
nämlich den Kommunikationspartner A.

21:03.440 --> 21:04.940
Wo haben wir jetzt den Dienstgeber?

21:05.360 --> 21:06.440
Was haben wir auf der anderen Seite?

21:20.080 --> 21:23.080
Wir haben in diesem Fall hier auch auf der anderen Seite einen

21:23.080 --> 21:23.740
Dienstnehmer.

21:24.700 --> 21:26.720
Die Aufgabenstellung gibt es praktisch schon her.

21:28.580 --> 21:33.460
Beide Kommunikationspartner nutzen die Dienste des

21:33.460 --> 21:33.940
Telekommunikationssystems.

21:34.360 --> 21:35.880
Und dies ist dann der Diensterbringer,

21:41.960 --> 21:43.760
wieder der Betreiber dieses Systems.

21:49.530 --> 21:52.290
Auch an der Stelle kann man auf jeden Fall darüber diskutieren, weil

21:52.290 --> 21:55.050
wenn die Kommunikationspartner in einer kleinen Serverbeziehung

21:55.050 --> 21:57.670
stehen, dann nimmt natürlich Kommunikationspartner A auch wieder

21:57.670 --> 21:59.890
Dienst in Anspruch von Kommunikationspartner B.

21:59.890 --> 22:02.910
Da müssen wir also sehr genau auf den Kontext achten, in dem sowas

22:02.910 --> 22:03.850
immer gefragt wird.

22:15.360 --> 22:18.920
Ob die Dienstgeber Personen sein müssen, oder ob das Maschinen sein

22:18.920 --> 22:19.220
können?

22:20.420 --> 22:23.960
Es ist nicht gefordert, dass Dienstgeber immer Personen oder

22:23.960 --> 22:26.400
rechtliche Personen sind.

22:27.580 --> 22:29.660
Es reicht auch das Medium an sich.

22:31.300 --> 22:34.480
Also Dienstgeber in diesem Beispiel ist das Telekommunikationssystem,

22:34.480 --> 22:35.920
das Telekommunikationssystem an sich stellt Dienste zur Verfügung.

22:36.300 --> 22:39.600
Aber wer uns die Dienste erbringt, schreiben wir normalerweise in den

22:39.600 --> 22:40.920
Step -Provider dieses Systems.

22:45.950 --> 22:47.310
Gibt es hierzu jetzt noch Fragen?

22:53.090 --> 22:55.950
Wenn Kommunikationspartner A und B diese Dienste in Anspruch nehmen,

22:56.010 --> 22:58.790
um Daten zu übertragen, was brauchen wir da für Operationen?

22:59.170 --> 23:01.930
Was muss das Telekommunikationssystem zur Verfügung stellen an

23:01.930 --> 23:05.470
Operationen, damit wir Daten übertragen können zwischen diesen beiden

23:05.470 --> 23:06.150
Partnern?

23:06.910 --> 23:09.730
Ganz grundlegend gedacht, nicht zu kompliziert.

23:25.400 --> 23:25.640
Bitte?

23:30.500 --> 23:34.960
Genau, wir haben einen Dienstzugangspunkt, das ist hier, auf beiden

23:34.960 --> 23:40.280
Seiten, die Abkürzung Service Access Point, haben Sie drauf, ja.

23:41.240 --> 23:43.940
Aber was braucht man an Operationen an diesen Dienstzugangspunkten?

23:44.000 --> 23:45.680
Was muss uns das Medium zur Verfügung stellen?

23:46.660 --> 23:48.800
Ganz einfach gedacht, zum Datenübertragen.

23:54.870 --> 23:55.530
Request, ja.

23:56.130 --> 23:58.630
Wir sagen aber noch viel einfacher, wir sagen einfach mal Daten

23:58.630 --> 23:59.750
senden.

24:07.160 --> 24:09.960
Was muss es uns im Gegensatz natürlich Spiegelverkehr zur Verfügung

24:09.960 --> 24:10.360
stellen?

24:17.060 --> 24:19.000
Ich gestehe ein, das ist wirklich zu trivial.

24:19.240 --> 24:21.560
Wir müssen natürlich auch Daten empfangen können, wenn wir sie senden

24:21.560 --> 24:21.840
können.

24:23.680 --> 24:26.240
Jetzt ging es üblicherweise noch um die Frage der Parameter, die wir

24:26.240 --> 24:29.940
bei diesen Fragen mitschicken, bei diesen Operationen.

24:30.060 --> 24:32.320
Was können wir uns vorstellen, wenn wir Daten senden, was werden wir

24:32.320 --> 24:34.940
wohl für Parameter benötigen?

24:35.920 --> 24:37.680
Für diese Operationen.

24:43.320 --> 24:46.300
Spielt ein bisschen auf die Rolle von vorhin ein, aus der Vorlesung,

24:46.380 --> 24:48.380
was braucht man für einen Protokollkopf, alles für Felder.

24:50.460 --> 24:52.160
Die Daten selbst auf jeden Fall.

25:00.620 --> 25:03.620
Okay, je nachdem wie viele Dienstgeber wir haben, auch den Empfänger,

25:03.720 --> 25:05.440
nennen wir es mal Adressen.

25:13.040 --> 25:18.240
Und ich schreibe mir noch dazu weitere Anforderungen an die

25:18.240 --> 25:19.060
Dienstmerkmale.

25:22.220 --> 25:24.700
Wir hatten es auch vorhin in der Vorlesung, wir können eben, wenn wir

25:24.700 --> 25:26.440
irgendwelche Dienste in Anspruch nehmen, auch noch weitere

25:26.440 --> 25:27.460
Anforderungen mitschicken.

25:27.920 --> 25:30.300
Da geht es dann zu sehr ins Detail, also hier wollen wir mal nur ganz

25:30.300 --> 25:30.840
grob bleiben.

25:31.060 --> 25:33.340
Welche das sind, interessiert uns in diesem Fall mal nicht.

25:34.620 --> 25:37.080
Bei Datenempfangen haben wir dann einen grundlegenden Unterschied von

25:37.080 --> 25:38.300
diesen Parametern.

25:39.680 --> 25:42.540
Da das Ganze spiegelverkehrt ist, haben wir den natürlich nicht.

25:43.100 --> 25:47.140
Was können wir uns noch ausdenken, was uns das Medium zur Verfügung

25:47.140 --> 25:47.780
stellen sollte?

25:47.900 --> 25:49.160
Das Telekommunikationssystem.

25:57.000 --> 25:59.540
Im Grunde war das schon die Grundfunktionalität, die wir brauchen.

25:59.660 --> 26:01.540
Wir wollen Daten senden, wir wollen Daten empfangen.

26:06.980 --> 26:09.720
Alles was dann noch übrig ist, fassen wir in dieser Folie mal

26:09.720 --> 26:10.100
zusammen.

26:10.280 --> 26:13.740
Also unter der Überschrift den Datentransport steuern.

26:19.630 --> 26:22.030
Also was auch immer dann damit zusammenhängt.

26:22.970 --> 26:24.890
Beispielsweise das Aushandeln der Anforderungen.

26:31.200 --> 26:32.800
Oder das Überprüfen von Adressen.

26:42.550 --> 26:43.450
Das war es aber auch schon.

26:43.570 --> 26:47.630
Mehr Operationen brauchen wir auf dieser relativ hohen Denkweise, die

26:47.630 --> 26:48.570
wir gerade eingenommen haben.

26:48.750 --> 26:51.630
Nicht von dem Telekommunikationssystem, das uns Daten überträgt.

26:57.640 --> 26:59.500
Gut, haben wir Fragen hierzu?

27:00.200 --> 27:01.620
Dann kommen wir zur nächsten Aufgabe.

27:03.160 --> 27:05.660
Wo der Dateiserver in dem Netzwerk installiert war.

27:06.600 --> 27:09.240
Und dem Benutzer des Netzes erlaubt, Dateien abzulegen, Dateien

27:09.240 --> 27:09.940
abzuholen.

27:10.800 --> 27:13.540
Es wurde schon beschrieben in der Aufgabe, was er im Erfolgsfall

27:13.540 --> 27:14.260
jeweils tut.

27:14.500 --> 27:16.340
Was er im Fehlerfalle tut.

27:17.760 --> 27:19.660
Und was für Dienste das Medium anbietet.

27:21.140 --> 27:23.680
Wo zeichne ich jetzt die Dienstprimitive an, die uns das Medium

27:23.680 --> 27:24.220
anbietet?

27:25.040 --> 27:28.200
Genannt waren Data Request und Data Indication.

27:32.100 --> 27:33.960
Wir haben hier auf jeden Fall wieder unsere Dienstzugangspunkte.

27:36.120 --> 27:37.040
Wir haben unser Medium.

27:39.860 --> 27:43.360
In dem Fall unser Telekommunikationssystem.

27:54.820 --> 27:56.100
Fangen wir mal etwas höher an.

27:56.160 --> 27:57.500
Was haben wir links und was haben wir rechts?

27:58.440 --> 28:00.020
Auch wieder die Kommunikationspartner.

28:03.420 --> 28:04.360
Wir haben den Nutzer.

28:04.460 --> 28:06.360
Wer war der zweite Teilnehmer in diesem Szenario?

28:08.660 --> 28:09.860
Der Dateiserwerber.

28:11.440 --> 28:15.280
Was findet zwischen diesen beiden für eine horizontale Kommunikation

28:15.280 --> 28:15.540
statt?

28:15.980 --> 28:18.260
Horizontale Kommunikation, wie wir in der Vorlesung gelernt haben,

28:18.320 --> 28:19.380
immer auf der gleichen Ebene.

28:19.540 --> 28:20.920
Also zwischen diesen beiden Nutzern.

28:26.940 --> 28:30.120
Entweder die Anforderung...

28:31.460 --> 28:34.480
oder natürlich die Datei wird gespeichert.

28:39.000 --> 28:41.140
Und was hat der Server gemacht in den beiden Fällen?

28:43.700 --> 28:45.660
Im einen Fall hat er die Datei geschickt.

28:47.300 --> 28:48.480
Falls es funktioniert hat.

28:49.960 --> 28:52.280
Wenn ich eine Datei speichere, habe ich zwei Fälle.

28:52.980 --> 28:53.760
Es hat funktioniert.

28:54.960 --> 28:56.380
Dann kriege ich eine Bestätigung.

28:57.340 --> 28:59.400
Oder es hat nicht funktioniert, dann kriege ich natürlich eine

28:59.400 --> 28:59.980
Fehlermeldung.

29:03.640 --> 29:04.760
Wie machen die zwei das?

29:04.940 --> 29:07.440
Welche Kommunikation betreiben sie vertikal?

29:22.350 --> 29:24.850
Im Gegensatz zur horizontalen Kommunikation...

29:24.850 --> 29:28.150
geht die vertikale Kommunikation natürlich durch die Schichten durch.

29:28.270 --> 29:31.770
Das heißt Kommunikation zwischen den Dienstnehmern und dem

29:31.770 --> 29:32.370
Dienstgeber.

29:32.450 --> 29:34.590
In diesem Fall Dienstgeber, nicht der Server, sondern wieder das

29:34.590 --> 29:35.690
Kommunikationssystem.

29:42.600 --> 29:44.000
Was wird an diesem Punkt angeboten?

29:44.100 --> 29:45.380
Die Aufgabenstellung enthält es schon.

29:49.880 --> 29:51.620
Was muss ich an den linken Pfeil schreiben?

29:53.140 --> 29:54.960
Welche Dienstprimitive bietet mir das Medium?

30:02.760 --> 30:03.320
Genau.

30:05.180 --> 30:06.480
Das Data Request.

30:07.740 --> 30:10.320
Und auf der anderen Seite natürlich das Data Indication.

30:11.460 --> 30:12.640
Gleiches hier auch wieder.

30:19.210 --> 30:21.730
Da gehen wir im Folgenden noch sehr viel genauer drauf ein.

30:22.090 --> 30:26.650
Das Medium bietet mir das Dienstprimitiv an, das ich aufrufen kann, um

30:26.650 --> 30:27.690
Daten zu übertragen.

30:28.530 --> 30:31.670
Das Gegenstück, Data Indication, wir haben es vorhin in der Vorlesung

30:31.670 --> 30:36.110
gehabt, das Medium zeigt mir an, dass Daten anliegen.

30:37.430 --> 30:41.250
Und beide Kommunikationspartner können natürlich beide Operationen des

30:41.250 --> 30:43.150
Mediums in Anspruch nehmen.

30:44.430 --> 30:45.470
Gibt es hierzu Fragen?

30:51.160 --> 30:52.680
Wenn nicht, gehen wir zur dritten Aufgabe.

30:53.040 --> 30:55.220
Die ersten zwei waren zum Einsteigen.

30:55.760 --> 30:57.500
Viele Begriffe, sehr trivial.

30:58.840 --> 31:00.460
Auch die nächste wird noch relativ einfach.

31:00.860 --> 31:02.960
Dann steigen wir ein bisschen mehr ins Detail ein.

31:02.960 --> 31:05.580
Wir wären fast heute Morgen in der Vorlesung noch zum Alternating-Bit

31:05.580 --> 31:06.460
-Protokoll gekommen.

31:06.700 --> 31:08.260
Die Spezifikationen desselben.

31:08.840 --> 31:10.380
Wir machen gleich sowas ähnliches.

31:11.300 --> 31:13.340
Die nächsten zwei Aufgaben sind ziemlich wichtig.

31:16.140 --> 31:18.660
Alle Aufgaben sind wichtig, die nächsten sind besonders interessant.

31:19.560 --> 31:22.520
Und danach haben wir noch zwei leichtere, mit denen wir dann den

31:22.520 --> 31:23.420
Morgen heute beenden.

31:24.140 --> 31:28.840
Wir sollen also das Verhalten von Verbindungsauf- und Abbauphase mit

31:28.840 --> 31:30.960
einem Zustandsübergangsdiagramm beschreiben.

31:30.960 --> 31:33.240
Leider sind wir heute Morgen nicht mehr dazu in der Vorlesung

31:33.240 --> 31:37.100
gekommen, die Zustandsübergangsdiagramme vom Alternating-Bit-Protokoll

31:37.100 --> 31:38.500
aufzumalen.

31:38.640 --> 31:40.260
Dann wird vielleicht einiges klarer werden.

31:40.360 --> 31:42.160
Auf den Folien haben Sie sie, im Buch haben Sie sie.

31:42.960 --> 31:45.040
In der nächsten Vorlesung werden wir sie auch bringen.

31:45.200 --> 31:47.520
Wir machen es jetzt einfach mal ein Stückchen fast voraus.

31:48.920 --> 31:52.020
Die Schnittstellenereignisse, die wir haben, die Dienstprimitive, sind

31:52.020 --> 31:52.740
uns vorgegeben.

31:54.260 --> 31:58.040
Wir haben also um eine Verbindung, um eine Connection auf- und

31:58.040 --> 32:00.860
abzubauen, haben wir Connection-Request, ich fordere eben eine an.

32:01.460 --> 32:02.840
Wir haben Connection-Indication.

32:03.540 --> 32:06.760
Mir wird angezeigt, dass ein Verbindungsanforderungswunsch anliegt.

32:07.660 --> 32:10.480
Ich habe eine Connection-Response, das heißt, ich antworte auf diesen

32:10.480 --> 32:10.920
Wunsch.

32:11.880 --> 32:14.960
Wir haben eine Connection-Confirmation, das signalisiert demjenigen,

32:15.080 --> 32:17.800
der eine Verbindung anfordert, dass sie bestätigt wurde vom Empfänger.

32:20.460 --> 32:23.260
Disconnect, Request und Indication sollte dann eigentlich klar sein.

32:23.820 --> 32:26.860
Die Begriffe, das sind die Dienstprimitive, die wir heute Morgen in

32:26.860 --> 32:27.580
der Vorlesung hatten.

32:27.580 --> 32:31.020
Ich habe die Folie nochmal hier reingemacht, in weiser Voraussicht.

32:31.440 --> 32:34.900
Setzen sich immer zusammen aus Namen der Schicht die Dienstleistung

32:34.900 --> 32:37.160
und dann den Dienstgrundtyp.

32:37.360 --> 32:40.040
Parameter lassen wir im Augenblick mal außen vor sein, aber auf jeden

32:40.040 --> 32:41.240
Fall auch sehr interessant hier.

32:42.120 --> 32:47.240
Und wir hatten eben die Dienstleistung Connection und schauen uns

32:47.240 --> 32:49.320
hierzu die verschiedenen Dienstgrundtypen an.

32:49.960 --> 32:53.120
Und machen hieraus jetzt ein Zustandsübergangsdiagramm.

32:54.640 --> 32:56.360
Das ist hier vorbereitet.

32:58.280 --> 33:03.480
Und zwar müssen Sie hier jetzt ziemlich aufpassen, von was für

33:03.480 --> 33:08.100
Instanzen genau wir das Zustandsübergangsdiagramm wünschen.

33:08.300 --> 33:11.880
In diesem Fall machen wir es vom Medium, das heißt den Zustand, den

33:11.880 --> 33:15.500
das komplette Medium hier unten hat.

33:16.960 --> 33:19.480
Wir werden nachher das gleiche Diagramm noch machen von einer

33:19.480 --> 33:20.900
einzelnen Protokollinstanz.

33:20.900 --> 33:22.420
Und das unterscheidet sich ziemlich.

33:26.140 --> 33:29.160
Das heißt im Augenblick, wenn wir im Schichtenmodell denken, eine

33:29.160 --> 33:32.120
Schicht nimmt Dienst den Anspruch von einer anderen Schicht, über

33:32.120 --> 33:40.440
Dienstzugangspunkte und diskutiert dann mit einer anderen Schicht.

33:41.380 --> 33:49.090
Dann machen wir das Diagramm hier im Augenblick praktisch horizontal.

33:50.850 --> 33:53.630
Das heißt wir machen jetzt ein Zustandsübergangsdiagramm von dem

33:53.630 --> 33:55.830
Zustand, in dem sich das Medium befindet.

33:56.970 --> 34:01.070
Das heißt für uns spielt nur eine Rolle, das nach oben beobachtbare

34:01.070 --> 34:02.610
Verhalten des Dienstes.

34:12.820 --> 34:14.640
Das haben wir im Übrigen vorhin ausgelassen.

34:15.240 --> 34:16.140
Warum sagen Sie mir nichts?

34:18.720 --> 34:19.640
Nein, da kommen wir noch dazu.

34:21.740 --> 34:25.020
Wir haben einen Startzustand, der ist hier gekennzeichnet dadurch,

34:25.120 --> 34:27.880
dass er ein bisschen dicker schwarz umrandet ist.

34:28.820 --> 34:31.640
Was ist der Startzustand von meinem Medium, wenn es mir jetzt um ein

34:31.640 --> 34:33.540
Diagramm über Verbindungsaufbauten geht?

34:34.860 --> 34:35.880
Haben wir schon eine?

34:38.000 --> 34:39.520
Genau, wir haben noch keine Verbindung.

34:39.620 --> 34:40.820
Das ist unser Startzustand.

34:45.290 --> 34:48.650
Das heißt ich als Dienstnehmer möchte von einer Schicht, von einem

34:48.650 --> 34:51.250
Medium, dass es mir eine Verbindung aufbaut.

34:51.250 --> 34:55.770
Das Medium befindet sich zu Beginn in dem Zustand, es ist noch keine

34:55.770 --> 34:56.710
Verbindung aufgebaut.

34:57.010 --> 34:57.930
Da starten wir mal.

35:00.670 --> 35:05.910
Und die Primitive, die uns der Dienst anbietet, haben wir schon

35:05.910 --> 35:07.450
genannt bekommen in der Aufgabenstellung.

35:08.250 --> 35:17.010
Ich als Dienstnehmer fordere also von dem Dienst, dass es mir eine

35:17.010 --> 35:20.750
Verbindung aufbaut an und schicke einen Connection-Request von oben an

35:20.750 --> 35:21.410
dieses Medium.

35:23.630 --> 35:27.450
Die Notation für diese Zustandsübergangsdiagramme sieht wie folgt aus.

35:28.070 --> 35:32.050
Wir geben immer an das auslösende Dienst Primitiv, dann mit einem

35:32.050 --> 35:35.470
Strichpunkt das darauf folgende Dienst Primitiv.

35:37.730 --> 35:43.330
Wir wechseln also jetzt den Zustand im Medium, wenn das Medium von mir

35:43.330 --> 35:45.110
eine Connection-Request empfangen hat.

35:51.550 --> 35:54.330
Was passiert in dem Medium, wenn es von mir eine Connection-Request

35:54.330 --> 35:55.070
empfangen hat?

35:55.530 --> 35:58.850
Wir malen das gleiche mal auf, weil die Diagrammformen sehr eng

35:58.850 --> 36:01.970
zusammenhängen, in einem Zeitdiagramm.

36:07.050 --> 36:09.270
Ich erkläre Ihnen nachher noch kurz, wie die zusammenhängen.

36:10.350 --> 36:13.630
Wir haben also hier den Dienstnehmer 1, das sind wir hier.

36:14.390 --> 36:17.150
Wir haben den Dienstnehmer 2, das ist hier.

36:21.600 --> 36:26.720
So, was wir getan haben war, wir haben den Connection-Request an das

36:26.720 --> 36:27.480
Medium übergeben.

36:27.880 --> 36:30.260
Was kommt auf der anderen Seite raus und in welchem Zustand befindet

36:30.260 --> 36:31.100
sich das Medium dann?

36:38.840 --> 36:40.300
Connection-Indication habe ich gehört.

36:40.960 --> 36:43.380
Hier kommt eine Connection-Indication an, ganz genau.

36:44.060 --> 36:45.320
Die kommt hier raus.

36:46.600 --> 36:48.680
Und auf diese Art und Weise werden wir jetzt das Diagramm füllen.

36:48.680 --> 36:51.960
Die Connection-Indication, wie der Name schon sagt, zeigt dem

36:51.960 --> 36:55.340
Dienstnehmer, meinem Empfänger, auf der anderen Seite an, dass ein

36:55.340 --> 36:58.740
Verbindungswunsch an ihn anliegt.

36:59.760 --> 37:03.060
Wie wird dieser darauf reagieren, wenn er höflich ist und antwortet?

37:07.930 --> 37:08.390
Genau.

37:12.250 --> 37:16.110
Er antwortet also auf jeden Fall mit einer Connection-Response.

37:20.900 --> 37:24.120
So, weil wir gerade viele Diagramme zu füllen haben, haben wir hier

37:24.120 --> 37:24.700
was vergessen.

37:25.800 --> 37:33.500
Unser erster Pfeil resultierte in einer Connection-Indication auf der

37:33.500 --> 37:35.320
anderen Seite, auf Empfängerseite.

37:36.520 --> 37:39.100
Das ist ein Punkt, mit dem ich mich mit Kollegen ein bisschen über das

37:39.100 --> 37:40.340
Diagramm gestritten habe.

37:40.340 --> 37:42.180
Es wird ein bisschen vereinfacht.

37:42.600 --> 37:46.820
Es sollte eigentlich unterschieden werden, auf welchen Seiten Sender

37:46.820 --> 37:48.900
oder Empfänger diese Dienstprimitive auftreten.

37:49.100 --> 37:51.600
Streng genommen kommt das Connection-Request natürlich vom

37:51.600 --> 37:56.660
Verbindungsinitiator und das Connection-Indication wird angezeigt dem

37:56.660 --> 37:57.720
Verbindungsempfänger.

37:57.940 --> 37:59.320
Also hier müssen Sie ein bisschen aufpassen.

37:59.760 --> 38:00.840
Wir haben es jetzt hier vereinfacht.

38:00.840 --> 38:06.060
Das heißt, im Zustandsübergangsdiagramm hier unten sagen wir einfach

38:06.060 --> 38:09.720
das Connection-Request, das was von hier oben reinkam.

38:10.500 --> 38:14.180
Das Connection-Indication stellt praktisch das da, was auf der anderen

38:14.180 --> 38:15.060
Seite rauskommt.

38:15.480 --> 38:16.420
Das dreht sich aber um.

38:16.620 --> 38:17.540
Also passen Sie hier auf.

38:18.820 --> 38:21.140
Wenn Ihnen der Fall klar ist, können Sie das Diagramm normalerweise

38:21.140 --> 38:21.980
selber weiterfüllen.

38:23.100 --> 38:26.060
Wir überlegen uns, was für ein Primitiv kommt von oben rein, was macht

38:26.060 --> 38:28.620
das Medium darauf hin und in welchen Zustand wechselt das Medium

38:28.620 --> 38:32.220
jetzt, wenn es von dem Verbindungsinitiator ein Connection-Request

38:32.220 --> 38:36.680
erhalten hat und an den Empfänger ein Connection-Indication

38:36.680 --> 38:37.680
ausgeliefert hat.

38:40.220 --> 38:42.260
Dann sind wir ja in diesem Zustand gewechselt.

38:43.140 --> 38:45.080
In welchem Zustand befindet sich das Medium dann?

38:45.760 --> 38:46.860
Ist die Verbindung schon aufgebaut?

38:48.260 --> 38:48.560
Nein.

38:49.820 --> 38:50.180
Sondern?

38:57.150 --> 38:58.770
Wo befindet sich die Verbindung?

39:00.210 --> 39:01.270
Im Aufbau.

39:04.940 --> 39:07.060
So, das heißt, das Medium schwebt jetzt ein bisschen in der Luft.

39:07.200 --> 39:08.400
Es weiß nicht genau, was passiert ist.

39:08.760 --> 39:09.740
Es hat getan, was es konnte.

39:09.840 --> 39:13.020
Es hat eine Connection-Indication dem Empfänger angezeigt.

39:14.020 --> 39:16.220
Wir haben schon vorweggenommen, er antwortet mit einer Connection

39:16.220 --> 39:16.760
-Response.

39:16.840 --> 39:18.440
Wir haben es hier oben im Zeitdiagramm drin.

39:19.200 --> 39:22.000
Was kommt darauf hin beim Empfänger als Dienstprimitiv an der

39:22.000 --> 39:22.740
Schnittstelle an?

39:25.340 --> 39:27.200
Genau, eine Connection-Confirmation.

39:31.940 --> 39:33.220
So, wo wird die rauskommen?

39:34.960 --> 39:36.080
Trivial, hier.

39:41.680 --> 39:44.100
So, und was ist im unteren Zustandsdiagramm passiert?

39:46.960 --> 39:48.160
Was haben wir hier bekommen?

39:50.520 --> 39:53.160
Sie müssen einfach nur das Zeitdiagramm anschauen und es hier unten

39:53.160 --> 39:53.680
übertragen.

39:57.230 --> 39:58.290
Genau, die Response.

39:59.250 --> 40:01.250
Das ist jetzt der springende Punkt, wo kam die her?

40:04.760 --> 40:07.520
Nicht weiter schwierig, das war die Antwort von dem gerufenen

40:07.520 --> 40:08.060
Teilnehmer.

40:08.060 --> 40:09.660
Also hier müssen Sie ein bisschen aufpassen.

40:11.040 --> 40:15.460
Und resultierte dann in einer Connection-Confirmation an den

40:15.460 --> 40:17.500
Verbindungsaufbauer.

40:18.460 --> 40:19.780
Was ist danach mit der Verbindung?

40:23.120 --> 40:26.100
Wenn wir in dem Fall unbestätigte Verbindungsaufbauten betrachten,

40:29.690 --> 40:32.670
dann ist die Verbindung hiermit aufgebaut.

40:35.250 --> 40:38.150
Das war jetzt ein Weg durch das Zustandsübergangsdiagramm, das ist

40:38.150 --> 40:39.410
natürlich noch nicht vollständig.

40:39.410 --> 40:48.830
Und das ist ganz genau auch der Zusammenhang von den Zeitdiagrammen zu

40:48.830 --> 40:50.490
den Zustandsübergangsdiagrammen.

40:52.650 --> 40:56.750
Der Weg, den wir im Zeitdiagramm nehmen, wenn wir uns anschauen, wie

40:56.750 --> 40:59.590
die Daten ausgetauscht werden und was für Daten ausgetauscht werden,

41:00.890 --> 41:06.670
entspricht ganz genau einem solchen Weg im Zustandsübergangsdiagramm.

41:10.320 --> 41:12.640
Damit müssen Sie sehr gut umgehen können mit sowas.

41:12.940 --> 41:15.900
Sehr beliebte Klausuraufgaben, solche Dinge.

41:17.020 --> 41:19.060
Das hier ist noch einfach, wir machen gleich ein bisschen noch ein

41:19.060 --> 41:19.640
komplexeres.

41:19.860 --> 41:22.000
Sie sind nicht wirklich schwer, man muss sich nur ein bisschen

41:22.000 --> 41:22.740
Gedanken machen.

41:23.200 --> 41:24.740
Wir sind natürlich auch noch nicht fertig.

41:25.400 --> 41:28.180
Wir sollten ja gleichzeitig noch die Dienstabbaufase modellieren.

41:29.700 --> 41:33.660
Die entsprechenden Dienstprimitive heißen wie?

41:35.680 --> 41:38.280
Also ablesen aus der Aufgabenstellung fordere ich tatsächlich nichts

41:38.280 --> 41:38.640
von Ihnen.

41:39.180 --> 41:40.300
Aber wo können sie auftreten?

41:41.160 --> 41:42.440
Es geht um Disconnect diesmal.

41:46.360 --> 41:49.500
Wer von den Dienstnehmern kann ein Disconnect-Request schicken?

41:49.660 --> 41:51.340
Also die Bitte, die Verbindung wieder abzubauen.

41:53.600 --> 41:54.620
Im Prinzip beide.

41:55.360 --> 41:57.660
Nicht nur im Prinzip, das können auf jeden Fall beide tun.

41:57.660 --> 42:00.340
Ich schreibe es im Augenblick mal auf.

42:02.220 --> 42:03.860
Ich schreibe es auch mal gleich auf beide Seiten.

42:04.200 --> 42:05.000
Vergessen wir weniger.

42:05.960 --> 42:08.320
Beide Dienstnehmer können fordern, die Verbindung abzubauen.

42:09.200 --> 42:11.100
Jetzt müssen wir das Diagramm unten natürlich noch füllen.

42:11.540 --> 42:13.560
Sie sehen bei zwei Pfeilen, dass es uns noch fehlt.

42:14.080 --> 42:19.100
Wenn die Verbindung aufgebaut ist und einer der Teilnehmer, egal

42:19.100 --> 42:22.020
welcher, schickt ein Disconnect-Request, dann tut das Medium was?

42:35.700 --> 42:36.260
Genau.

42:37.720 --> 42:39.400
Sie sehen, Sie haben es drauf.

42:39.840 --> 42:41.520
Sie sind schneller fertig, wenn Sie es einfach sagen.

42:41.900 --> 42:44.340
Es schickt eine Disconnect-Indication natürlich an den anderen.

42:45.040 --> 42:46.660
Die können wir dann hier oben wieder beobachten.

42:51.080 --> 42:58.360
So, egal welcher Teilnehmer schickt ein Disconnect-Request.

42:59.540 --> 43:03.420
Der andere erhält eine Disconnect-Indication.

43:05.060 --> 43:07.580
Das ist der Zusammenhang von diesem Zeitdiagramm und dem

43:07.580 --> 43:08.920
Zustandsübergangsdiagramm.

43:09.120 --> 43:11.980
Beides, wie gesagt, immer sehr gerne Themen für Prüfungen und

43:11.980 --> 43:12.440
Klausuren.

43:13.640 --> 43:16.580
So, und das ganz genau gleiche, ich versuche es nicht zu langweilen,

43:16.680 --> 43:18.880
aber das ganz genau gleiche kann uns passieren, wenn die Verbindung im

43:18.880 --> 43:19.420
Aufbau ist.

43:20.660 --> 43:23.200
Natürlich kann der andere Teilnehmer sinnigerweise in diesem Fall,

43:23.320 --> 43:27.860
anstatt mit einer Connection-Response auch antworten, dass er lieber

43:27.860 --> 43:29.160
Disconnect -Requests wünscht.

43:29.160 --> 43:35.230
Wenn er sehr unhöflich ist, antwortet er gar nicht.

43:35.770 --> 43:37.930
Beliebte Firewall-Einstellungen im Internet.

43:39.630 --> 43:40.630
Was machen wir dann?

43:44.920 --> 43:46.940
Genau, dann brauchen wir eigentlich noch irgendwelche Timer.

43:47.240 --> 43:50.740
Sie sehen, das Zustandsübergangsdiagramm, das wir aufgemalt haben, ist

43:50.740 --> 43:52.680
noch längst nicht alles, was wir betrachten müssen im

43:52.680 --> 43:53.600
Kommunikationssektor.

43:53.700 --> 43:55.360
Da kämen dann noch solche Timer rein.

43:56.060 --> 43:59.100
Es gibt auch spontane Übergänge, wenn zum Beispiel der Provider uns

43:59.100 --> 44:01.800
ohne irgendwelche Anforderungen ans Medium, wenn das Medium uns einen

44:01.800 --> 44:04.460
Provider ab Bord schickt, würde der einfach spontan in diesem Fall

44:04.460 --> 44:05.020
auftreten.

44:05.380 --> 44:07.640
Können wir hier auch noch reinfüllen, war in der Aufgabenstellung aber

44:07.640 --> 44:08.280
nicht gefordert.

44:08.680 --> 44:10.620
Ist aber auch auf jeden Fall alles gar nicht schwierig.

44:11.940 --> 44:13.100
Haben Sie Fragen hierzu?

44:22.940 --> 44:27.660
Wir haben in diesem Fall, geht die Disconnect-Indication, wird dadurch

44:27.660 --> 44:30.140
erzeugt, dass einer der Teilnehmer ein Disconnect-Request schickt.

44:30.860 --> 44:33.560
Das heißt, der weiß schon, dass er die Verbindung abbauen will.

44:37.010 --> 44:40.390
Sie würde an beide Teilnehmer geschickt, wenn das Medium einen Abbruch

44:40.390 --> 44:41.630
schickt, also der Provider.

44:42.210 --> 44:44.390
Das war noch das Beispiel heute Morgen aus der Vorlesung.

44:44.970 --> 44:48.490
Wenn es irgendein Problem hier im Medium gibt, die Verbindung bricht

44:48.490 --> 44:52.390
zusammen, dann würde mir das Medium einen Provider ab Bord schicken.

44:52.650 --> 44:54.370
Der ist aber jetzt in dieser Aufgabe nicht Thema.

44:54.530 --> 44:55.770
Der würde dann an beide gehen.

45:02.960 --> 45:03.740
Klar, oder?

45:05.080 --> 45:06.100
Noch immer unklar.

45:06.660 --> 45:08.340
Aber hier wie gesagt, nicht mal das Thema.

45:09.240 --> 45:12.580
Klar, was ich natürlich vergessen habe, es können auch beide Seiten

45:12.580 --> 45:18.700
die Verbindung erhalten oder können die Verbindung aufbauen wollen.

45:18.880 --> 45:22.540
Also ist das Ganze natürlich jeweils spiegelsymmetrisch.

45:30.270 --> 45:33.530
Das war schon die ganze Aufgabe A.

45:35.710 --> 45:38.570
Und achten Sie, wenn wir so etwas fragen, darauf, was wir fragen.

45:38.690 --> 45:41.830
In diesem Fall das Zustandsübergangsdiagramm des Mediums.

45:41.830 --> 45:44.290
Das ist in der Aufgabenstellung nicht erwähnt.

45:44.370 --> 45:46.890
In der Klausur würde ich es noch ein bisschen klarer machen, sollte so

45:46.890 --> 45:47.910
eine Aufgabe vorkommen.

45:49.390 --> 45:50.930
Da kann man sich nämlich lang darüber streiten.

45:51.010 --> 45:53.510
Dieses Zustandsübergangsdiagramm werden wir nämlich gleich auch noch

45:53.510 --> 45:54.970
für die Protokollinstanz machen.

45:55.890 --> 45:57.630
Also achten Sie darauf, es gibt verschiedene

45:57.630 --> 45:59.930
Zustandsübergangsdiagramme, welches gewünscht ist.

46:01.110 --> 46:06.170
In diesem Fall beschreibt das Zustandsübergangsdiagramm nämlich

46:06.170 --> 46:11.470
schlicht und ergreifend das von der Schicht hier über dieser

46:11.470 --> 46:16.030
Connectionsschicht beobachtbare Verhalten.

46:16.310 --> 46:19.530
Was kriegt die Anwendung hier oben drüber zu sehen?

46:20.410 --> 46:21.530
Und zwar auf beiden Seiten.

46:22.110 --> 46:23.770
Deswegen habe ich hier blau eingezeichnet.

46:24.150 --> 46:27.550
Wir spezifizieren praktisch den Zustandsübergangskraft des Mediums.

46:28.550 --> 46:29.310
Fragen?

46:32.250 --> 46:34.910
Wenn nicht, erweitern wir das Diagramm nämlich jetzt noch um den

46:34.910 --> 46:38.510
Datenaustausch, nicht nur um den Verbindungsaufbau.

46:40.710 --> 46:44.810
Und abbauen wollen, soll möglich sein, die Verbindung jederzeit

46:44.810 --> 46:45.370
abzubauen.

46:45.750 --> 46:49.250
Wir brauchen also zunächst mal weitere Schnittstellenereignisse,

46:49.390 --> 46:49.730
primitive.

46:49.990 --> 46:52.730
Wir brauchen DatRequest und DatIndication, wie wir es schon vorhin

46:52.730 --> 46:53.420
hatten, zur Datenübertragung.

46:54.710 --> 46:57.510
Und das gleiche noch für den bestätigten Datentransfer später.

46:59.250 --> 47:00.750
Das hier haben wir eben aufgemalt.

47:01.110 --> 47:03.470
Was haben wir jetzt noch als zusätzliche Ereignisse reinbekommen?

47:05.210 --> 47:07.410
Wir haben natürlich DatRequest reinbekommen.

47:09.150 --> 47:11.950
Was wird passieren, wenn ich ein DatRequest auf der einen Seite in das

47:11.950 --> 47:12.770
Medium reinwerfe?

47:18.430 --> 47:20.090
Genau, ich habe es gehört.

47:20.150 --> 47:22.550
Auf der anderen Seite wird natürlich ein DatIndication rauskommen.

47:25.210 --> 47:28.770
Und da wir im ersten Fall einen unbestätigten Datentransfer haben

47:28.770 --> 47:31.610
wollen, können wir den natürlich nur durchführen, wenn die Verbindung

47:31.610 --> 47:32.390
aufgebaut ist.

47:32.950 --> 47:35.450
Und es gibt auch keine weiteren Zustände.

47:35.730 --> 47:42.030
Es findet schlicht und ergreifend ein Übergang statt vom

47:42.030 --> 47:46.710
Datenaustausch zum Datenaustausch, der eben vorsieht, dass auf der

47:46.710 --> 47:51.450
einen Seite ein DatRequest eingeht, das auf der anderen Seite in einer

47:51.450 --> 47:53.570
DatIndication resultiert.

47:55.030 --> 47:57.950
Das Ganze selbstverständlich auch wieder spiegelverkehrt.

48:04.690 --> 48:06.830
So, und abbauen können wir die Verbindung hier schon wieder.

48:06.910 --> 48:10.190
Das haben wir vorhin schon eingetragen, von beiden Zuständen jeweils.

48:12.990 --> 48:13.870
Das war es auch schon.

48:13.970 --> 48:14.770
Das ist das Tolle daran.

48:14.910 --> 48:17.690
Unbestätigter Datentransfer ist immer sehr einfach zu spezifizieren.

48:18.310 --> 48:20.970
Wir haben eine aufgebaute Verbindung, jagen Daten durch, die kommen am

48:20.970 --> 48:23.350
anderen Ende raus und das war auch schon alles.

48:26.490 --> 48:30.610
Jetzt machen wir das gleiche mal mit dem bestätigten Datentransfer.

48:30.710 --> 48:31.870
Bestätigter Datentransfer.

48:34.570 --> 48:38.570
Was gibt es noch für Fälle im bestätigten Datentransfer

48:38.570 --> 48:40.530
-Zustandsübergangsdiagramm?

48:41.710 --> 48:46.110
Wir hatten vorhin nur den Zustand Verbindung aufgebaut und wenn wir

48:46.110 --> 48:48.330
Daten ausgetauscht haben, waren wir wieder im Zustand Verbindung

48:48.330 --> 48:48.910
aufgebaut.

48:48.910 --> 48:52.110
Wenn wir auf Bestätigung warten müssen, was gibt es dann jetzt noch?

48:58.130 --> 48:59.350
Irgendjemand und ein bisschen lauter.

49:03.180 --> 49:05.360
Wir haben es vorhin in der Vorlesung gehört, konkurrierender Zugriff

49:05.360 --> 49:07.160
auf das Medium zu mir.

49:07.960 --> 49:09.120
Und ich bin ganz nett.

49:20.760 --> 49:25.080
Das sind die zusätzlichen Schnittstellenereignisse, die wir haben.

49:25.680 --> 49:31.140
Wir fordern jetzt auf ein Data-Request, das wir auf der anderen Seite

49:31.140 --> 49:36.120
mit einem Data-Indication anzeigen, fordern wir jetzt ein Data

49:36.120 --> 49:38.000
-Response, wie ich es gerade gehört habe, ganz genau.

49:39.360 --> 49:45.840
Das wird am anderen Ende wieder eintreffen als Data-Confirmation, ganz

49:45.840 --> 49:46.160
genau.

49:47.020 --> 49:49.220
Und das gleiche auch wieder spiegelverkehrt, selbstverständlich.

49:54.350 --> 49:56.630
So, das ist das, was von außen beobachtbar sein wird.

49:56.690 --> 49:58.890
Wenn wir ein Zeitdiagramm malen, sehen wir es da drin auch wieder.

49:59.330 --> 50:01.090
Das ist, glaube ich, zu trivial, um es wieder mitzulangen.

50:01.570 --> 50:02.990
Was werden wir noch für einen Zustand haben?

50:19.300 --> 50:20.420
Wirklich gar nicht schwierig, gell?

50:21.080 --> 50:22.960
Ich fasse es schnell zusammen und mache es noch schnell auf.

50:23.040 --> 50:26.060
Genau, Datenempfang haben wir noch als Zustand, warten auf

50:26.060 --> 50:26.720
Bestätigung.

50:30.420 --> 50:32.960
Das ist einfach, wenn Sie es sich mal logisch überlegen, denn nächster

50:32.960 --> 50:34.440
Zustand in dem das Medium jetzt sein kann.

50:34.520 --> 50:36.820
Ich habe Daten reingeworfen, das Medium hat sie abgeliefert.

50:36.960 --> 50:38.180
Genau das gleiche wie bei der Verbindung.

50:38.520 --> 50:40.920
Mehr weiß es noch nicht, es hat noch keine Antwort bekommen.

50:40.920 --> 50:46.560
In diesem Zustand gelangen wir, selbstverständlich, wenn wir Daten

50:46.560 --> 51:00.160
übertragen, die auf der anderen Seite mit einem Data Indication

51:00.160 --> 51:02.420
angezeigt werden, sind wir in diesem neuen Zustand.

51:03.480 --> 51:04.480
Ich komme mal wieder raus.

51:08.220 --> 51:10.820
Was muss passieren, damit das Medium weiß, die Daten sind angekommen?

51:13.560 --> 51:15.580
Genau, Data Response.

51:15.780 --> 51:17.120
Und wie wird es mir das anzeigen?

51:17.620 --> 51:19.100
Mit dem Data Confirmation.

51:20.840 --> 51:22.160
Und was haben wir noch gehört eben?

51:22.440 --> 51:23.840
Was in der Antwort schon enthalten war?

51:23.920 --> 51:26.420
Wir müssen auch von diesem Zustand die Verbindung abbauen können,

51:27.000 --> 51:29.520
sonst könnten wir nach verlorenen Daten die Verbindung nie abbauen.

51:30.000 --> 51:34.400
Das heißt, wir haben auch hier schlicht und ergreifend den

51:34.400 --> 51:34.820
Verbindungsdienstabbau.

51:38.960 --> 51:39.760
Fragen hierzu?

51:39.860 --> 51:40.680
Ich denke keine.

51:41.380 --> 51:44.120
Nichtsdestotrotz, nicht ganz einfach, wenn man ein leeres Blatt vor

51:44.120 --> 51:45.300
sich hat, das aufzumalen.

51:47.500 --> 51:50.480
Man kann es logisch entwickeln, das ist genau das, worauf ich Sie ein

51:50.480 --> 51:51.140
bisschen hinführen will.

51:51.220 --> 51:53.660
Überlegen Sie es sich, versetzen Sie sich in die Lage von diesem

51:53.660 --> 51:54.820
Modell.

52:04.710 --> 52:07.830
Wie ich vorhin schon erwähnt habe, es ist immer eine Frage, an welcher

52:07.830 --> 52:10.430
Stelle kommt es ins Netz rein, an welcher kommt es raus.

52:10.430 --> 52:14.130
Also streng genommen müssten wir bei diesen Dingen jeweils

52:14.130 --> 52:19.030
dazuschreiben, von wem das Data Indication kommt, an wen die Data

52:19.030 --> 52:21.870
Indication ging, die auf das Data Request von der anderen Seite

52:21.870 --> 52:22.390
folgte.

52:25.750 --> 52:28.350
In dem Fall sollten wir das tun, ja, das übergehen wir hier.

52:29.150 --> 52:32.130
Also wir machen praktisch Datenaustauschverbindungsabbau immer nur in

52:32.130 --> 52:32.650
eine Richtung.

52:32.770 --> 52:35.590
Das Medium kann sich natürlich im Zustand befinden, dass es in die

52:35.590 --> 52:39.470
eine Seite Daten übertragen hat und dort auf eine Bestätigung wartet

52:39.470 --> 52:41.390
oder das Ganze auf der anderen Seite geschehen ist.

52:42.130 --> 52:45.310
Für jemanden, für eine Anwendung, die das Medium von oben betrachtet

52:45.310 --> 52:48.890
und eben die Zustände vom Medium sich dafür interessiert, macht das

52:48.890 --> 52:51.210
aber keinen Unterschied, weil entweder hat sie Daten geschickt und

52:51.210 --> 52:55.070
wartet auf deren Bestätigung, also seine Seite des Mediums wartet auf

52:55.070 --> 52:57.810
dessen Bestätigung oder umgekehrt.

53:01.870 --> 53:04.370
Aber wenn Sie hierzu ansonsten keine Fragen mehr haben, machen wir das

53:04.370 --> 53:05.790
Ganze noch ein bisschen ausführlicher.

53:06.270 --> 53:07.550
In der nächsten Aufgabe,

53:11.340 --> 53:13.120
in der es jetzt um Protokollinstanzen geht.

53:13.240 --> 53:14.540
Und das ist jetzt der große Unterschied.

53:15.020 --> 53:17.700
Wir schauen uns nämlich jetzt auch noch an, was die Protokollinstanzen

53:17.700 --> 53:21.640
und nicht nur das Medium alleine von oben zu beobachten liefert,

53:22.320 --> 53:24.460
sondern was die Protokollinstanzen miteinander machen.

53:25.920 --> 53:28.900
Protokollinstanzen erzeugen, hatten wir in der Vorlesung, wenn ein

53:28.900 --> 53:31.500
Dienstprimitiv eintrifft, eine Protokoll-Data-Unit.

53:32.900 --> 53:35.940
Protokoll-Data-Unit, die gibt es wiederum weiter an die Schicht

53:35.940 --> 53:38.900
darunter und dieser Schicht, das wollte ich hier nochmal einfügen, um

53:38.900 --> 53:43.000
es klarer zu machen, der gibt sie diese Daten als Nutzdaten weiter.

53:43.260 --> 53:47.140
Das heißt, die darunter liegende Schicht hat davon keine Ahnung.

53:47.260 --> 53:49.740
Das sind einfach Daten, die die darunter liegende Schicht übertragen

53:49.740 --> 53:50.000
soll.

53:50.080 --> 53:52.820
Was in diesen Daten drin steht, das können eben Protokoll-Data-Units

53:52.820 --> 53:54.320
von der darüber liegenden Schicht sein.

53:54.980 --> 53:57.660
Wir haben über die Header-Einkapselung, wo das Stückweise vor sich

53:57.660 --> 53:58.560
geht, alles gelernt.

54:01.420 --> 54:03.720
Genauso funktioniert das natürlich umgekehrt.

54:03.720 --> 54:05.880
Und wir sollen jetzt anhand eines Modells mal die Unterscheidung

54:05.880 --> 54:08.780
spezifizieren, auf die wir ein bisschen hinaus wollen, zwischen

54:08.780 --> 54:11.920
Dienstspezifikation und Protokollspezifikation.

54:13.660 --> 54:15.340
Ich habe das hier mal für Sie vorbereitet.

54:18.180 --> 54:21.000
Wir haben auf jeden Fall wieder Dienstnutzer, das sollte uns

54:21.000 --> 54:23.880
mittlerweile klar sein und damit belästige ich Sie auch gar nicht

54:23.880 --> 54:24.120
mehr.

54:25.820 --> 54:27.120
Was haben wir an dieser Stelle?

54:27.220 --> 54:29.740
Wir hatten es vorhin auch schon ein paar Mal gesagt.

54:32.080 --> 54:35.480
Kennen Sie also mittlerweile auch schon, wie Frau Zitterbart so schön

54:35.480 --> 54:37.340
gesagt hat, wenn wir Sie nachts aufwecken und wissen wollen, was

54:37.340 --> 54:40.280
dieser Kreis ist, das ist Ihr Service Access Point, Ihr

54:40.280 --> 54:40.740
Dienstzugangspunkt.

54:44.040 --> 54:49.520
Und was bildet, hier dargestellt durch diesen Block, im Grunde in der

54:49.520 --> 54:53.860
Vorlesung bezeichnet als diese Linie hier.

54:54.420 --> 54:55.800
Was ist genau diese Linie hier?

54:57.900 --> 54:59.820
Genau, ich habe es gehört, das ist die Dienstschnittstelle.

55:11.710 --> 55:14.730
Und jetzt kommt die interessante Frage, das war der eine Teil der

55:14.730 --> 55:15.170
Aufgabe.

55:16.470 --> 55:19.010
Die Unterscheidung zwischen Dienstspezifikation und

55:19.010 --> 55:20.430
Protokollspezifikation.

55:21.350 --> 55:24.050
Was ist jetzt, das stellt diese Abbildung dar, was ist jetzt die

55:24.050 --> 55:25.330
Dienstspezifikation?

55:26.410 --> 55:27.410
Was spezifiziert sie?

55:33.900 --> 55:40.520
Ja, ganz genau, die Reaktion nach außen und das ist ziemlich wichtig.

55:41.620 --> 55:44.360
Die sind auch ganz kurze Definitionen, die lohnt sich auch auswendig

55:44.360 --> 55:44.800
zu lernen.

55:47.000 --> 55:52.920
Diese Spezifikation beschreibt, dass und natürlich an dieser

55:52.920 --> 56:09.900
Dienstschnittstelle, von außen zu

56:16.930 --> 56:20.690
beobachtbare Verhalten eines

56:25.230 --> 56:25.890
Dienstes.

56:26.910 --> 56:28.830
Und das haben wir gerade eben spezifiziert.

56:28.950 --> 56:32.350
Das heißt, wir haben geschaut, was die Schicht, die da rüber liegt und

56:32.350 --> 56:35.430
die die Dienst in Anspruch nimmt, was beobachtet die von außen, was an

56:35.430 --> 56:36.270
diesem Dienst geschieht.

56:37.050 --> 56:38.750
Und wir haben es, das haben wir gerade eben angesprochen, nicht nur

56:38.750 --> 56:41.050
von einer Seite gemacht, sondern von beiden Seiten, das stimmt

56:41.050 --> 56:41.430
natürlich.

56:41.430 --> 56:43.430
Also horizontal gewissermaßen.

56:44.550 --> 56:48.350
Und das ist die sehr wichtige Definition für die Dienstspezifikation.

56:49.450 --> 56:51.430
Ganz einfach, was beobachte ich von außen?

56:51.970 --> 56:53.090
Ich möchte den Dienst nutzen.

56:53.970 --> 56:55.270
Wie ist der Dienst spezifiziert?

56:55.370 --> 56:56.410
Was sehe ich an dem Dienst?

56:57.510 --> 56:59.970
Wer liebt die Fragen in Prüfungen immer wieder, wenn es eine Rolle

56:59.970 --> 57:04.150
spielt, ob ein Dienst unbestätigt ist oder nicht, dann wird immer

57:04.150 --> 57:06.910
wieder genannt, das hängt mit dem Protokoll zusammen oder so, das ist

57:06.910 --> 57:07.370
nicht so.

57:07.530 --> 57:10.130
Es hängt einfach nur zusammen, wie ist der Dienst spezifiziert?

57:10.690 --> 57:14.050
Was für eine Vereinbarung ist getroffen, wie dieser Dienst abläuft?

57:14.650 --> 57:17.250
Wenn gesagt wird, dass der bestätigt ist, dann muss das Protokoll, das

57:17.250 --> 57:18.730
jetzt abläuft, sich natürlich darum kümmern.

57:19.670 --> 57:21.810
Wenn das nicht der Fall ist, nicht, da kommen wir jetzt dazu.

57:22.190 --> 57:23.730
Was haben wir auf der anderen Seite alles?

57:25.910 --> 57:29.350
Da ist ein bisschen detaillierter aufgezeichnet.

57:29.430 --> 57:31.070
Wir haben wieder den Dienstnutzer oben.

57:32.330 --> 57:33.470
Was sind die Kästen da drin?

57:35.670 --> 57:36.190
Diese hier.

57:39.310 --> 57:42.050
Sie kennen es aus den Bildern aus der Vorlesung?

57:44.350 --> 57:44.870
Genau.

57:45.590 --> 57:46.990
Das sind die Protokollinstanzen.

58:01.710 --> 58:03.190
So, und was nutzen die wiederum?

58:03.770 --> 58:05.930
Schönes Schichtenmodell, wie wir es jetzt oft genug hatten.

58:06.490 --> 58:09.730
Die nutzen natürlich jetzt wieder die darunter liegende Schicht.

58:19.720 --> 58:23.240
So, und während die Dienstspezifikation was beschreibt?

58:23.240 --> 58:25.480
Horizontale oder vertikale Kommunikation eher?

58:27.960 --> 58:28.440
Bitte?

58:29.520 --> 58:30.500
Fifty-fifty Chance.

58:36.820 --> 58:37.780
Genau, vertikal.

58:37.880 --> 58:39.940
Was sehe ich von oben als Nutzer an dem Dienst?

58:40.600 --> 58:42.580
Das von außen beobachtbare Verhalten des Dienstes.

58:42.920 --> 58:46.200
Haben wir bei der Protokollspezifikation, zu der wir kommen, jetzt

58:46.200 --> 58:48.520
eher, was machen die Protokolle miteinander?

58:48.700 --> 58:51.480
Und die Definition hierfür ist auch nicht weiter komplizierter.

58:52.940 --> 58:56.420
Wenn wir Sie bitten, eine Protokollspezifikation zu entwerfen,

59:03.060 --> 59:05.540
dann entwerfen Sie uns bitte Regeln und Formate.

59:11.200 --> 59:14.340
Frau Zitterbart hat heute Morgen in der Vorlesung den Unterschied

59:14.340 --> 59:14.800
gebracht.

59:15.480 --> 59:19.480
Bei der vertikalen Kommunikation, wenn eine Anwendung mit einem Dienst

59:19.480 --> 59:22.880
redet, brauche ich nicht zwangsweise global festlegen, wie die Formate

59:22.880 --> 59:23.660
auszusehen haben.

59:24.140 --> 59:26.540
Wenn ich mit einem Protokollnehmer am anderen Ende der Welt sprechen

59:26.540 --> 59:29.220
will, dann müssen die Protokolle auf jeden Fall diese Sachen regeln.

59:29.900 --> 59:33.480
Also legt ein Protokoll fest, in dem es Regeln, also Abläufe und

59:33.480 --> 59:41.260
Formate, festschreibt, legt es das Kommunikationsverhalten zweier

59:50.020 --> 59:51.560
dieser Protokollinstanzen fest.

59:57.340 --> 01:00:01.340
So, und jetzt kommen wir wieder hierher, um einen Dienst zu erbringen.

01:00:05.250 --> 01:00:05.970
Ganz einfach.

01:00:08.690 --> 01:00:09.970
So, und das müssen wir jetzt noch machen.

01:00:10.050 --> 01:00:12.430
Das ist jetzt auch noch das letzte richtig Komplizierte, was wir heute

01:00:12.430 --> 01:00:12.870
vorhaben.

01:00:13.410 --> 01:00:15.790
Das war die Aufgabenstellung, ich möchte sie nicht im Detail

01:00:15.790 --> 01:00:15.950
durchlesen.

01:00:16.770 --> 01:00:20.330
Wir möchten einen bestätigten Transportverbindungsaufbaudienst, das

01:00:20.330 --> 01:00:21.370
ging nur um den Aufbau.

01:00:21.890 --> 01:00:28.630
Wir möchten wieder ein Zustandsdiagramm, aber in diesem Fall wollen

01:00:28.630 --> 01:00:29.250
wir mal beide.

01:00:29.350 --> 01:00:32.810
Wir wollen das vom Außen zu beobachtbare Verhalten vom Dienst, und wir

01:00:32.810 --> 01:00:33.870
wollen das Verhalten von den Protokollinstanzen.

01:00:34.710 --> 01:00:36.850
Dann wird Ihnen auch der Unterschied klarer, und der ist, wie gesagt,

01:00:36.990 --> 01:00:37.190
wichtig.

01:00:37.490 --> 01:00:39.690
Wenn Sie das heute mit nach draußen tragen, wäre ich schon sehr

01:00:39.690 --> 01:00:39.970
glücklich.

01:00:41.490 --> 01:00:44.890
Der Netzwerkdienst, der darunter liegt, den die Transportinstanz

01:00:44.890 --> 01:00:48.010
verwendet, ist unbestätigt in dieser Aufgabe.

01:00:48.690 --> 01:00:51.010
Das heißt, wir dürfen uns bei unserer Spezifikation einem

01:00:51.010 --> 01:00:52.970
unbestätigten Netzwerkdienst bedienen.

01:00:54.850 --> 01:00:57.770
Und wir haben hier noch Abbildungsregeln, zu denen wir gleich noch

01:00:57.770 --> 01:00:58.670
wieder kommen werden.

01:00:59.370 --> 01:01:02.490
Fangen wir also an, das Ganze nochmal als Dienstspezifikation zu

01:01:02.490 --> 01:01:02.950
entwerfen.

01:01:03.030 --> 01:01:06.190
Wir hatten es vorhin, deswegen machen wir es ein bisschen schneller

01:01:06.190 --> 01:01:06.570
durch.

01:01:07.030 --> 01:01:09.270
Unterbrechen Sie mich, wenn irgendwas unklar ist, wie üblich.

01:01:09.270 --> 01:01:12.830
Wir haben einen Start, wir haben natürlich wieder eine Verbindung im

01:01:12.830 --> 01:01:14.610
Aufbau, wenn wir sie bestätigen wollen.

01:01:16.910 --> 01:01:19.430
Und wir wollen früher oder später natürlich zum Zustand, dass die

01:01:19.430 --> 01:01:20.630
Verbindung aufgebaut ist.

01:01:24.450 --> 01:01:27.870
So, und auch hier sind die Primitive, die da stattfinden, nicht anders

01:01:27.870 --> 01:01:29.150
als in der Aufgabe zuvor.

01:01:29.850 --> 01:01:32.490
Ich habe natürlich einen Transportdienst, der die Connection-Request

01:01:32.490 --> 01:01:35.370
hat, den ich abgebe an meinen Transportdienst.

01:01:36.210 --> 01:01:38.870
Und am anderen Ende wird natürlich eine Connection-Indication

01:01:38.870 --> 01:01:39.510
rauskommen.

01:01:41.910 --> 01:01:44.410
Angefragte Verbindung bisher unbestätigt.

01:01:44.550 --> 01:01:46.730
Wir wechseln also den Zustand Verbindung im Aufbau.

01:01:48.030 --> 01:01:51.270
Auf der anderen Seite wird hoffentlich eine Response kommen.

01:01:53.670 --> 01:01:57.330
Und bei mir, beim Verbindungsinitiator, wird eine Confirmation

01:01:57.330 --> 01:02:00.350
angezeigt, sodass die Verbindung danach aufgebaut ist.

01:02:02.670 --> 01:02:03.110
Klar?

01:02:04.410 --> 01:02:06.790
So, und von beiden Seiten kann ich natürlich wieder die Verbindung

01:02:06.790 --> 01:02:09.050
abbauen, was in diesem Fall allerdings gar nicht gefragt war.

01:02:09.930 --> 01:02:11.150
Wir wollten es erstmal nur aufbauen.

01:02:11.610 --> 01:02:13.890
Wenn wir es aber tun, gibt es von beiden diesen Zuständen natürlich

01:02:13.890 --> 01:02:18.690
die Möglichkeit mit einer T-Disconnect-Request, die bei der anderen

01:02:18.690 --> 01:02:21.230
Seite mit einer Disconnect-Indication angezeigt wird.

01:02:25.680 --> 01:02:26.620
Bestimmt soweit klar.

01:02:26.800 --> 01:02:28.480
Nichts anderes, als wir eben entwickelt haben.

01:02:29.540 --> 01:02:33.840
So, und daraus entwickeln wir jetzt aber die Protokollspezifikation.

01:02:34.320 --> 01:02:35.940
Ich habe sie hier angemalt, wir gehen sie jetzt durch.

01:02:36.860 --> 01:02:38.880
Ich wollte Ihnen nur ersparen, dass ich so viel in ein Bild

01:02:38.880 --> 01:02:40.820
reinschreiben muss und Sie es irgendwie noch lesen sollen.

01:02:40.940 --> 01:02:43.200
Wobei ich die Musterlösung für heute auch noch in sinnvoller

01:02:43.200 --> 01:02:44.980
Papierform zur Verfügung stellen werde.

01:02:45.560 --> 01:02:48.420
Geben Sie mir dafür aber bis Montag oder so Zeit.

01:02:49.840 --> 01:02:52.840
Wir haben also wieder die Protokollspezifikation, wie wir vorher

01:02:52.840 --> 01:02:53.560
gelernt haben.

01:02:53.700 --> 01:02:56.620
Legt durch Regeln und Formate das Verhalten zweier Protokollinstanzen

01:02:56.620 --> 01:02:56.980
fest.

01:02:56.980 --> 01:02:59.820
Das heißt, wir befinden uns jetzt, wenn wir unser Schichtenmodell

01:02:59.820 --> 01:03:06.110
wieder anschauen, mit Dienstzugangspunkten, ein bisschen größer malen

01:03:06.110 --> 01:03:17.180
sollen, befinden wir uns jetzt hier drin in so einer Protokollinstanz.

01:03:17.740 --> 01:03:20.580
Und schauen uns an, was an den Schnittstellen jetzt passiert.

01:03:21.040 --> 01:03:23.860
Das heißt, jetzt passiert in dem Zustandsdiagramm etwas ganz anderes

01:03:23.860 --> 01:03:24.400
als vorher.

01:03:25.120 --> 01:03:28.960
Wenn ich jetzt Anforderungen an die Instanz kriege mit Unterschieden,

01:03:29.080 --> 01:03:31.560
kommen die von unten, von der Netzwerkschicht, sagt die meiner

01:03:31.560 --> 01:03:35.980
Transportinstanz etwas, oder kommen sie von oben, von der Anwendung.

01:03:36.060 --> 01:03:37.360
Und was passiert dann im Gegenzug?

01:03:37.760 --> 01:03:39.520
Das heißt, wie wird das jetzt tatsächlich umgesetzt?

01:03:41.520 --> 01:03:45.540
Wir schauen uns also wieder den Startzustand an, in dem wir keine

01:03:45.540 --> 01:03:47.660
Verbindung haben und wir möchten jetzt eine aufbauen.

01:03:47.980 --> 01:03:51.080
Wenn wir eine aufbauen möchten, wird, wir können das Ganze auch wieder

01:03:51.080 --> 01:03:52.440
als Zeitdiagramm darstellen.

01:03:52.620 --> 01:03:53.960
Allerdings ist dafür wenig Platz.

01:03:55.100 --> 01:03:57.020
Wir haben also wieder einen Dienstnehmer A,

01:04:00.440 --> 01:04:05.860
in diesem Fall eine Transportinstanz 1 und die bedient sich der

01:04:05.860 --> 01:04:06.360
Dienste.

01:04:06.720 --> 01:04:09.640
Wir müssen nicht immer die horizontale Kommunikation nur sehen, von

01:04:09.640 --> 01:04:12.940
einem Ort zu einem anderen, sondern die kann eben auch im Zeitdiagramm

01:04:12.940 --> 01:04:15.240
dargestellt werden, wie die Schichten miteinander reden.

01:04:15.400 --> 01:04:17.020
Die bedient sich einer Netzwerkschicht.

01:04:17.720 --> 01:04:20.320
Das kommt dann auf der anderen Seite an eine Netzwerkschicht an, die

01:04:20.320 --> 01:04:22.520
das wiederum an eine Transportschicht abliefern wird.

01:04:24.700 --> 01:04:29.360
So, wir beginnen also mit einer T-Connection-Request an die

01:04:29.360 --> 01:04:30.580
Transportschicht jetzt.

01:04:31.620 --> 01:04:33.160
Und die überträgt die weiter.

01:04:33.800 --> 01:04:35.960
Lassen Sie sich bitte durch das Zeitdiagramm nicht verwirren.

01:04:36.040 --> 01:04:38.640
In diesem Fall ist die Zeit das, was hier horizontal ist.

01:04:38.680 --> 01:04:40.960
Hier findet noch keine horizontale Kommunikation statt.

01:04:42.200 --> 01:04:44.860
Das geht nur nach unten an die Netzwerkschicht, benötigt aber Zeit.

01:04:46.140 --> 01:04:48.600
Nur weil im Zeitdiagramm ein Pfeil horizontal ist, bitte nicht

01:04:48.600 --> 01:04:50.480
verwechseln mit horizontaler Kommunikation.

01:04:51.160 --> 01:04:54.700
Und die Netzwerkschicht nimmt es entgegen, den Verbindungsaufbauwunsch

01:04:54.700 --> 01:05:00.500
meiner Transportinstanz und tut jetzt was und übermittelt was an die

01:05:00.500 --> 01:05:01.380
andere Netzwerkschicht.

01:05:01.640 --> 01:05:03.740
Beachten Sie, wir haben in der Aufgabenstellung gesagt, der

01:05:03.740 --> 01:05:07.440
Transportdienst hat noch keine aufgebaute Netzwerkverbindung.

01:05:13.160 --> 01:05:14.720
Das heißt, die müssen wir erst aufbauen.

01:05:14.820 --> 01:05:17.260
Das heißt, die Netzwerkinstanz wird natürlich dann ein Connection

01:05:17.260 --> 01:05:20.920
-Request erzeugen und erstmal an die andere Netzwerkinstanz schicken.

01:05:21.940 --> 01:05:25.120
Und hier natürlich, wie wir es schon gelernt haben, wird das Ganze als

01:05:27.620 --> 01:05:29.700
Network Connect Indication ankommen.

01:05:30.960 --> 01:05:33.280
Das heißt, wir müssen natürlich zuerst mal die darunter liegende

01:05:33.280 --> 01:05:36.140
Schicht aufbauen, nämlich die Schicht 3 Verbindung und das heißt, wir

01:05:36.140 --> 01:05:37.080
befinden uns hier.

01:05:38.600 --> 01:05:42.440
Und das Interessante an Protokollspezifikation ist, wir können jetzt

01:05:42.440 --> 01:05:48.740
in diesem Zustandsübergangsdiagramm, da ist natürlich beides drin, das

01:05:48.740 --> 01:05:51.800
heißt, wir haben in diesem Übergangsdiagramm natürlich den Fall, dass

01:05:51.800 --> 01:05:54.820
eine Verbindung ankommt, sondern dass eine Verbindung aufgebaut werden

01:05:54.820 --> 01:05:55.120
soll.

01:05:55.120 --> 01:06:00.400
Ich mache das mal groß hier oben im Sender und Empfänger.

01:06:04.280 --> 01:06:10.160
Das heißt, wenn die Netzwerkschicht des Senders ein Connection-Request

01:06:10.160 --> 01:06:13.640
schickt, das haben wir hier, dann trifft sie natürlich bei der

01:06:13.640 --> 01:06:18.420
Netzwerkschicht beim Empfänger ein, als Network Connection Indication.

01:06:19.400 --> 01:06:23.860
Das heißt, wir haben hier, wenn sie den gleichen Automat haben sie

01:06:23.860 --> 01:06:25.740
auch auf der anderen Seite jetzt eben laufen.

01:06:25.740 --> 01:06:29.080
Das heißt, sie haben hier gewissermaßen diese Verbindung, in der

01:06:29.080 --> 01:06:32.760
Sender und Empfänger sich miteinander unterhalten.

01:06:34.380 --> 01:06:36.460
Sie können also jetzt in dem Diagramm praktisch gleichzeitig

01:06:36.460 --> 01:06:38.760
durchgehen, was passiert auf der Initiator- und was passiert auf der

01:06:38.760 --> 01:06:39.440
Empfängerseite.

01:06:40.020 --> 01:06:42.220
Wir haben also jetzt eine Schicht 3 Verbindung im Aufbau.

01:06:44.440 --> 01:06:47.380
Kommt als Connection Indication an, das heißt, die Schicht auf der

01:06:47.380 --> 01:06:52.460
anderen Seite wird ihre Transportschicht zunächst mal nicht, wir

01:06:52.460 --> 01:06:55.640
sollten nicht vorgreifen, zunächst mal nicht benachrichtigen.

01:06:55.940 --> 01:06:59.040
Die befindet sich nur in Schicht 3 Verbindung akzeptiert.

01:06:59.220 --> 01:06:59.940
Das ist hier unten.

01:07:00.800 --> 01:07:02.980
Wird aber in diesem Fall diese Verbindung akzeptieren.

01:07:04.160 --> 01:07:05.980
Mit den Primitiven, die wir schon kennen.

01:07:06.140 --> 01:07:09.340
Das heißt, sie wird natürlich mit einer Response antworten.

01:07:10.440 --> 01:07:13.300
Diese Response, gehen wir wieder zurück, jetzt wieder horizontale

01:07:13.300 --> 01:07:14.600
Kommunikation zum Sender.

01:07:14.600 --> 01:07:19.140
Die Response kommt als Confirmation an der Netzwerkschicht vom Sender

01:07:19.140 --> 01:07:19.700
wieder an.

01:07:20.280 --> 01:07:23.280
Die Netzwerkschicht reicht das wieder nach oben.

01:07:27.970 --> 01:07:29.090
Das heißt, sie tut es noch nicht.

01:07:29.170 --> 01:07:29.970
Ich bitte um Verzeihung.

01:07:31.110 --> 01:07:33.550
Die Netzwerkschicht hat jetzt eine Verbindung aufgebaut.

01:07:34.010 --> 01:07:36.330
Die Aufgabe an die Netzwerkschicht war der Aufbau einer

01:07:36.330 --> 01:07:37.270
Transportverbindung.

01:07:37.430 --> 01:07:39.690
Das heißt, die Netzwerkschicht, die eine Verbindung jetzt hat,

01:07:40.330 --> 01:07:44.370
transportiert jetzt die Anforderungen der Transportschicht an eine

01:07:44.370 --> 01:07:44.790
Verbindung.

01:07:44.790 --> 01:07:48.190
Das heißt, eine Schicht-4-Verbindung transportiert sie über ihren

01:07:48.190 --> 01:07:51.250
eigenen Datendienst horizontal zum Empfänger.

01:07:52.030 --> 01:07:54.610
Das ist noch das Einzige, was in dem Diagramm noch ein bisschen

01:07:54.610 --> 01:07:55.370
kompliziert ist.

01:07:55.770 --> 01:07:58.470
Das heißt, die Netzwerkschicht reagiert auf die Confirmation hier,

01:08:00.390 --> 01:08:04.630
indem sie einfach Daten schickt, und zwar Nutzdaten.

01:08:04.790 --> 01:08:07.630
Das habe ich Ihnen vorhin erzählt, die Protocol Data Unit von der

01:08:07.630 --> 01:08:09.790
Transportschicht wird von der Netzwerkschicht einfach nur als

01:08:09.790 --> 01:08:10.570
Nutzdaten verschickt.

01:08:10.690 --> 01:08:11.810
Die weiß nicht, was da drin steht.

01:08:11.810 --> 01:08:14.970
Die schickt sie jetzt nach drüben, und zwar Nutzdaten.

01:08:15.410 --> 01:08:17.370
Hier kommen wir jetzt zu der Tabelle, die wir vorhin hatten.

01:08:18.210 --> 01:08:23.070
Die Nutzdaten in diesem Fall sind eben von der Transportschicht der

01:08:23.070 --> 01:08:27.250
Connection Request, RQ.

01:08:28.190 --> 01:08:31.750
Das heißt, auf der Netzwerkschicht wird jetzt einfach die Protocol

01:08:31.750 --> 01:08:34.870
Data Unit der Transportschicht, RQ, verschickt.

01:08:35.690 --> 01:08:37.230
Das haben wir jetzt praktisch hier.

01:08:38.250 --> 01:08:41.070
Und dann befinden wir uns natürlich im Zustand Schicht 4 Verbindung im

01:08:41.070 --> 01:08:41.470
Aufbau.

01:08:43.550 --> 01:08:47.970
Die Netzwerkschicht der anderen, der Empfängerseite, empfängt es als

01:08:47.970 --> 01:08:52.290
Data Indication, die Protocol Data Unit Response.

01:08:54.490 --> 01:08:55.690
Schauen wir es uns hier an.

01:08:56.110 --> 01:08:56.690
Da sind wir hier.

01:08:59.530 --> 01:09:03.090
Und reicht jetzt zum allerersten Mal, wird jetzt die Transportschicht

01:09:03.090 --> 01:09:04.570
auf Empfängerseite belästigt.

01:09:05.270 --> 01:09:07.330
Bisher hat die noch überhaupt nichts davon mitbekommen.

01:09:07.810 --> 01:09:10.670
Und die erhält jetzt die Connection Confirmation, das heißt, hier

01:09:10.670 --> 01:09:14.410
kommt jetzt zum allerersten Mal...

01:09:14.910 --> 01:09:17.250
Entschuldigung, die Connection Indication kommt hier an.

01:09:17.710 --> 01:09:19.930
Wir müssen immer aufpassen, auf welcher Seite wir uns hier im Diagramm

01:09:19.930 --> 01:09:20.590
befinden.

01:09:21.530 --> 01:09:23.210
Ich bin auch hier zu schnell nach vorne gesprungen.

01:09:23.790 --> 01:09:26.390
Wenn wir dieses Request übermitteln, kommt es natürlich hier unten

01:09:26.390 --> 01:09:28.270
erst mal als Indication vom Request an.

01:09:28.610 --> 01:09:29.950
Wir müssen immer auf die Seiten achten.

01:09:30.710 --> 01:09:33.390
In dem Diagramm spielt so schön alles zusammen, dass man aufpassen

01:09:33.390 --> 01:09:35.030
muss, welche Wege wir uns anschauen.

01:09:35.390 --> 01:09:37.350
Welche Wege im Diagramm ablaufen, ist hoffentlich klar.

01:09:37.410 --> 01:09:40.190
Es läuft immer nur einer von beiden ab, auf einer Seite.

01:09:40.890 --> 01:09:42.910
Wir schauen uns natürlich nur jetzt beide parallel an.

01:09:44.730 --> 01:09:47.930
Die Netzwerkschicht auf Empfängerseite empfängt also das Request und

01:09:47.930 --> 01:09:50.490
antwortet, was ich Ihnen gerade erklärt habe, mit einer Connection

01:09:50.490 --> 01:09:51.470
Indication...

01:09:51.470 --> 01:09:55.330
und belästigt zum ersten Mal die Transportschicht auf Empfängerseite.

01:09:56.130 --> 01:09:58.550
Die antwortet jetzt mit einer Connection Response.

01:09:59.610 --> 01:10:01.830
Und das wird wiederum übertragen auf der Netzwerkschicht als

01:10:01.830 --> 01:10:03.610
Connection, als Response.

01:10:04.550 --> 01:10:08.230
Und dann gelangen wir wieder auf Empfängerseite zu einer aufgebauten

01:10:08.230 --> 01:10:09.370
Schicht 4 Verbindung...

01:10:09.370 --> 01:10:14.830
und was dort als Confirmation ganz zum Schluss signalisiert wird.

01:10:18.560 --> 01:10:19.720
Ist das klar geworden?

01:10:20.920 --> 01:10:24.280
Zunächst mal der große Unterschied von diesem Zustandsdiagramm.

01:10:24.280 --> 01:10:26.280
Wir befinden uns eben jetzt in der Protokollinstanz.

01:10:26.960 --> 01:10:28.260
Das heißt, die muss mit zwei Schichten reden.

01:10:28.360 --> 01:10:30.980
Die nimmt von oben Sachen von der höher liegenden Schicht entgegen und

01:10:30.980 --> 01:10:32.560
verwendet Dienste der unterliegenden Schicht.

01:10:32.920 --> 01:10:35.960
Die unterliegende Diensteschicht bietet in dem Fall nur

01:10:35.960 --> 01:10:38.460
Verbindungsaufbau und einen unbestätigten Datendienst an.

01:10:38.800 --> 01:10:41.340
Das heißt, wenn die Transportschicht ihre Verbindung aufbauen will,

01:10:41.420 --> 01:10:44.120
muss sie entsprechende Nutzdaten, ich hätte gerne eine Verbindung mit

01:10:44.120 --> 01:10:46.700
der anderen Transportschicht, an die Netzwerkschicht geben.

01:10:47.400 --> 01:10:49.720
Die baut eine entsprechende Verbindung auf und transportiert diese

01:10:49.720 --> 01:10:50.060
dann.

01:10:51.960 --> 01:10:54.500
Und weiß aber von diesen Daten ansonsten nichts weiter.

01:10:57.780 --> 01:11:01.700
Das ganze Diagramm haben wir noch erweitert, um das gleiche bei

01:11:01.700 --> 01:11:02.220
Disconnect.

01:11:02.780 --> 01:11:04.580
Der Fall sollte sich selber erklären.

01:11:04.700 --> 01:11:06.620
Würde ich Sie auch bieten, ihn sich selber mal anzuschauen.

01:11:07.340 --> 01:11:09.340
Auch hier können wir eben die Verbindung wieder abbauen, indem

01:11:09.340 --> 01:11:12.100
entsprechende Protokoll-Data-Units, in diesem Fall das Disconnect,

01:11:12.220 --> 01:11:13.080
transportiert werden.

01:11:13.560 --> 01:11:16.300
Und von der Netzwerkschicht werden die einfach wieder eingepackt als

01:11:16.300 --> 01:11:17.560
ganz normale Nutzdaten.

01:11:18.660 --> 01:11:21.060
Resultieren dann aber in eine Disconnect-Indication.

01:11:22.140 --> 01:11:24.520
Worauf ich Sie hier noch hinweisen wollte, war eine Sache.

01:11:24.780 --> 01:11:26.560
Die Diagramme sind natürlich nie vollständig.

01:11:26.660 --> 01:11:30.520
Es kann in jedem Zustand jedes Primitiv von unten oder oben ankommen.

01:11:30.920 --> 01:11:33.620
Normal müssten wir noch viele weitere Zustände, die normalerweise

01:11:33.620 --> 01:11:37.000
einfach in den gleichen Zustand wieder übergehen, hier einzeichnen.

01:11:37.520 --> 01:11:39.000
Das machen wir normalerweise nicht.

01:11:39.500 --> 01:11:42.860
Aber ein Beispiel wäre zum Beispiel, wenn wir im Startzustand sind,

01:11:42.920 --> 01:11:47.920
wir haben noch keine Verbindung aufgebaut und wir bekommen eine T

01:11:47.920 --> 01:11:50.180
-Connection -Response oder solche unsinnigen Dinge.

01:11:51.860 --> 01:11:56.740
Oder wir bekommen eine Network-Disconnect-Request oder Indication.

01:11:57.200 --> 01:11:59.140
Relativ egal, das ist alles unsinnig.

01:11:59.180 --> 01:12:01.160
Die haben wir noch nicht gehabt, da ist irgendwas schiefgegangen.

01:12:01.580 --> 01:12:04.180
Wenn wir den Automat wirklich vollständig machen wollten, müssten wir

01:12:04.180 --> 01:12:08.160
alle möglichen Zustände in allen möglichen Zuständen aufbauen.

01:12:09.240 --> 01:12:10.840
Das war auch dann die zweite Frage.

01:12:12.100 --> 01:12:15.160
Wenn der Netzwerkdienst unzuverlässig sein kann, was kann uns in

01:12:15.160 --> 01:12:16.140
diesem Fall dann passieren?

01:12:16.320 --> 01:12:18.580
Sehr schöner Bezug zur Vorlesung, ich verrate es schon mal.

01:12:18.680 --> 01:12:20.920
Es geht natürlich hier um den Verbindungsaufbau, es geht natürlich

01:12:20.920 --> 01:12:22.340
auch um den Handshake.

01:12:24.180 --> 01:12:26.800
Und bei solchen Fragen, wir kommen in der zweiten Übung noch dazu,

01:12:26.900 --> 01:12:28.420
müssen Sie immer ein bisschen kreativ sein.

01:12:28.500 --> 01:12:30.140
Das heißt, seien Sie fies zu dem Protokoll.

01:12:30.820 --> 01:12:32.600
Tun Sie dem Protokoll das möglichst Schlimmste an.

01:12:32.940 --> 01:12:33.900
Was kann alles verloren gehen?

01:12:34.000 --> 01:12:34.980
Was kann alles kaputt gehen?

01:12:35.060 --> 01:12:36.760
Was können für Dinge geschehen?

01:12:41.660 --> 01:12:46.000
Worauf ich in diesem Fall hier hinaus wollte ist, wenn die

01:12:46.000 --> 01:12:49.460
Empfängerschicht sagt, ja, ich akzeptiere die Verbindung und gibt der

01:12:49.460 --> 01:12:53.760
Netzwerkschicht den Auftrag, hier gibt sie der Netzwerkschicht den

01:12:53.760 --> 01:12:57.040
Auftrag, die Response zu übertragen.

01:12:57.700 --> 01:13:00.740
Dann kann die Response natürlich verloren gehen, weil die

01:13:00.740 --> 01:13:02.740
Netzwerkschicht einen unbestätigten Dienst bietet.

01:13:04.420 --> 01:13:08.300
Dann denkt die Empfängerschicht, die Verbindung wäre aufgebaut, aber

01:13:08.300 --> 01:13:10.940
die Senderschicht hat es nicht erhalten, denkt also nicht daran.

01:13:11.560 --> 01:13:12.840
Wie lösen wir das Problem wieder?

01:13:12.920 --> 01:13:14.040
Wir haben es vorhin schon mal genannt.

01:13:15.860 --> 01:13:17.360
Durch Timer, ganz genau.

01:13:18.180 --> 01:13:20.900
Das heißt, im Grunde müssen wir hier noch einiges mehr spezifizieren,

01:13:20.980 --> 01:13:22.440
wenn wir das Protokoll festlegen wollen.

01:13:22.560 --> 01:13:25.680
Wir haben hier aber nur den Zustandsübergangsdiagramm der Instanz.

01:13:30.040 --> 01:13:31.200
Haben Sie hierzu Fragen?

01:13:32.120 --> 01:13:33.700
Wie wird das natürlich wieder behandelt?

01:13:33.780 --> 01:13:36.220
Klar, wir haben es in der Vorlesung gehört, drei Wege Handshake.

01:13:37.580 --> 01:13:39.800
Auch der kann natürlich Fehl schlagen, ganz klar.

01:13:39.940 --> 01:13:42.200
Wenn Sie sehr kreativ sind, denken Sie sich auch da noch Fälle aus.

01:13:42.640 --> 01:13:44.760
Das führt hier aber, wie gesagt, auf jeden Fall auch zu weit.

01:13:48.680 --> 01:13:50.580
Mit den Sachen müssen Sie, wie gesagt, firm sein.

01:13:50.760 --> 01:13:51.720
Gucken Sie es sich mal durch.

01:13:54.280 --> 01:13:56.740
Und schauen Sie es sich an, wenn Sie Schwierigkeiten haben oder so,

01:13:56.920 --> 01:13:57.960
sagen Sie nochmal Bescheid.

01:13:58.240 --> 01:13:59.540
Weil die Dinge sind sehr interessant.

01:13:59.740 --> 01:14:02.240
Wenn Sie das richtige Zustandsübergangsdiagramm wählen und sich

01:14:02.240 --> 01:14:04.680
überlegen, sind Sie gerade eine Protokollinstanz oder schauen Sie von

01:14:04.680 --> 01:14:06.980
oben auf den Dienst drauf, kann Ihnen im Grunde genommen wenig

01:14:06.980 --> 01:14:09.540
passieren, wenn Sie das einfach nur logisch-geistig durchspielen.

01:14:13.040 --> 01:14:14.240
Das hatten wir genau hier.

01:14:19.340 --> 01:14:21.440
Dann käme ich noch zur Aufgabe 5 und 6.

01:14:21.640 --> 01:14:23.120
Die haben wir noch zum Aussteigen heute.

01:14:23.540 --> 01:14:24.880
Die kriegen wir auch relativ schnell durch.

01:14:25.020 --> 01:14:27.120
Das sind auch sehr beliebte Klausuraufgaben, sehr beliebte

01:14:27.120 --> 01:14:28.200
Klausurrechenaufgaben.

01:14:28.700 --> 01:14:30.300
Wir haben es in der Vorlesung kurz durchgemacht.

01:14:31.940 --> 01:14:35.400
Gehen wir also nochmal ganz kurz ISDN durch, die Abtastung von ISDN.

01:14:35.620 --> 01:14:39.200
Pulse Code Modulation Technik, Digitalisierung des analogen Signals.

01:14:39.760 --> 01:14:42.580
Wir haben eine Frequenzlage von 300 bis 3400 Hertz.

01:14:43.660 --> 01:14:46.700
Wir sagen mal, aus technischen Gründen haben wir keine Bandbreite,

01:14:46.840 --> 01:14:52.580
sondern haben eine obere Grenzfrequenz von 4 Kilohertz.

01:14:53.000 --> 01:14:55.960
Wie hoch und nach welchem Verfahren wird eigentlich die Abtastfrequenz

01:14:55.960 --> 01:14:59.260
jetzt geregelt, damit wir das Signal zeitlich auf jeden Fall genau

01:14:59.260 --> 01:15:00.120
rekonstruieren können.

01:15:00.620 --> 01:15:02.060
Was haben wir für ein Theorem kennengelernt?

01:15:04.040 --> 01:15:07.120
Shannon und Rabe, die sagen was?

01:15:07.120 --> 01:15:11.480
Die Abtastfrequenz muss größer oder gleich der doppelten Grenzfrequenz

01:15:11.480 --> 01:15:12.720
des Ausgangssignals sein.

01:15:13.680 --> 01:15:16.080
Welche Grenzfrequenz haben wir jetzt hier in Wirklichkeit?

01:15:21.840 --> 01:15:24.540
Was wäre die echte Grenzfrequenz in diesem Beispiel, wenn wir von 300

01:15:24.540 --> 01:15:26.540
bis 3400 Hertz digitalisieren wollen?

01:15:29.540 --> 01:15:30.020
Wie viel?

01:15:32.020 --> 01:15:33.200
Das ist schon das Doppelte.

01:15:33.360 --> 01:15:36.160
Also die obere Grenzfrequenz wäre eigentlich 3400, genau.

01:15:37.200 --> 01:15:40.320
Und digitalisieren müssen wir dann nach Shannon und Rabe natürlich mit

01:15:40.320 --> 01:15:42.520
6, 8.

01:15:42.880 --> 01:15:46.160
Womit man es natürlich machen ist, wie gesagt, wir wählen einfach mal

01:15:46.160 --> 01:15:49.120
4 Kilohertz als obere Grenzfrequenz und digitalisieren dann

01:15:49.120 --> 01:15:51.460
entsprechend natürlich mit 8.

01:15:59.210 --> 01:16:04.670
Nur lassen Sie sich nicht ins Boxhorn jagen, nur weil hier irgendeine

01:16:04.670 --> 01:16:06.410
300 steht, die ist für uns uninteressant.

01:16:06.430 --> 01:16:09.710
Für uns ist uninteressant, wo das Band genau liegt, ob ich von 600 bis

01:16:09.710 --> 01:16:11.730
3700 gehe oder was anderes.

01:16:12.190 --> 01:16:14.970
Wir müssen immer die obere Grenzfrequenz betrachten, damit wir wissen,

01:16:15.050 --> 01:16:16.310
wie schnell wir digitalisieren müssen.

01:16:18.630 --> 01:16:22.250
So, wir machen 256 Quantisierungsintervalle daraus, damit wir die

01:16:22.250 --> 01:16:23.390
Sprache noch gut verstehen.

01:16:23.930 --> 01:16:26.430
Welche Übertragungsrate brauchen wir dann damit für so einen Kanal?

01:16:27.430 --> 01:16:30.890
Wie viel Bit brauchen wir, um 256 unterschiedliche Typen unterscheiden

01:16:30.890 --> 01:16:31.330
zu müssen?

01:16:31.850 --> 01:16:35.810
Wer die Antwort nicht weiß, der möchte ins Mittagessen.

01:16:37.710 --> 01:16:41.230
Wir brauchen 8 Bit, weil natürlich 2 hoch 8 256 ist.

01:16:43.490 --> 01:16:47.310
Wir haben gesagt, wir machen genau 8000 Übertragungsrate pro Sekunde,

01:16:47.410 --> 01:16:48.370
nämlich 8000 Hertz.

01:16:48.470 --> 01:16:51.090
Und was brauchen wir dann natürlich als Übertragungsgeschwindigkeit

01:16:51.090 --> 01:16:52.390
für so einen PCM-Kanal?

01:17:08.650 --> 01:17:12.530
Genau, wir kommen natürlich zu den 64 Kilobit, wo wir auch hinwollten,

01:17:12.690 --> 01:17:13.210
pro Sekunde.

01:17:14.190 --> 01:17:17.250
Wann immer es um Einheiten geht, Kilo und Kbit, wir streiten uns nicht

01:17:17.250 --> 01:17:19.070
darum, wir geben es den Aufgaben normalerweise an.

01:17:19.070 --> 01:17:21.090
Ob wir mit 1000 rechnen oder mit 2 hoch 10.

01:17:22.890 --> 01:17:26.290
So, können wir danach das Signal einwandfrei wieder rekonstruieren,

01:17:26.670 --> 01:17:27.470
rein prinzipiell?

01:17:30.430 --> 01:17:32.070
Wenn wir das jetzt getan haben...

01:17:33.390 --> 01:17:35.350
Ja, nein, 50-50 Chance.

01:17:43.970 --> 01:17:46.790
Also es sieht ja so aus, wir haben ein digitales Signal.

01:17:48.750 --> 01:17:50.190
Ein analoges Signal, sehr gut.

01:17:51.490 --> 01:17:52.450
Ja, es wird spät.

01:17:52.450 --> 01:17:55.530
Und wir digitalisieren das jetzt, das heißt wir teilen es auf einmal

01:17:55.530 --> 01:17:56.730
in fixe Schritte ein.

01:17:59.350 --> 01:18:02.350
Zu bestimmten Zeitpunkten, die ich jetzt hier schlecht gewählt habe,

01:18:02.470 --> 01:18:04.470
deswegen machen wir es hier nochmal schöner.

01:18:09.250 --> 01:18:14.450
Wenn ich jetzt also zu diesem Zeitpunkt hier das Signal abtaste...

01:18:15.630 --> 01:18:18.790
und ich habe jeweils nur die von hier vorne angegebenen Möglichkeiten,

01:18:19.010 --> 01:18:20.450
dem einen Bitwert zuzuordnen.

01:18:23.170 --> 01:18:24.010
Was mache ich dann?

01:18:24.090 --> 01:18:25.130
Ich mache natürlich einen Fehler.

01:18:25.290 --> 01:18:25.750
Wie heißt der?

01:18:27.990 --> 01:18:28.390
Quantisierungsfehler.

01:18:35.320 --> 01:18:38.420
Und der ist natürlich höchstens wie groß, was ist der schlimmste Fall

01:18:38.420 --> 01:18:39.520
im Quantisierungsfehler?

01:18:44.430 --> 01:18:47.070
Wenn es genau in der Mitte liegt natürlich, dann mache ich nämlich

01:18:47.070 --> 01:18:50.210
genau das halbe Intervall, das ich für die Quantisierung verwende als

01:18:50.210 --> 01:18:50.550
Fehler.

01:18:51.110 --> 01:18:52.410
Auch keine Schwierigkeit.

01:18:53.530 --> 01:18:53.850
Fragen?

01:18:58.880 --> 01:19:01.700
Also die Antwort lautet, prinzipiell ist das Signal danach nicht

01:19:01.700 --> 01:19:04.000
einmal frei rekonstruierbar, falls noch irgendwelche Fragen sind.

01:19:05.820 --> 01:19:08.480
Wie viele Fernsprechkanäle können wir mit einem physikalischen Medium,

01:19:08.520 --> 01:19:14.240
wenn wir 2048 Megabit haben, 2,048 Megabit, Entschuldigung, das andere

01:19:14.240 --> 01:19:14.700
wäre viel.

01:19:15.340 --> 01:19:17.180
Wie viel können wir dann damit übertragen?

01:19:19.160 --> 01:19:20.120
Einfache Multiplikationsaufgabe.

01:19:21.960 --> 01:19:29.460
Wenn wir jeweils 64 Kilobit haben, dann können wir damit natürlich 32

01:19:29.460 --> 01:19:31.120
Kanäle übertragen.

01:19:33.980 --> 01:19:42.380
Denn 32 mal 70.000 gibt 2048 Kilobit, das ist genau die Angabe von

01:19:42.380 --> 01:19:42.620
oben.

01:19:43.300 --> 01:19:46.240
Passen Sie mit Einheiten immer auf, ob wir mit Byte oder Bit reden in

01:19:46.240 --> 01:19:48.880
Klausurofgaben, das wird immer auch gerne wieder falsch gemacht.

01:19:50.120 --> 01:19:50.360
Ja?

01:19:53.980 --> 01:19:55.200
Ja, aber das ist ein Komma.

01:20:00.410 --> 01:20:01.770
Genau das sind die Fallen, ja.

01:20:02.290 --> 01:20:05.390
Sonst hätten Sie halt nochmal das tausendfache mehr reingeschmissen,

01:20:05.510 --> 01:20:06.750
aber das haben wir ja heute auch.

01:20:07.770 --> 01:20:09.110
So, und das kriegen Sie, ja?

01:20:14.140 --> 01:20:17.720
Wir würden es wirklich klarstellen, dass es keine Ungenauigkeiten

01:20:17.720 --> 01:20:19.680
sind, wenn wir sowas als Klausurofgabe stellen.

01:20:20.420 --> 01:20:22.800
Wenn Sie es interessiert, wenn Sie bei der Telekom einen Primär

01:20:22.800 --> 01:20:25.540
-Multiplex -Anschluss mieten, kriegen Sie sowas geliefert, das heißt

01:20:25.540 --> 01:20:26.700
dann nur PCM 30.

01:20:27.460 --> 01:20:32.000
Und es sind dann wirklich 30 Kanäle da drin, weil zwei davon werden

01:20:32.000 --> 01:20:33.360
zur Signalisierung verwendet.

01:20:35.320 --> 01:20:37.140
Das gibt es also auf jeden Fall auch in echt.

01:20:39.900 --> 01:20:43.760
So, dann wollte ich Sie noch bitte ganz kurz an Paritäts-Bit für eine

01:20:43.760 --> 01:20:46.760
Tabelle von solchen digitalen Werten zu berechnen.

01:20:47.420 --> 01:20:50.080
Übertragung ist ja jetzt klar, wir digitalisieren das Signal in

01:20:50.080 --> 01:20:55.340
diskreten Zeitabständen und übertragen diese Worte dann, diese Worte,

01:20:55.440 --> 01:20:58.560
die wir hier dargestellt sehen, und die können wir sichern.

01:20:58.700 --> 01:21:01.180
Eines der Verfahren, die wir in der Vorlesung vorgestellt bekommen

01:21:01.180 --> 01:21:02.820
haben, war einfach ein Paritäts-Bit hinzuzufügen.

01:21:03.960 --> 01:21:05.720
In diesem Fall wollte ich ein ungerades.

01:21:06.880 --> 01:21:09.700
Das heißt, wir füllen einfach so auf, wenn wir das durchzählen, wie

01:21:09.700 --> 01:21:12.340
viele Bits vorhanden sind, bis eine ungerade Anzahl vorhanden ist.

01:21:12.340 --> 01:21:15.540
Hier haben wir zwei, also würden wir eins auffüllen, hier ebenfalls.

01:21:16.320 --> 01:21:17.900
Und so würden wir das dann einfach durchmachen.

01:21:25.350 --> 01:21:26.410
Das kriegen Sie hin, oder?

01:21:26.910 --> 01:21:29.130
Vorhin haben Sie mir erzählt, das ist alles trivial, was ich Sie

01:21:29.130 --> 01:21:29.390
frage.

01:21:30.110 --> 01:21:33.050
So, der digitale Wert, wer aus einer Bit-Folge nicht den digitalen

01:21:33.050 --> 01:21:36.070
Wert ausrechnen kann, das sehe ich auch kritisch.

01:21:37.050 --> 01:21:39.750
Wir wissen, welche Wertigkeit diese Bits hier betreiben.

01:21:45.660 --> 01:21:46.280
Und so weiter.

01:21:47.340 --> 01:21:49.620
Und wir rechnen dadurch natürlich den digitalen Wert.

01:21:49.760 --> 01:21:53.680
Das heißt, hier haben wir zum Beispiel 12, 10, 6.

01:21:55.220 --> 01:21:56.620
Sehen Sie, ich kann es doch noch ganz schnell.

01:22:04.860 --> 01:22:08.040
So, dann habe ich Sie gebeten, dass wir das Signal jetzt auch wieder

01:22:08.040 --> 01:22:09.020
in analoges umsetzen.

01:22:09.080 --> 01:22:11.440
Da gibt es dann meistens noch eine Vorschrift dazu, die ist hier unten

01:22:11.440 --> 01:22:16.260
dargestellt, wie ich den digitalen Wert, den ich hier habe, in der

01:22:16.260 --> 01:22:17.240
Amplitude umrechne.

01:22:19.620 --> 01:22:21.600
Das machen wir jetzt wirklich nicht allzu ausführlich.

01:22:22.540 --> 01:22:25.240
Wir kommen dann auf 0,7, wir kommen hier auf 0,8, das sind dann

01:22:25.240 --> 01:22:29.000
einfach Volt, wir kommen hier auf 1 Volt, hier auf 0,7 und so weiter.

01:22:32.880 --> 01:22:35.840
Dann ist als letzte Aufgabe natürlich noch, die Werte auch richtig in

01:22:35.840 --> 01:22:36.580
den Diagramm einzutragen.

01:22:37.720 --> 01:22:41.460
Wir hätten also für den ersten Signalschritt 0,7, für den zweiten

01:22:41.460 --> 01:22:42.860
hätten wir dann 0,8.

01:22:45.400 --> 01:22:46.580
Dann hätten wir 1.

01:22:47.780 --> 01:22:49.300
Dann hätten wir 0,7.

01:22:49.300 --> 01:22:54.400
Und erzeugen dann so aus unserem ehemals digitalen Signal ein analoges

01:22:54.400 --> 01:22:55.440
Ausgangssignal wieder.

01:22:55.640 --> 01:22:58.480
Das natürlich dann relativ diskret aussieht, aber wir haben es

01:22:58.480 --> 01:23:00.200
zurückgewandelt in ein analoges Signal.

01:23:01.280 --> 01:23:02.680
Das war jetzt sowieso verkehrt.

01:23:03.420 --> 01:23:04.440
Ich sage mal wieder nichts.

01:23:07.810 --> 01:23:09.970
Es sieht natürlich so aus, wenn wir von oben anfangen.

01:23:19.030 --> 01:23:19.890
Und so weiter.

01:23:24.380 --> 01:23:25.920
Das war's, hauen Sie ab.

01:23:29.240 --> 01:23:31.520
Wir haben nächsten Freitag schon die nächste Übung.

01:23:31.680 --> 01:23:33.740
Ich gucke, dass ich Ihnen das Übungsblatt wieder zur Verfügung stelle

01:23:33.740 --> 01:23:34.800
bis Montag oder so.

01:23:36.360 --> 01:23:39.080
Die Vorlesung hat das Problem, dass das Übungsblatt immer Stoff

01:23:39.080 --> 01:23:42.260
behandelt, der wirklich nicht besonders lange vorher bekannt ist.

01:23:42.340 --> 01:23:44.440
Wir haben ja heute Stoff dran gehabt, der war heute erst in der

01:23:44.440 --> 01:23:45.000
Vorlesung.

01:23:45.120 --> 01:23:47.700
Das ist ein prinzipielles Problem, da kommt man nicht drum rum.

01:23:48.260 --> 01:23:51.040
Also die Übungsblätter können Sie vorher mit dem Wissen aus der

01:23:51.040 --> 01:23:52.860
Vorlesung vorher nicht immer wirklich lösen.

01:23:53.480 --> 01:23:54.480
Da können wir nichts ändern.

01:23:54.480 --> 01:23:56.060
Bis bald.

01:23:57.020 --> 01:23:57.300
Tschüss.