WEBVTT

00:00.820 --> 00:01.980
Heute sind wir ein bisschen leerer.

00:13.860 --> 00:15.200
So, morgen zusammen.

00:17.820 --> 00:19.560
Zweiter Teil K&D für diese Woche.

00:20.400 --> 00:22.480
Und wie versprochen, heute machen wir nur einmal Vorlesung.

00:22.820 --> 00:24.280
Danach macht der Herr Walter mit Ihnen Übung.

00:28.880 --> 00:32.100
Wir haben uns im Prinzip gestern damit beschäftigt, dass wir erstmal

00:32.100 --> 00:36.020
so ein grundlegendes Sammelsurium an Protokollmechanismen uns

00:36.020 --> 00:37.000
bereitgelegt haben.

00:38.700 --> 00:44.200
Und wir haben ja immer davon gesprochen, dass wir entweder zwei

00:44.200 --> 00:47.300
Stationen haben, die direkt über ein Kabel einfach miteinander

00:47.300 --> 00:50.540
verbunden sind, oder irgendwie gelegentlich angenommen, dass da noch

00:50.540 --> 00:53.480
so ein Netz dazwischen ist, was uns ein bisschen dazwischen funkt und

00:53.480 --> 00:54.900
vielleicht mal ein paar Daten verschluckt.

00:56.860 --> 01:02.780
Was wir heute machen wollen, ist ein Schritt konkreter werden in, ja,

01:02.940 --> 01:07.680
wenn wir uns jetzt tatsächlich die Schicht 2 angucken, was haben wir

01:07.680 --> 01:10.560
denn dort für Protokolle, was haben wir dort für Probleme, die wir

01:10.560 --> 01:11.160
lösen müssen.

01:11.720 --> 01:14.780
Und wir werden gerade wieder dann zurückkommen auf das Sammelsurium,

01:14.820 --> 01:16.420
was wir uns gestern bereitgelegt haben.

01:16.900 --> 01:18.740
Allerdings in einem ein bisschen konkreteren Kontext.

01:19.700 --> 01:24.300
Das heißt, heute im Mittelpunkt einmal, was wir hier in der Schicht 2

01:24.300 --> 01:24.700
haben.

01:25.300 --> 01:28.980
Und dann werden wir uns noch ein bisschen genauer angucken, ja, wie

01:28.980 --> 01:32.540
beschreibe ich denn Dienste und Protokolle eigentlich wenn ich das

01:32.540 --> 01:34.100
einigermaßen formal machen will.

01:34.560 --> 01:39.540
Denn auch in unserem Bereich gibt es ein formales Rahmenwerk, was wir

01:39.540 --> 01:40.460
verwenden können.

01:40.800 --> 01:42.680
Und das werden Sie sich ja dann nachher in der Übung mit dem Herrn

01:42.680 --> 01:44.680
Walter nochmal ein bisschen vertiefen auch.

01:46.980 --> 01:50.320
Ja, die Sicherungsschicht kann man sich erstmal wieder ganz allgemein

01:50.320 --> 01:50.800
anschauen.

01:51.120 --> 01:54.420
Und das sollte man sich immer mal wieder ein bisschen ins Kopf

01:54.420 --> 01:57.320
zurückrufen, wenn man später darüber nachdenkt, in welcher Schicht bin

01:57.320 --> 01:59.300
ich denn, was muss ich denn gerade für Probleme lösen.

01:59.960 --> 02:03.460
Wir sind jetzt hier auf der Schicht 2.

02:04.360 --> 02:06.860
Wir hatten uns schon mal ein bisschen letzte Woche angeguckt Schicht

02:06.860 --> 02:11.120
1, wo ja dummerweise alles mögliche an Fehlern passieren kann, die wir

02:11.120 --> 02:12.240
nicht verhindern können.

02:13.540 --> 02:19.780
Wir haben hier einen Dienstzugangspunkt, über den wir die Dienste der

02:19.780 --> 02:22.300
physikalischen Schicht, also des Mediums in Anspruch nehmen.

02:23.200 --> 02:28.460
Und wir müssen hier oben irgendwo einen Dienst abliefern, an den

02:28.460 --> 02:30.020
Dienstbenutzer, den wir oben drüber haben.

02:30.360 --> 02:33.760
Das Spielchen haben wir also immer, bis wir zur Anwendung hochkommen.

02:35.220 --> 02:39.340
Was ist wichtig jetzt, was wir uns angucken müssen, das ist eben

02:39.340 --> 02:44.420
einmal genau die Tatsache, naja, wie setze ich jetzt solche

02:44.420 --> 02:48.100
Protokollmechanismen zur Fehlererkennung und Behebung ein, um eben

02:48.100 --> 02:52.460
mich abzusichern gegen Verfälschungen, gegen Verluste, also um den

02:52.460 --> 02:57.920
Benutzer, der hier oben dran sitzt, dieses Dienstes tatsächlich einen

02:57.920 --> 02:59.480
zuverlässigen Dienst anbieten zu können.

03:00.800 --> 03:03.780
Dann muss ich mir überlegen, wie ich ein Protokoll dazu aufbaue, was

03:03.780 --> 03:06.400
die Regeln sind, nach denen das Protokoll verfährt.

03:07.040 --> 03:10.760
Und ich muss mir auch irgendwo dann mal überlegen, naja, wie

03:10.760 --> 03:15.880
strukturiere ich eigentlich die Daten, so dass der Empfänger damit was

03:15.880 --> 03:16.520
anfangen kann.

03:17.920 --> 03:21.860
Das geht jetzt darauf, dass Sie hier zwei Protokollinstanzen ja

03:21.860 --> 03:23.820
nachher haben, die miteinander reden.

03:24.760 --> 03:27.180
Und wir haben ja gesehen, wir pflanzen immer eine

03:27.180 --> 03:30.700
Protokollkontrollinformation davor, den sogenannten Paketkopf.

03:31.560 --> 03:33.700
Und den muss man sich mal überlegen, was man eigentlich reinschreiben

03:33.700 --> 03:35.960
muss, damit das überhaupt vernünftig funktioniert.

03:36.460 --> 03:40.260
Das werden wir uns also ein bisschen am Beispiel anschauen.

03:41.480 --> 03:43.780
Ja, und dann haben wir noch so ein Problem, was wir da lösen müssen,

03:44.040 --> 03:48.240
von dem haben wir bisher noch gar nicht gesprochen, nämlich die

03:48.240 --> 03:50.360
Medienzugangskontrolle bei geteilten Medien.

03:51.040 --> 03:52.020
Was meine ich damit?

03:52.020 --> 03:53.340
Ist ganz primitiv.

03:54.380 --> 03:57.860
Dass Sie ein Kabel haben, was zwei Stationen verbindet und wo nur zwei

03:57.860 --> 04:01.860
Stationen dranhängen, ist in der Praxis selten der Fall.

04:02.760 --> 04:04.960
Sie haben irgendwelche Medien, die Sie gemeinsam benutzen.

04:05.300 --> 04:08.880
Denken Sie daran, wer von Ihnen Ducat benutzt, der benutzt hier

04:08.880 --> 04:11.140
einfach den Äther und bestimmte Frequenzbereiche.

04:12.100 --> 04:14.260
Und das machen vielleicht mehrere von Ihnen gleichzeitig.

04:15.140 --> 04:18.200
Also müssen wir uns irgendwo drum kümmern, geht das wirklich

04:18.200 --> 04:22.180
gleichzeitig oder müssen wir das koordinieren, damit die irgendwie

04:22.180 --> 04:26.100
kontrolliert nacheinander das Ganze abläuft, sodass keine

04:26.100 --> 04:27.980
Verfälschungen und solche Sachen passieren.

04:28.680 --> 04:32.300
Und genau das werden wir uns heute auch an Beispielen, die Sie aus der

04:32.300 --> 04:35.080
Praxis kennen, anschauen.

04:36.580 --> 04:40.040
Wenn man sich überlegt, was bietet nachher die Sicherungsschicht den

04:40.040 --> 04:45.760
oberen Schichten an, dann haben wir ja oben drüber hier die Schicht 3,

04:45.900 --> 04:48.840
Vermittlungsschicht, von der wir gesagt haben, die kümmert sich um die

04:48.840 --> 04:49.880
Wegewahl und sowas.

04:50.400 --> 04:53.080
Und für die Schicht 3 ist nachher das unten drunter einfach irgendein

04:53.080 --> 04:56.160
Medium, dessen bestimmten Dienst anbietet.

04:57.080 --> 04:59.540
Die guckt da gar nicht mehr rein, die will da gar nichts von wissen

04:59.540 --> 05:02.620
und die will schon gar keine Information darüber haben, wie jetzt

05:02.620 --> 05:04.800
Medienzugangskontrolle oder sowas funktioniert.

05:05.540 --> 05:08.640
Das ist für hier oben nachher komplett transparent.

05:11.680 --> 05:16.700
So, dann schauen wir uns das mal an am Beispiel der lokalen Netze.

05:18.140 --> 05:20.420
Das sieht nachher in öffentlichen Netzen wieder ein bisschen anders

05:20.420 --> 05:23.640
aus, ist aber irrelevant, sich das jetzt unbedingt alles im Detail

05:23.640 --> 05:26.220
anzugucken, sondern wir nehmen mal das eine Beispiel und wenn man das

05:26.220 --> 05:29.480
verstanden hat, dann kriegt man den Rest auch ungefähr in den Griff.

05:33.680 --> 05:36.220
Medien, ja da braucht man gar nicht viel zu sagen, ist denke ich

05:36.220 --> 05:39.040
einfach klar, typischerweise verdrillte Kupferadern, was sie irgendwo

05:39.040 --> 05:42.920
rumliegen haben, Coax-Kabel, ich hatte ja letzte Woche mal dieses

05:42.920 --> 05:46.820
dicke gelbe Ding, auch solche Sachen gibt es und gab es.

05:49.180 --> 05:53.380
Datenraten, die sie typischerweise verwenden, liegen irgendwo so im

05:53.380 --> 05:57.440
Bereich 10 Megabit bis 1 Gigabit, je nachdem wie gut ihr Netz jetzt

05:57.440 --> 05:58.280
ausgestattet ist.

05:59.920 --> 06:03.960
Glasfaser, ja gibt es auch, wir haben es zum Teil am Institut

06:03.960 --> 06:06.820
tatsächlich mit Glasfaser vernetzt, viele machen es nicht, weil es

06:06.820 --> 06:07.600
einfach teuer ist.

06:08.640 --> 06:10.820
Und nicht unbedingt den tollen Mehrwert bringt.

06:11.660 --> 06:14.340
Das soll uns aber nicht interessieren, wir wollen uns eigentlich heute

06:14.340 --> 06:18.500
stürzen, auf diese graue Box hier drin, nämlich was passiert obendrin

06:18.500 --> 06:19.160
in Schicht 2.

06:21.720 --> 06:27.160
Schicht 2 nochmal, was war denn nochmal der Unterschied zwischen

06:27.160 --> 06:28.700
Schicht 2 und Schicht 4?

06:29.960 --> 06:33.900
So eine Sache, die man sich ebenfalls gelegentlich nochmal fragen

06:33.900 --> 06:34.160
muss.

06:34.160 --> 06:35.280
Hat das jemand noch im Griff?

06:35.760 --> 06:38.600
Schicht 3 habe ich ja gerade gesagt, war für die Vermittlung, damit es

06:38.600 --> 06:40.960
da irgendwo durchs Netz zielgerichtet flutscht.

06:42.640 --> 06:46.240
Was macht Schicht 2 und was macht im Gegensatz dazu Schicht 4?

06:47.800 --> 06:48.700
Ist jemand noch im Griff?

06:53.370 --> 06:55.230
Oder kann man eine der beiden Schichten wegschmeißen?

06:56.390 --> 06:57.850
Wäre ja auch eine Option, hätten wir eine weniger.

07:05.720 --> 07:06.980
Blätterwühl, ja.

07:16.840 --> 07:19.940
Da kommt jetzt das Antwort, Schicht 4 kümmert sich darum, ob die

07:19.940 --> 07:24.100
Pakete angekommen sind und Schicht 2 kümmert sich mehr um die Bits.

07:28.550 --> 07:31.010
Zur Überprüfung, ob die Bits stimmen.

07:31.750 --> 07:36.630
Ja, Schicht 2 macht auf jeden Fall irgendwie, steht auch hier,

07:36.770 --> 07:37.010
Verfälschungssicherung.

07:37.910 --> 07:41.370
Das heißt, wir müssen irgendwie prüfen, ob das richtig angekommen ist.

07:42.950 --> 07:43.390
Ja?

07:47.840 --> 07:51.900
Schicht 2 macht Punkt zu Punkt, Schicht 4 macht Ende zu Ende, kommt

07:51.900 --> 07:52.160
jetzt.

07:52.260 --> 07:54.940
Jetzt haben wir also einmal Bits, Pakete, einmal Punkt zu Punkt, Ende

07:54.940 --> 07:55.340
zu Ende.

07:58.560 --> 07:59.940
Und alles ist irgendwo wahr.

08:02.380 --> 08:06.100
Einer der ganz wichtigen Unterschiede ist in der Tat, wenn man sich so

08:06.100 --> 08:11.480
ein Netz anguckt, das ist ein Endsystem, das sei ein Endsystem, also

08:11.480 --> 08:12.960
Schichten 1 bis 7.

08:18.480 --> 08:22.100
Hier haben wir in der Regel Schicht 4 und hier haben wir in der Regel

08:22.100 --> 08:27.540
Schicht 4 und die überprüfen, ob Ende zu Ende, also zwischen den

08:27.540 --> 08:31.920
beiden Anwendungen tatsächlich alle Daten, wenn es zuverlässig sein

08:31.920 --> 08:34.600
soll, korrekt und so weiter, angekommen sind.

08:35.420 --> 08:43.160
Schicht 2 operiert in der Tat zunächst mal zwischen benachbarten

08:43.160 --> 08:46.180
Systemen, also unmittelbar benachbarten Systemen.

08:46.960 --> 08:51.040
Das heißt, wenn Sie eine Schicht 4 Kommunikation haben, sind darin

08:51.040 --> 08:53.900
mehrere Schicht 2 Kommunikationen involviert.

08:55.140 --> 08:59.280
Und im Moment wollen wir jetzt genau über diesen Teil sprechen.

08:59.880 --> 09:02.740
Jetzt müssen wir nochmal zurückkommen, es gab irgendwie die Antwort

09:02.740 --> 09:04.600
Pakete und Bits.

09:06.580 --> 09:11.600
Bits an sich ist eine Sache, die ganz klar erstmal in die

09:11.600 --> 09:12.980
physikalische Schicht gehören.

09:13.480 --> 09:17.220
Da schauen wir, wie wir sie darstellen, was eine 1 ist und wie wir

09:17.220 --> 09:18.680
erkennen, ob das eine 0 oder eine 1 ist.

09:20.400 --> 09:26.500
Hier oben verwenden wir schon Pakete, wir werden uns nachher auch ein

09:26.500 --> 09:30.000
paar Beispiele anschauen, schauen aber tatsächlich nach, ob wir

09:30.000 --> 09:31.520
Bitfehler drin haben in den Paketen.

09:33.560 --> 09:35.760
Tauschen aber einzelne Pakete aus.

09:36.240 --> 09:42.000
Wir tauschen ebenfalls bei Schicht 4 noch Pakete aus, die dann

09:42.000 --> 09:46.860
irgendwo in den oberen Schichten zu den Daten zusammengesetzt werden,

09:46.920 --> 09:48.360
die die Anwendung miteinander austauschen.

09:49.800 --> 09:53.680
Was müssen wir jetzt tun, um tatsächlich diese Daten austauschen zu

09:53.680 --> 09:53.860
können?

09:53.860 --> 09:56.160
Wir sind auf Schicht 2 eben, wie gesagt, jetzt erstmal zwischen

09:56.160 --> 09:58.280
benachbarten Systemen.

09:58.760 --> 10:01.860
Wir müssen die Sachen schauen, die wir uns gestern angeguckt haben.

10:02.440 --> 10:05.340
Wie kriegen wir die Dinger korrekt rüber, wie erkennen wir, dass Daten

10:05.340 --> 10:08.120
fehlen, dass zu viele Daten da sind, dass sie in der richtigen

10:08.120 --> 10:12.400
Reihenfolge sind, dass meinetwegen der Sender hier das nächste System,

10:12.500 --> 10:13.800
also den Empfänger, nicht überschwemmt.

10:13.940 --> 10:15.540
Also Flusssteuerung müssen wir irgendwo machen.

10:16.780 --> 10:20.560
Ja, und mit Strukturierung der Übertragung ist nachher gemeint, wir

10:20.560 --> 10:26.000
müssen uns irgendwo ein Format überlegen, das standardisiert sein muss

10:26.000 --> 10:29.480
und das eben Sender und Empfänger bekannt sein muss.

10:31.300 --> 10:33.980
Aber bevor wir das machen können, müssen wir uns erstmal darum

10:33.980 --> 10:36.580
kümmern, ja, wenn ich jetzt ein Medium habe und mehrere sich auf

10:36.580 --> 10:39.640
dieses Medium draufstürzen, weil sie alle losreden, so wie Sie hier

10:39.640 --> 10:43.600
gelegentlich alle auf einmal losreden, dann müssen wir das irgendwie

10:43.600 --> 10:44.180
kontrollieren.

10:44.860 --> 10:48.340
Weil alle auf einmal geht in einem Medium nicht, zumindest wenn ich

10:48.340 --> 10:52.780
korrekt, also ohne Fehler übertragen will.

10:54.060 --> 10:57.580
Und da gibt es im Wesentlichen zwei Verfahren, wie ich das machen

10:57.580 --> 10:57.820
kann.

10:58.300 --> 11:01.140
Ich kann es einmal konkurrierend machen, das heißt, ich gebe das

11:01.140 --> 11:05.080
Medium frei und dann wer zuerst kommt, malt zuerst nach dem Motto.

11:05.840 --> 11:10.300
Oder ich kann es kontrolliert machen, indem ich das Medium speziell

11:10.300 --> 11:10.820
zuteile.

11:11.880 --> 11:15.440
Kontrolliert wäre beispielsweise, wenn ich jetzt irgendwie der Reihe

11:15.440 --> 11:19.680
nach hier allen von Ihnen immer einen bestimmten Zeitrahmen geben

11:19.680 --> 11:22.560
würde und Sie könnten in dem eine Frage stellen.

11:23.640 --> 11:27.100
Konkurrierend ist, wenn ich eine Frage stelle und ich darauf hoffe,

11:27.280 --> 11:29.220
dass möglichst schnell von irgendwo eine Antwort kommt.

11:33.000 --> 11:37.920
Was gibt es zunächst für unterschiedliche Topologien von Netzen, die

11:37.920 --> 11:41.260
wir uns hier angucken sollten zumindest mal.

11:41.320 --> 11:42.320
Was ist üblich?

11:44.520 --> 11:48.620
Einmal habe ich die Möglichkeit, ich kann hier die Daten voll

11:48.620 --> 11:49.120
vermaschen.

11:49.960 --> 11:53.620
Das heißt, ich lege wirklich physikalische Verbindungen zwischen

11:53.620 --> 11:55.840
jeweils zwei Kommunizierenden.

11:57.320 --> 12:00.420
Dass das in großen Netzen oder schon in Mittelgroßen keine clevere

12:00.420 --> 12:01.620
Idee ist, dürfte einleuchten.

12:02.520 --> 12:04.160
Dann hätten wir hier so Berge von Kabeln liegen.

12:04.860 --> 12:09.480
Ist also nichts, mit dem man wirklich im Kommunikationsbereich in

12:09.480 --> 12:11.200
größeren Netzen arbeiten kann.

12:12.600 --> 12:15.320
Man könnte sagen, man macht es teilvermascht, das klingt schon sehr

12:15.320 --> 12:16.100
viel vernünftiger.

12:17.020 --> 12:20.820
Das heißt, Sie haben einzelne Systeme, die miteinander verbunden sind,

12:20.820 --> 12:27.280
manche direkt, wie beispielsweise hier das System 1 und 2, und manche

12:27.280 --> 12:31.740
vielleicht indirekt, wie das System 2 und 3, was hier erstmal über

12:31.740 --> 12:35.380
System X drüber gehen muss, wenn 2 3 erreichen muss.

12:36.040 --> 12:38.980
Das ist durchaus was Praxisrelevantes, das finden Sie im Netz.

12:39.960 --> 12:44.800
Sie finden auch Netzbereiche mit Vollvermaschung, aber nicht im

12:44.800 --> 12:45.820
gesamten globalen Netz.

12:46.900 --> 12:48.120
Was kann man dann machen?

12:48.200 --> 12:52.920
Immer schön zur Strukturierung, noch in der Informatik, in vielen

12:52.920 --> 12:57.880
Disziplinen irgendwo vertreten, wir bauen uns Bäume auf, machen eine

12:57.880 --> 12:58.420
Hierarchie.

12:59.320 --> 13:02.280
Das werden wir in vielen Sachen noch finden, dass wir das verwenden,

13:02.520 --> 13:04.200
das kann ich auch bei der Vernetzung machen.

13:05.960 --> 13:06.400
Problem?

13:07.280 --> 13:11.180
Ja, was ist denn für ein Problemchen dabei, wenn Sie so ein Netz in

13:11.180 --> 13:12.380
der Art und Weise aufbauen?

13:19.220 --> 13:21.480
Der Rechner in der Mitte muss ziemlich Power haben.

13:21.600 --> 13:25.420
Ich nehme an, in der Mitte meinen Sie den, ja, über den geht alle

13:25.420 --> 13:26.200
Kommunikation.

13:27.620 --> 13:30.920
Das ist also ein zentraler Punkt, das ist etwas, was wir im

13:30.920 --> 13:33.780
Allgemeinen vermeiden wollen, im vernetzten System.

13:35.180 --> 13:38.860
Das eine Problem ist, der muss sehr leistungsfähig sein, und das

13:38.860 --> 13:43.620
nächste Problem ist, denke ich, auch klar, wenn er ausfällt, wenn wir

13:43.620 --> 13:46.260
da mal ein Kreuzchen durchmachen, dann haben wir ein Problem.

13:47.200 --> 13:51.020
Dann müssen wir irgendwie das reorganisieren und eine neue Struktur

13:51.020 --> 13:53.020
finden, damit wir überhaupt kommunizieren können.

13:54.640 --> 14:01.100
Dann haben wir drei weitere Topologien, die man jetzt typischerweise

14:01.100 --> 14:05.580
im lokalen Netzebereich findet und teilweise beim Stern auch in

14:05.580 --> 14:06.840
globalen Netzen.

14:09.880 --> 14:12.300
Bustopologie ist eine, die...

14:12.300 --> 14:13.520
Ja, ne, fangen wir mal beim Stern an.

14:13.540 --> 14:15.780
Das ist eigentlich so der Ausgangspunkt gewesen früher mal.

14:17.100 --> 14:20.300
Dass man gesagt hat, man macht sternförmige Vernetzung, das findet

14:20.300 --> 14:25.580
sich typischerweise in Telekommunikationsnetzen sehr stark, ist auch

14:25.580 --> 14:29.040
relativ lange betrieben worden, hat natürlich ein Problem.

14:30.400 --> 14:33.560
Klar, der Stern ist wieder so ein halber zentraler Punkt hier im Netz,

14:33.680 --> 14:35.160
aber das ist ein relativ kleines Netz.

14:36.480 --> 14:40.900
Und das Problem, was man dann irgendwann mal gesehen hat, hier führen

14:40.900 --> 14:42.380
ja jede Menge Leitungen hin.

14:43.280 --> 14:46.940
Wenn Sie sich mal Anfang der 80er, Ende der 70er Jahre hinversetzen

14:46.940 --> 14:49.900
und dieses dicke Kabel noch mal vor Augen halten, was ich letzte Woche

14:49.900 --> 14:53.780
mit hatte, das waren Zeiten, wo man solche Kabel verwendet hat, dann

14:53.780 --> 14:54.660
ist das natürlich unschön.

14:54.920 --> 14:57.480
Dann führt das zu riesigen Kabelbäumen, wenn die alle auf die Zentrale

14:57.480 --> 14:58.060
zulaufen.

14:59.500 --> 15:02.060
Also hat man sich mal gedacht, naja, das können wir ja viel besser

15:02.060 --> 15:06.880
machen, dann legen wir doch einen Bus, das heißt ein Kabel,

15:07.900 --> 15:12.700
beispielsweise durch ein Stockwerk, und jeder, der einen Rechner

15:12.700 --> 15:15.720
anschließen will, der stöpselt sich an das Kabel dran, so wie es hier

15:15.720 --> 15:16.480
angezeichnet ist.

15:17.380 --> 15:19.760
Das sind busbasierte Netze, die man damit entwickelt hat.

15:20.060 --> 15:22.300
Hat den Vorteil, sie haben nicht diese Kabelstränge, die

15:22.300 --> 15:25.440
zusammenlaufen, hat aber auf der anderen Seite viele Nachteile.

15:28.840 --> 15:32.800
Da kann viel schief gehen, wenn Sie so Stationen hier drankoppeln,

15:33.200 --> 15:36.540
oder wenn Sie verschiedene Segmente nachher miteinander verbinden.

15:39.020 --> 15:42.160
Ich kann mich noch gut daran erinnern, an meiner Zeit, ich glaube, da

15:42.160 --> 15:46.140
war ich sogar noch Student, wo ich im Mathebau unten saß, da hat die

15:46.140 --> 15:48.660
Telematik auch noch ein paar Räume, und wir haben irgendwie was vor

15:48.660 --> 15:51.340
uns hingebastelt, wir hatten damals schon Ethernet, das war eine der

15:51.340 --> 15:54.300
ersten Installationen, die es überhaupt gab, und da gibt es dann hier

15:54.300 --> 15:59.700
am Ende so Abschlusswiderstände, damit das Netz überhaupt

15:59.700 --> 16:03.920
funktionieren kann, und gelegentlich musste man halt mal eine Station

16:03.920 --> 16:07.380
reinstecken und rausnehmen, und wir haben da halt reingesteckt,

16:07.460 --> 16:12.480
rausgenommen, dabei muss ich irgendwie den da abgezogen haben.

16:13.420 --> 16:16.500
Ich war eigentlich noch glücklich, ich kam dann ein paar Stunden

16:16.500 --> 16:19.940
später hoch ans Institut, und der Systemadministrator lief rum und war

16:19.940 --> 16:23.820
ganz aufgeregt, und das Netz funktioniert nicht, und irgendwas ist...

16:23.820 --> 16:26.200
da habe ich mich leise wieder getrollt, habe mal geguckt, was wir

16:26.200 --> 16:29.960
unten geschafft haben, und allein durch das Abziehen eines solchen

16:29.960 --> 16:31.920
Widerstandes können Sie das gesamte Netz lahmlegen.

16:33.140 --> 16:35.820
Ähnliche Sachen passieren Ihnen, wenn Sie hier unsauber Stationen

16:35.820 --> 16:36.780
zwischendrin einklinken.

16:37.920 --> 16:43.760
Also eine Sache im Netz, das ist okay, aber hat auch seine Tücken.

16:44.200 --> 16:48.320
Heute hat man eigentlich keine reinen busbasierten Netze mehr, sondern

16:48.320 --> 16:52.560
man geht zumindest physikalisch von der Sterntopologie aus.

16:53.240 --> 16:56.640
Und da müssen wir jetzt auch unterscheiden lernen, physikalisch eine

16:56.640 --> 16:59.280
Sterntopologie oder auf Schicht 2 eine.

16:59.460 --> 17:01.420
Das werden wir gleich noch ein bisschen beleuchten, wo da der

17:01.420 --> 17:02.020
Unterschied ist.

17:02.900 --> 17:06.540
Ja, und die andere Möglichkeit, machen wir keinen Bus, so wie das die

17:06.540 --> 17:07.600
ganze Welt gemacht hat.

17:08.260 --> 17:09.660
Nee, man könnte ja auch einen Ring machen.

17:10.000 --> 17:13.060
Das war die Idee von IBM damals, die machen ja immer ein bisschen was

17:13.060 --> 17:13.380
anders.

17:14.220 --> 17:17.880
Die haben also ein Ringnetz aufgebaut, das darauf basiert, dass ich im

17:17.880 --> 17:23.200
Prinzip die Stationen so im Ring miteinander verbinde.

17:24.020 --> 17:26.780
Das heißt, die Kommunikation geht tatsächlich hier, wenn der was

17:26.780 --> 17:28.940
sendet, irgendwie einmal den Ring durch.

17:31.060 --> 17:36.140
Ist eine Struktur, die es ebenfalls in die Praxis geschafft hat, aber

17:36.140 --> 17:41.400
nicht ganz so breit wie die Bustopologie, die im Wesentlichen von

17:41.400 --> 17:43.060
Xerox damals getrieben wurde.

17:45.280 --> 17:49.940
Wenn Sie einen Ring aufbauen, haben Sie auch wieder physikalisch einen

17:49.940 --> 17:50.180
Stern.

17:51.320 --> 17:54.360
Den werden Sie nämlich so aufbauen, dass Sie hier in der Mitte einen

17:54.360 --> 17:58.340
Verteiler haben und die einzelnen Stationen da jeweils reingehen,

17:58.820 --> 17:59.160
wieder rausgehen.

18:01.060 --> 18:05.460
Also so, so, dann geht es so an die nächste Station und so an die

18:05.460 --> 18:05.740
nächste.

18:06.020 --> 18:08.280
Das heißt hier auch typischerweise wieder die Unterscheidung

18:08.280 --> 18:08.960
physikalisch.

18:08.960 --> 18:12.980
Ein Stern, logisch auf Schicht 2 ein Ring.

18:15.400 --> 18:21.320
Ja, dann kam so Anfang der 80er Jahre die Sache, dass man sich

18:21.320 --> 18:23.360
vermehrt damit beschäftigt hat, wie kann ich denn überhaupt solche

18:23.360 --> 18:24.680
Netze aufbauen, wie mache ich es?

18:25.220 --> 18:26.840
Und wie mache ich es vielleicht standardisiert?

18:27.780 --> 18:29.760
Uns wurden jede Menge Standards entwickelt.

18:30.600 --> 18:37.940
Das Gremium dafür ist die IEEE, die eben solche Standards entwirft und

18:37.940 --> 18:38.940
dann auch verabschiedet.

18:39.820 --> 18:41.460
Wer ist denn von Ihnen Mitglied bei der IEEE?

18:42.880 --> 18:45.720
Aha, wer ist denn von Ihnen Mitglied bei der ACM?

18:47.420 --> 18:48.480
Und bei der GEI?

18:52.320 --> 18:54.260
Haben Sie sich bei IEEE gemeldet?

18:57.080 --> 18:58.320
Wer kennt denn die GEI?

19:01.080 --> 19:02.340
Wer kennt die ACM?

19:03.780 --> 19:05.080
Und das IEEE?

19:09.880 --> 19:11.800
Mitglied werden lohnt sich dort tatsächlich.

19:12.620 --> 19:15.940
Das mag uninteressant sein, solange man im Grundstudium ist.

19:16.700 --> 19:19.720
Wenn man in das Hauptstudium reinkommt und dann auch so ein bisschen

19:19.720 --> 19:22.620
sich ja langsam irgendwo vertieft in spezielle Richtungen.

19:23.060 --> 19:27.980
Die IEEE hat unterschiedliche Untergruppen, beispielsweise die

19:27.980 --> 19:32.160
Communication Society, die jetzt für uns zuständig ist und in den

19:32.160 --> 19:36.440
Gruppen gibt es dann jeweils sehr attraktive Zeitschriften.

19:36.700 --> 19:40.960
Wenn Sie als Student beitreten, kriegen Sie zu einem ziemlich geringen

19:40.960 --> 19:44.940
Preis einmal überhaupt die Mitgliedschaft und zum zweiten dann auch

19:44.940 --> 19:45.840
solche Zeitschriften.

19:45.920 --> 19:48.080
Und gerade wenn Sie anfangen, sich zu vertiefen in eine bestimmte

19:48.080 --> 19:50.840
Richtung, auch wenn Sie Richtung Diplomarbeit gehen, ist sowas

19:50.840 --> 19:53.600
interessant, weil Sie da einen Einblick kriegen, was passiert denn

19:53.600 --> 19:54.300
eigentlich in der Forschung.

19:58.170 --> 20:01.630
So, aber jetzt, was hat die IEEE im Bereich lokale Netze gemacht?

20:01.630 --> 20:04.990
LAN steht für Local Area Networks.

20:05.130 --> 20:10.230
Sie hat zunächst mal Standards entwickelt, die über die Schichten 1

20:10.230 --> 20:10.930
und 2 gehen.

20:13.410 --> 20:19.810
Dabei sind die Standards so entwickelt, dass ich in der Regel hier ein

20:19.810 --> 20:24.870
bestimmtes Netz, CSMACD, werden wir uns gleich angucken, also ein

20:24.870 --> 20:29.910
bestimmtes Verfahren verwenden kann und unten drunter transparent

20:29.910 --> 20:31.370
unterschiedliche physikalische Schichten.

20:31.870 --> 20:35.730
Das heißt, Sie entwickeln einen Standard für ein lokales Netz, nicht

20:35.730 --> 20:39.070
genau für eine physikalische Schicht, sondern Sie können die

20:39.070 --> 20:40.690
physikalische Schicht dabei auswechseln.

20:41.390 --> 20:48.210
Das mag trivial klingen, ist aber wichtig, um den flexiblen Einsatz

20:48.210 --> 20:50.070
auch für neue Netztechnologien zu gewähren.

20:50.910 --> 20:54.110
Das heißt, wenn dann eine neue Schicht 1 dazukommt, dann gibt es halt

20:54.110 --> 20:57.350
einen Appendix 27 oder so und dann steht drin, wie das mit dem

20:57.350 --> 20:58.730
Standard funktioniert.

21:01.310 --> 21:03.710
Das hier ist eine ganze Familie von Standards.

21:04.550 --> 21:08.850
Das 802.1 gibt so einen generellen Überblick über Architektur und

21:08.850 --> 21:11.870
Management und Blablabla, gucken wir uns nicht weiter an hier.

21:13.510 --> 21:18.970
Die Schicht 2, das ist jetzt der obere Teil der Sicherungsschicht,

21:19.050 --> 21:23.430
wenn wir nochmal zurückblättern, zwei Folien, dann ist das im Prinzip

21:23.430 --> 21:25.670
der Teil 2b hier oben.

21:30.670 --> 21:34.270
Und das, was hier so ein bisschen klein weggekommen ist, das ist im

21:34.270 --> 21:37.570
Prinzip der Teil 2a, der sich jetzt darum kümmert, wie darf ich denn

21:37.570 --> 21:40.230
auf dieses Medium, was ich unten drunter habe, zugreifen.

21:44.750 --> 21:48.470
Dann gibt es hier jede Menge Buchstaben, das ist ungefähr reflektiert

21:48.470 --> 21:50.570
die Reihenfolge, in der die Netze entwickelt wurden.

21:50.570 --> 21:57.450
Die zwei Klassiker sind ganz klar CSMA, CD oder Ethernet und der

21:57.450 --> 21:57.990
Tokenring.

21:59.670 --> 22:02.230
Tokenbus gab es zwischendurch auch, hat es nicht wirklich geschafft.

22:02.450 --> 22:07.050
802.6 ist ein Standard gewesen für ein schnelleres Netz, der hat es

22:07.050 --> 22:10.510
auch nicht wirklich geschafft, in der Praxis eingesetzt zu werden.

22:10.590 --> 22:13.210
Da sehen Sie, dass eine ganze Reihe von Sachen gar nicht erwähnt ist.

22:13.550 --> 22:16.450
Dann haben wir hier 802.11, das ist mal wieder etwas, was es in die

22:16.450 --> 22:20.050
Praxis geschafft hat und gerade gründlich dafür sorgt, dass der

22:20.050 --> 22:22.270
Bereich der Mobilkommunikation durcheinander gewirbelt wird.

22:22.370 --> 22:26.930
Das ist nämlich das Wireless LAN, also das, was Sie hier mit Ducat im

22:26.930 --> 22:31.210
Raum auch hier drin haben und das, was über Hotspots eben gerade

22:31.210 --> 22:33.010
ziemlich konkurriert mit UMTS.

22:34.210 --> 22:36.750
Und dann haben Sie hier eine ganze Reihe weiterer, es gibt noch mehr,

22:37.010 --> 22:37.810
die entwickelt wurden.

22:40.030 --> 22:44.210
Was wir uns anschauen werden, sind im Wesentlichen jetzt 802.3 und 802

22:44.210 --> 22:44.770
.5.

22:50.580 --> 22:53.920
Vielleicht nochmal einmal zurückgeblättert auf das Bild vorher.

22:54.480 --> 22:57.700
Kleine Bemerkung hier noch, was wir jetzt sehen, gerade am Beispiel

22:57.700 --> 22:59.100
der lokalen Netze.

22:59.740 --> 23:02.280
Man fängt an, die einzelnen Schichten innen drin nochmal zu

23:02.280 --> 23:02.820
unterteilen.

23:03.800 --> 23:06.000
Hier in Schicht 2a und Schicht 2b.

23:07.100 --> 23:10.760
Das ist eine logische Gliederung, bei der sich jetzt aber einzelne

23:10.760 --> 23:12.280
Schichten wegfallen lassen könnten.

23:15.420 --> 23:18.860
Im Referenzmodell an sich kann keine der Schichten wegfallen.

23:19.580 --> 23:22.360
Wenn Sie nachher innen drin nochmal gliedern, dann können Sie

23:22.360 --> 23:25.920
tatsächlich bei der praktischen Umsetzung Schichten wegfallen lassen.

23:26.060 --> 23:28.860
Und so eine interne Gliederung hat man im Prinzip nochmal in Schicht 3

23:28.860 --> 23:31.300
und weiteren Schichten.

23:32.680 --> 23:36.540
Okay, wenn wir jetzt auf 2a gehen und uns fragen, wie kann ich jetzt

23:36.540 --> 23:37.640
auf dieses Medium zugreifen?

23:39.040 --> 23:41.100
Wie funktioniert also die Medienzuteilung?

23:41.620 --> 23:45.620
Ja, zunächst kann ich mal sagen, ich kann Zeitmultiplexen machen,

23:45.960 --> 23:47.260
hatten wir ja auch kurz angesprochen.

23:47.420 --> 23:50.300
Das heißt, ich kann zu gewissen Zeitpunkten einem

23:50.300 --> 23:52.580
Kommunikationsteilnehmer das Medium komplett überlassen.

23:54.160 --> 23:56.900
Oder ich kann Frequenzmultiplexen machen.

23:57.540 --> 24:00.920
Das heißt, ich nehme einen bestimmten Frequenzbereich, den es einem

24:00.920 --> 24:03.940
Teilnehmer gibt, und einen anderen Frequenzbereich, den kriegt ein

24:03.940 --> 24:04.580
anderer Teilnehmer.

24:07.500 --> 24:10.220
Typischerweise beispielsweise im Bereich GSM oder so, da haben Sie

24:10.220 --> 24:13.480
bestimmte Frequenzen, die Sie benutzen können, und die werden jeweils

24:13.480 --> 24:18.840
einzelnen Betreibern, die ein, zwei davon oder so zugeteilt, und dann

24:18.840 --> 24:22.200
wieder irgendeinem Benutzer, der gerade mobil telefoniert, der kommt

24:22.200 --> 24:25.020
auf eine Frequenz, und dann wird aber noch ein bisschen Zeit

24:25.020 --> 24:25.700
gemultiplexed.

24:26.460 --> 24:29.340
Im lokalen Netzbereich haben wir eigentlich ausschließlich

24:29.340 --> 24:31.760
Zeitmultiplexen, was praxisrelevant ist.

24:32.900 --> 24:35.200
So, dann kann man aber weiter unterscheiden, wenn ich jetzt sage,

24:35.300 --> 24:38.780
okay, zu einem bestimmten Zeitpunkt dürfen Sie reden, und zu einem

24:38.780 --> 24:43.020
anderen Zeitpunkt dürfen Sie reden, ist es kontrolliert oder ist es

24:43.020 --> 24:44.880
nicht kontrolliert.

24:45.860 --> 24:49.200
Und, ja, obendrüber noch die Unterscheidung, ist es synchron oder ist

24:49.200 --> 24:49.600
es asynchron.

24:51.020 --> 24:55.740
Synchron bedeutet, das haben Sie beispielsweise bei ISDN, wenn Sie das

24:55.740 --> 25:01.580
Medium dann mal bekommen haben, dann wissen Sie, alle x Millisekunden

25:02.140 --> 25:04.680
darf ich für so und so viele Millisekunden das Medium benutzen.

25:05.360 --> 25:08.860
Das heißt, Sie kriegen dann regelmäßig das Medium zugeteilt, und

25:08.860 --> 25:12.580
können bei ISDN beispielsweise Ihre Sprachdaten drauf senden.

25:14.120 --> 25:18.260
Asynchron bedeutet, ja, ich teile es nicht regelmäßig zu, weil wenn

25:18.260 --> 25:22.900
ich das wirklich fest und regelmäßig zuteile, und der Benutzer benutzt

25:22.900 --> 25:26.100
das Medium gerade nicht, dann sind die Ressourcen verschwendet.

25:26.920 --> 25:29.440
Asynchron bedeutet, ich teile es genau dann zu, wenn ich es brauche,

25:30.780 --> 25:32.120
und zu keinem festen Raster.

25:32.960 --> 25:36.100
Und das kann ich eben einmal noch konkurrierend machen oder

25:36.100 --> 25:36.700
kontrolliert.

25:37.520 --> 25:42.640
Und für beides werden wir uns jetzt Beispiele anschauen, einmal für

25:42.640 --> 25:47.040
den konkurrierenden Zugriff und dann für den kontrollierenden Zugriff.

25:51.150 --> 25:54.930
Ja, was kann man in der einfachsten Art und Weise machen und wie hat

25:54.930 --> 25:56.150
man tatsächlich angefangen?

25:57.290 --> 26:00.930
Ich regele gar nichts, sondern ich überlasse die Sache dem Zufall.

26:02.170 --> 26:06.610
Und das war tatsächlich die Grundlage eines der ersten Netze, das

26:06.610 --> 26:08.690
gebaut wurde, das sogenannte ALOA-Netz.

26:09.850 --> 26:14.410
Das hat man ja aus Leidensdruck sozusagen aufgebaut.

26:15.170 --> 26:18.590
In Hawaii, da gibt es eine ganze Menge Inseln, man würde auch ganz

26:18.590 --> 26:21.670
gerne zwischen den Inseln, wollte man kommunizieren, also musste man

26:21.670 --> 26:26.050
sich irgendwas überlegen, hat ein Netz aufgebaut und hat es eben ALOA

26:26.050 --> 26:26.450
genannt.

26:28.130 --> 26:29.330
Wie funktioniert es?

26:29.970 --> 26:31.710
Komplett unkontrolliert, zufällig.

26:32.290 --> 26:35.330
Das heißt, wenn jemand senden will, beispielsweise Station 1 hier,

26:35.970 --> 26:36.790
dann sendet sie halt.

26:37.450 --> 26:39.990
Wenn Station 2 senden will, sendet sie auch.

26:40.810 --> 26:44.330
Station 1 senden, fängt wieder an zu senden und jetzt haben wir das

26:44.330 --> 26:48.470
Problem, Station 1 sendet und Station 2 hat auch Lust zu senden und

26:48.470 --> 26:50.450
wir haben beides auf dem Medium.

26:51.050 --> 26:53.590
Das kann natürlich nicht gut gehen, weil damit die Signale verfälscht

26:53.590 --> 26:57.090
werden und damit nicht mehr die korrekten Daten empfangen werden

26:57.090 --> 26:57.350
können.

26:57.790 --> 27:02.450
Das heißt, hier habe ich Perioden von gleichzeitigem Senden, was zu

27:02.450 --> 27:07.750
Kollisionen eben führt, das heißt überlagerten Signalen, das ist nicht

27:07.750 --> 27:08.330
wünschenswert.

27:10.830 --> 27:16.590
ALOA funktioniert nur als Netz, wenn die Sendewünsche unkorreliert

27:16.590 --> 27:19.370
sind und ich eben eine relativ geringe Wahrscheinlichkeit habe von

27:19.370 --> 27:20.870
Überlappungen von den Sendewünschen.

27:21.550 --> 27:23.030
Dann funktioniert es einigermaßen.

27:23.550 --> 27:26.770
Ich kann es auf eine relativ einfache Art verbessern.

27:27.210 --> 27:28.650
Ich nehme nämlich ein Slotted ALOA.

27:30.430 --> 27:33.150
Das bedeutet schlicht und einfach, ich habe hier bestimmte

27:33.150 --> 27:38.050
Zeitintervalle und ich darf nur anfangen zu senden, wenn ich am Anfang

27:38.050 --> 27:39.250
eines solchen Zeitintervalls bin.

27:40.750 --> 27:44.490
Das heißt, ich reduziere Kollisionen jetzt darauf, dass ich im

27:44.490 --> 27:45.670
gleichen Zeitintervall anfange.

27:46.890 --> 27:51.050
Und damit kann ich schon eine deutlich bessere Auslastung des Mediums

27:51.050 --> 27:51.570
erreichen.

27:52.410 --> 27:55.910
Übrigens ein Verfahren, was man heute bei GSM verwendet.

27:56.970 --> 28:01.270
Slotted ALOA ist ein Verfahren, das Sie bei GSM dann verwenden, wenn

28:01.270 --> 28:03.130
Sie anfangen zu kommunizieren.

28:03.810 --> 28:08.010
Wenn Sie mal Ihre Verbindung etabliert haben, dann ist nichts mehr

28:08.010 --> 28:08.370
ALOA.

28:08.710 --> 28:11.990
Aber genau der Zeitpunkt, zu dem Sie anfangen, wird so ein Verfahren

28:11.990 --> 28:12.530
verwendet.

28:16.290 --> 28:19.310
Beides ALOA und Slotted ALOA sind nicht wirklich gut geeignet für

28:19.310 --> 28:21.810
lokale Netze, wenn Sie mehrere Benutzer bedienen wollen.

28:22.810 --> 28:26.630
Was macht man, oder was hat man sich überlegt als konkurrierenden

28:26.630 --> 28:29.450
Zugriff, basierend auf einer Bustopologie.

28:29.450 --> 28:31.790
Ich habe also hier das Medium als Bus.

28:32.570 --> 28:35.670
Ich habe hier die vorhin schon erwähnten Abschlusswiderstände, die

28:35.670 --> 28:37.990
essentiell sind.

28:41.950 --> 28:45.270
Und ich habe jetzt eine Reihe von Stationen, die miteinander

28:45.270 --> 28:46.190
kommunizieren wollen.

28:48.150 --> 28:51.910
Ich kann es jetzt zumindest mal so weit abmildern, dass bevor ich aufs

28:51.910 --> 28:55.510
Medium rausschieße, ich mir mal anhöre, was eigentlich auf dem Medium

28:55.510 --> 28:56.270
gerade los ist.

28:57.070 --> 29:00.430
Und wenn jemand sendet, dann lasse ich den halt fertig senden.

29:00.810 --> 29:02.470
Dann fange ich nicht an, dem dazwischen zu funken.

29:03.350 --> 29:06.270
Und das ist im Prinzip schon die Idee, die da dahinter steht.

29:07.230 --> 29:11.450
Das heißt, ich höre das Medium ab, wenn ich sehe, dass das Medium

29:11.450 --> 29:13.570
belegt ist, okay, warten.

29:14.290 --> 29:18.550
Wenn das Medium frei ist, dann gibt es bestimmte Strategien, aber im

29:18.550 --> 29:20.270
Prinzip kann ich dann einfach mal anfangen zu senden.

29:24.420 --> 29:26.440
Trotzdem können Kollisionen auftreten.

29:27.300 --> 29:28.420
Sollte einem auch klar sein.

29:29.960 --> 29:36.580
Station A hier, zum Zeitpunkt T1 beispielsweise, fängt an zu senden,

29:36.820 --> 29:39.680
weil das Medium frei war, sendet fröhlich vor sich hin.

29:41.700 --> 29:46.500
Station B, irgendwie zum Zeitpunkt T3 hier, kommt auf die Idee, ich

29:46.500 --> 29:47.640
hätte ja auch was zu senden.

29:48.640 --> 29:52.400
Hört ebenfalls das Medium ab, Medium ist frei.

29:53.440 --> 29:56.160
Wie kann denn das überhaupt kommen, wenn Station A schon sendet, dass

29:56.160 --> 29:57.740
bei B das Medium noch frei ist?

30:00.200 --> 30:01.540
A sendet ja eigentlich schon.

30:05.680 --> 30:08.280
Das Signal ist einfach noch nicht da, weil die Leitung hat eine

30:08.280 --> 30:12.380
gewisse Länge, das Signal bebreitet sich mit einer gewissen

30:12.380 --> 30:15.760
Geschwindigkeit darüber aus, was nehmen wir denn immer so an als

30:15.760 --> 30:17.960
Geschwindigkeit für die Signalausbreitung?

30:21.940 --> 30:23.360
Zwei Drittel C, genau.

30:24.300 --> 30:26.820
Also, auf jeden Fall kann der dann noch gar nicht wissen, dass A ja

30:26.820 --> 30:31.200
sendet, und dann passiert es auch schon, der fängt an zu senden, hier

30:31.200 --> 30:34.060
treffen sich irgendwo die Signale, es kommt zu einer Kollision.

30:36.120 --> 30:37.160
Das ist die eine Sache.

30:39.800 --> 30:43.520
Die andere Sache ist, wenn wir die Kollision haben sollten, was sie

30:43.520 --> 30:49.200
tunlichst auch erkennen, weil ab dann ja keine brauchbaren Bits mehr

30:49.200 --> 30:55.000
auf der Leitung sind, die der Empfänger irgendwie benutzen kann, das

30:55.000 --> 30:57.620
heißt, wir sollten dann eigentlich auch relativ schnell aufhören zu

30:57.620 --> 30:58.040
senden.

31:00.220 --> 31:04.120
Also die Frage, wie kann ich jetzt erkennen, dass so eine Kollision

31:04.120 --> 31:05.120
hier aufgetreten ist?

31:07.160 --> 31:08.080
Was macht man?

31:08.940 --> 31:13.160
Man sagt nicht nur Listen Before Talk, sondern man sagt auch Listen

31:13.160 --> 31:17.480
While Talk, das heißt, während ich sende, höre ich das Medium weiter

31:17.480 --> 31:17.740
ab.

31:19.460 --> 31:24.340
In dem Beispiel hier wird B relativ schnell dann merken, hoppla, das,

31:24.460 --> 31:26.700
was jetzt auf dem Medium ist, ist nicht das, was ich rausgesendet

31:26.700 --> 31:26.880
habe.

31:28.220 --> 31:32.560
Also schicke ich doch mal ein Jamming-Signal, um alle zu warnen, dass

31:32.560 --> 31:36.260
etwas faul ist gerade auf dem Medium und höre auf zu senden.

31:37.840 --> 31:40.060
Gleiches macht Station A, wenn die erkennt, dass eine Kollision

31:40.060 --> 31:41.600
vorhanden ist, hört sie auch auf zu senden.

31:44.920 --> 31:48.000
Dann gibt es einen Back-Off-Algorithmus, den ich auch noch brauche,

31:48.680 --> 31:51.760
weil damit ist es ja nicht getan, dass die jetzt erkannt haben, dass

31:51.760 --> 31:54.880
die Kollision vorhanden ist und dass sie sich beide zurückziehen.

31:55.920 --> 31:58.780
Das nächste Problem ist ja, die wollen ja senden, also werden sie es

31:58.780 --> 31:59.680
wieder versuchen wollen.

32:00.980 --> 32:04.460
Also muss ich jetzt mir überlegen, ja, wie mache ich dann das

32:04.460 --> 32:05.220
wiederholte Senden?

32:05.640 --> 32:08.700
Ich sollte die nicht möglichst alle gleich wieder senden lassen, weil

32:08.700 --> 32:11.800
sonst haben wir wieder die Kollision, die sie wieder erkennen, wo sie

32:11.800 --> 32:14.120
sich wieder zurückziehen und wo sie wieder gleichzeitig anfangen zu

32:14.120 --> 32:14.360
senden.

32:14.460 --> 32:15.120
Dann haben wir so einen Deadlock.

32:16.180 --> 32:19.620
Es gibt dann einen Back-Off-Algorithmus, bei dem eben geregelt wird,

32:20.040 --> 32:21.760
wie lange wartet jetzt so eine Station.

32:22.160 --> 32:24.180
Mit einer bestimmten Wahrscheinlichkeit hat die dann verschiedene

32:24.180 --> 32:25.460
Zeitintervalle, die sie wartet.

32:26.780 --> 32:30.440
Und im Regelfall sind es unterschiedliche Zeitintervalle, die die

32:30.440 --> 32:31.420
beiden Stationen warten.

32:31.820 --> 32:33.520
Und damit hat sich das Problem entzerrt.

32:38.280 --> 32:42.740
Genau, das ist alles schlicht und einfach nochmal hier beschrieben.

32:43.460 --> 32:47.080
Kommen wir nochmal zu dem Bild zurück.

32:47.480 --> 32:50.500
Eines muss ich natürlich jetzt gewährleisten, ich habe eben gesagt,

32:50.580 --> 32:51.640
Listen While Talk.

32:52.400 --> 32:55.740
Also gesagt, die Station B hört hier noch auf das Medium drauf,

32:56.100 --> 32:56.900
während sie sendet.

32:58.500 --> 33:02.700
Das Medium kann lang sein und die Frage ist, wie gewährleiste ich

33:02.700 --> 33:06.300
eigentlich, dass der überhaupt noch auf das Medium draufhört.

33:07.180 --> 33:08.740
Sprich, dass der überhaupt noch was sendet.

33:10.140 --> 33:13.160
Und dazu macht man einen ganz einfachen Trick.

33:13.860 --> 33:15.520
Man macht eine Dateneinheit künstlich länger.

33:16.540 --> 33:20.020
Das heißt, auch wenn sie nur einen Byte schicken, macht man die

33:20.020 --> 33:23.640
Dateneinheit so lang, dass gewährleistet ist, dass B noch am Senden

33:23.640 --> 33:23.920
ist.

33:24.600 --> 33:30.000
Und da spielt dann die Länge des Mediums eine Rolle, um eben

33:30.000 --> 33:32.420
tatsächlich zu gewährleisten, dass das der Fall ist.

33:32.880 --> 33:35.860
Das heißt, man sendet künstlich mehr Bits, als man eigentlich senden

33:35.860 --> 33:36.340
würde.

33:38.100 --> 33:43.960
Das ist hier mit dem Stoppfeld PAD gemeint, was im Text steht, das

33:43.960 --> 33:44.540
Paddingfeld.

33:47.820 --> 33:51.560
Hier ist es nochmal als Ablauf in einer anderen Form dargestellt.

33:52.320 --> 33:57.920
Eben mit dem Übertragungsbeginn nach einer gewissen Zeit.

33:58.340 --> 34:03.020
Hier der Kollision und dann eben dem Entdecken der Kollision.

34:03.800 --> 34:11.580
Und theoretisch habe ich auch nochmal ein paar ähnliche Animationen

34:11.580 --> 34:13.940
rausgesucht, wie wir die gestern schon hatten.

34:14.640 --> 34:20.140
Und zwar vom Kollegen Effelsberg aus Mannheim auf seinem Webserver.

34:21.200 --> 34:24.400
Wenn man da mal drauf schaut, der hat jede Menge Animationen, unter

34:24.400 --> 34:28.400
anderem zu lokalen Netzen, aber auch zu Videokodierungen und allen

34:28.400 --> 34:29.400
möglichen anderen Dingen.

34:31.620 --> 34:39.020
Er hat unter anderem eines zu CSMA CD, bei dem man bestimmte Sachen,

34:46.100 --> 34:50.080
kann man sich eben auch ein paar Netze aufbauen.

34:53.080 --> 34:57.260
Hier zum Beispiel jetzt ein Netz mit sechs Stationen, dann muss man

34:57.260 --> 34:58.900
glaube ich hier noch irgendwie gucken, oder?

35:00.480 --> 35:03.920
Wir versuchen mal eine Übertragung mit Kollision hinzukriegen und

35:03.920 --> 35:10.060
sagen, der will zu dem senden und der will zu dem senden hier.

35:11.220 --> 35:14.660
Und wenn ich jetzt Glück habe und auf Start drücke, funktioniert es.

35:20.850 --> 35:23.070
Wieso war das vorhin so viel langsamer als jetzt?

35:28.110 --> 35:30.470
So, gesehen hat man eigentlich jetzt gar nichts, wo kann man denn die

35:30.470 --> 35:31.570
Geschwindigkeit...

35:31.570 --> 35:35.110
gut, man sieht, dass jetzt keine Kollision passiert ist.

35:37.250 --> 35:40.590
Ja, sehr viel mehr sieht man hier nicht dran, kann man aber auch mal

35:40.590 --> 35:43.430
rumspielen, wenn sie ein bisschen rauskriegen wollen, wie die Netze

35:43.430 --> 35:44.350
funktionieren.

35:45.070 --> 35:47.510
Und dann hat der hoffentlich irgendwo einen Stop Button.

35:52.620 --> 35:55.840
Der Walter guckt schon ganz kritisch, der hat nämlich gemeint, das

35:55.840 --> 35:56.800
Ding stürzt auch gerne ab.

35:58.880 --> 36:01.500
Wir werden nachher nochmal zurückkommen auf den Tokenring, der ist ein

36:01.500 --> 36:03.780
bisschen anschaulicher dort dargestellt.

36:11.880 --> 36:17.220
Das im Prinzip zur Funktionsweise Ethernet oder CSMA CD Netze.

36:19.280 --> 36:21.680
Zu Abkürzungen, von denen wir ja genügend haben.

36:22.480 --> 36:24.820
Manchmal hat man die Abkürzung einfach verstanden, wenn man das

36:24.820 --> 36:26.400
Funktionsprinzip verstanden hat.

36:27.740 --> 36:32.400
CSMA CD, Carrier Sense, das bedeutet einfach, dass das Medium abhören.

36:33.040 --> 36:36.060
Multiple Access ist auch klar, es dürfen mehrere drauf zugreifen.

36:36.840 --> 36:40.260
Und Collision Detection ist auch klar, bedeutet nämlich, dass sie die

36:40.260 --> 36:43.560
Kollision erkennen, also dass sie einen Listen-While-Talk machen.

36:44.680 --> 36:49.540
Es gibt zwei unterschiedliche Verfahren, einmal den IEEE-Standard 802

36:49.540 --> 36:52.020
.3 und zum anderen das Ethernet.

36:52.320 --> 36:54.580
Einfach aus zwei unterschiedlichen Richtungen entstanden.

36:55.060 --> 36:59.540
Bob Metcalf hat bei Xerox PARC das Ethernet an sich entwickelt.

37:00.020 --> 37:03.320
Im IEEE-Standardisierungsgremium ist es ein bisschen abgewandelt dann

37:03.320 --> 37:06.280
als CSMA CD standardisiert worden.

37:07.360 --> 37:11.520
Das ist übrigens auch eine schöne Sache, mit der man viel Geld

37:11.520 --> 37:12.860
verdienen konnte.

37:13.560 --> 37:14.600
Oder auch noch kann.

37:14.700 --> 37:19.020
Bob Metcalf, der das Ethernet entwickelt hat, hat dann die Firma 3Com

37:19.020 --> 37:22.280
ausgebaut und die ist wahrscheinlich jedem irgendwo ein Begriff.

37:24.060 --> 37:27.200
Es gibt jetzt unterschiedliche Realisierungen der Technik, das hatte

37:27.200 --> 37:28.060
ich vorhin schon gesagt.

37:28.180 --> 37:30.640
Einmal das grundsätzliche Medienzuteilungsverfahren und jetzt können

37:30.640 --> 37:34.200
wir alle möglichen unterschiedlichen physikalischen Medien darunter

37:34.200 --> 37:35.800
verwenden.

37:36.100 --> 37:39.700
Zum einen das dicke Coax, das gelbe, was ich dabei hatte letzte Woche.

37:39.700 --> 37:42.340
Das ziemlich unpraktisch ist, weil Sie mit dem kaum um die Ecken

37:42.340 --> 37:44.540
umkommen, weil es sich schon kaum biegen lässt.

37:45.480 --> 37:50.580
Typischerweise dann eher im Einsatz des dünnen Coax-Kabels, was den

37:50.580 --> 37:53.860
Vorteil hat, dass es wesentlich flexibler ist, aber gleich mit dem

37:53.860 --> 37:57.120
Nachteil einhergeht, eine geringere Distanz nur überwinden kann.

37:57.840 --> 38:01.520
Das heißt, Sie haben pro solchen Segment eine bestimmte Länge dieser

38:01.520 --> 38:02.560
Maxima haben können.

38:03.180 --> 38:05.940
Wenn Sie ein größeres Netz aufbauen, müssen Sie einen Signalverstärker

38:05.940 --> 38:08.600
dazwischen setzen und das nächste Segment wieder dran.

38:08.600 --> 38:11.420
Und auch da gibt es nachher eine gewisse Anzahl an Segmenten, die Sie

38:11.420 --> 38:15.140
maximal miteinander verbinden können.

38:15.920 --> 38:19.360
Dann gibt es verdrillte Adern, das was eigentlich heute mehr oder

38:19.360 --> 38:21.520
weniger Standard im Einsatz ist, und Glasfaser.

38:21.720 --> 38:24.180
Glasfaser hat wieder den wunderschönen Vorteil, Sie können über viel

38:24.180 --> 38:25.180
größere Distanzen gehen.

38:25.700 --> 38:27.300
Hat den kleinen Nachteil, es ist ein bisschen teurer.

38:31.400 --> 38:34.280
Realisierung, da will ich gar nicht so lange drauf eingehen.

38:34.280 --> 38:39.880
Sie haben im Prinzip hier dieses Yellow Cable, haben die Medium

38:39.880 --> 38:42.960
Attachment Unit, mit der Sie da drankommen können.

38:43.700 --> 38:46.960
Das Attachment Unit Interface, was im Prinzip ein Stecker ist, und

38:46.960 --> 38:52.520
hier haben Sie den gegenteiligen Stecker, den Sie an Ihrem Kabel dran

38:52.520 --> 38:52.900
haben.

38:53.720 --> 38:58.580
Einmal hier das Netzkabel und hier dran hängen dann der Rechner, der

38:58.580 --> 38:59.760
eben kommunizieren will.

38:59.760 --> 39:06.680
Und damit dann verschiedene technische Sachen, die ins Spiel kommen.

39:06.780 --> 39:10.060
Bei der Technik können Sie zum Beispiel maximal 5 Segmente miteinander

39:10.060 --> 39:13.820
kuppeln, dann sind Sie am Ende mit Ihrer Netzgröße.

39:14.260 --> 39:18.500
Sie haben eine relativ geringe Bitfehlerrate und man verwendet

39:18.500 --> 39:21.500
Manchester -Kodierung, das haben wir schon mal gesehen letzte Woche.

39:22.440 --> 39:28.500
Das ist eben die Tatsache, wenn Sie 0, 1, 1, 0, 1 kodieren wollen,

39:29.620 --> 39:33.020
dann haben Sie hier jeweils die Taktraster, in denen Sie das machen.

39:34.540 --> 39:39.100
Und die Idee, die da dahinter lag, Sie betrachten jeweils die Flanken

39:39.100 --> 39:45.460
innerhalb in der Bitmitte, um zu erkennen, ob es ein 0er oder 1er ist.

39:45.460 --> 39:49.800
Und Sie müssen dann eben hier an den Bit-Takt-Grenzen Hilfswechsel

39:49.800 --> 39:53.780
einfügen, wenn Sie aufeinander folgende 1er oder 0er haben.

39:57.000 --> 39:59.700
Ja, hier ist ein Beispiel für 10Base2, einfach nochmal bildlich

39:59.700 --> 40:03.940
dargestellt, wo man hier das Kabel sieht, den Stecker, die Einheit,

40:04.060 --> 40:06.340
mit der Sie das Ganze ins Netz reinstöpseln.

40:07.120 --> 40:10.520
Und die Übung früher war eben, bin ich schnell genug, um das da

40:10.520 --> 40:13.520
reinzukriegen, bevor das Netz zusammenbricht, oder merkt das das

40:13.520 --> 40:15.360
Admin, dass ich gerade was reingestöpselt habe.

40:16.220 --> 40:18.780
Man kriegt es rein, wenn man schnell genug ist und weiß, wie man damit

40:18.780 --> 40:19.120
umgeht.

40:21.000 --> 40:27.180
Ja, hier sehen Sie so einen Aufbau, wo eben mehrere Geräte

40:27.180 --> 40:30.420
übereinander stehen, jeweils hier an das Ethernet angeschlossen.

40:31.460 --> 40:33.260
Und hier so ein Bildchen von so einem Transceiver.

40:35.420 --> 40:38.940
Ja, das Ganze nochmal mit Twisted Pair, so wie es heute aussieht.

40:39.100 --> 40:43.380
Ich glaube, das ist ein Bild aus unserem Verteilerschrank oben im

40:43.380 --> 40:45.280
dritten Stock, älteren Datums.

40:45.420 --> 40:48.320
Da sehen Sie nämlich noch jede Menge gelber Kabel hier drin.

40:48.400 --> 40:50.140
Inzwischen sind wir auf die Idee gekommen, zumindest mal

40:50.140 --> 40:52.960
unterschiedliche Farben zu benutzen, um rauszukriegen, ob das jetzt

40:52.960 --> 40:56.620
Leitungen sind, die bei uns oben Versorgung machen oder Versorgung im

40:56.620 --> 40:58.500
Mattebau oder Versorgung in der Engeser Straße.

40:59.840 --> 41:02.680
Was es Ihnen aber vielleicht zeigt, wir sind zwar kein kleines

41:02.680 --> 41:04.900
Institut, aber auch nicht wirklich richtig groß.

41:05.020 --> 41:08.000
Ich schätze, wir haben, was weiß ich, so 150 Komponenten am Netz

41:08.000 --> 41:09.620
hängen, in der Richtung.

41:10.600 --> 41:12.620
Da kommt einfach schon was an Kabeln zusammen.

41:13.100 --> 41:14.240
Das sind die dünnen Verdrillten.

41:14.840 --> 41:16.540
Stellen Sie sich das mal vor mit den Coax-Kabeln.

41:18.480 --> 41:21.200
Und stellen Sie sich das mal vor, wie das bei einem Rechenzentrum

41:21.200 --> 41:23.220
nachher aussieht, wie 1&1 oder sowas.

41:24.720 --> 41:27.260
Die lächeln müde über so einen kleinen Kabelstrang hier.

41:30.080 --> 41:35.720
Das ursprüngliche Ethernet für 10 Megabit ausgerichtet, das war Anfang

41:35.720 --> 41:37.480
der 80er Jahre eine Riesendatenrate.

41:37.700 --> 41:38.480
Boah, war das schnell.

41:39.400 --> 41:42.260
Inzwischen auch nur noch ein müdes Lächeln für 10 Megabit.

41:42.340 --> 41:45.820
Heute hat man 100 Megabit in der Regel Fast Ethernet oder Gigabit

41:45.820 --> 41:47.760
Ethernet, zumindest teilweise.

41:51.740 --> 41:55.220
Das Verfahren an sich hat sich im Prinzip nicht geändert, sondern man

41:55.220 --> 41:59.000
hat auch wieder eine schnellere Technik einfach unten drunter gesetzt.

42:00.800 --> 42:03.380
Was den Vorteil hat, dass Sie oben drüber nichts ändern müssen.

42:04.360 --> 42:06.300
Das ist ja auch immer eine Frage, wenn Sie irgendwo in diesem

42:06.300 --> 42:10.460
Kommunikationsdeck, vor allem relativ weit unten, was ändern, wollen

42:10.460 --> 42:13.620
Sie tunlichst vermeiden, dass es irgendjemand oben merkt, außer dass

42:13.620 --> 42:15.220
es vielleicht besser geworden ist, weil es schneller ist.

42:15.740 --> 42:18.240
Aber Sie wollen nicht alle Software oben wieder neu strecken.

42:19.920 --> 42:24.760
Jemand eine Idee, was für ein Problem das mit sich bringt, wenn ich

42:24.760 --> 42:30.380
jetzt von 10 auf 100 Megabit springe und das Medienzugriffsverfahren

42:30.380 --> 42:31.060
nicht ändere.

42:31.880 --> 42:35.020
Und auch das Format der Dateneinheiten nicht ändere.

42:36.400 --> 42:38.500
Denn sobald ich das Format ändere, hat das ja auch wieder

42:38.500 --> 42:39.140
Auswirkungen.

42:46.930 --> 42:48.970
Oder geht das aus Ihrer Sicht jetzt gerade ganz problemlos?

42:54.900 --> 42:56.680
Ich blätter nochmal, blätter ich zurück?

42:56.920 --> 42:56.920
Ja.

42:59.640 --> 43:02.040
Das, was hier vorhin unterstrichen, jetzt hier inzwischen

43:02.040 --> 43:07.440
durchgestrichen ist, wir haben noch so ein sogenanntes Stoppffeld eben

43:07.440 --> 43:09.380
vorhin diskutiert, das wir eingeführt haben.

43:10.780 --> 43:14.460
Damit die Station gesichert noch am Senden ist, wenn sie eine

43:14.460 --> 43:15.540
Kollision erkennen kann.

43:17.980 --> 43:22.420
Jetzt haben Sie natürlich das Problem, höhere Datenrate, flupp ist

43:22.420 --> 43:23.540
auch die Dateneinheit schneller weg.

43:25.220 --> 43:29.520
Also haben Sie welche Möglichkeiten, darauf zu reagieren, um das

43:29.520 --> 43:32.460
Verfahren immer noch anwenden zu können?

43:36.100 --> 43:38.000
Mindestlänge erhöhen, eine Möglichkeit.

43:38.500 --> 43:39.080
Andere Möglichkeit?

43:44.580 --> 43:44.720
Bitte?

43:46.280 --> 43:48.080
Kabel kürzen, genau.

43:49.320 --> 43:51.380
Das sind die Parameter, an denen Sie schrauben können.

43:51.380 --> 43:56.980
Hier hat man bei 100 Megabit die Dateneinheit nicht verlängert, also

43:56.980 --> 43:58.380
hat man die Distanz verringert.

43:59.060 --> 44:02.720
Das kann man natürlich nur in einem gewissen Umfang machen, wenn man

44:02.720 --> 44:05.520
noch wirklich ein praktikables Netz haben will.

44:07.160 --> 44:10.920
Nächste Geschichte, Gigabit, wieder das gleiche Problem, wenn ich das

44:10.920 --> 44:12.120
gleiche Verfahren haben will.

44:12.420 --> 44:16.500
Ich kann entweder die Datenlänge größer machen oder ich kann das Kabel

44:16.500 --> 44:17.200
kürzer machen.

44:17.200 --> 44:20.960
Wenn man da das Kabel noch mal kürzer gemacht hätte, dann würde man

44:20.960 --> 44:23.260
wirklich Schwierigkeiten kriegen, ein vernünftiges Netz aufzubauen.

44:24.360 --> 44:28.800
Also hat man hier angefangen, die Datenlänge zu erhöhen, nämlich von

44:28.800 --> 44:32.040
64 Byte Mindestlänge auf 512 Byte Mindestlänge.

44:32.900 --> 44:36.260
Ist natürlich jetzt dumm, weil man will ja auch mit dem anderen

44:36.260 --> 44:38.120
Equipment irgendwie noch kompatibel sein.

44:38.940 --> 44:42.980
Man hat also nicht wirklich die Dateneinheit an sich geändert, sondern

44:42.980 --> 44:45.780
man füllt auf, und zwar wenn die Dateneinheit fertig ist an sich

44:45.780 --> 44:50.180
schon, mit einer Reihe von Füllzeichen, die ohne jegliche Bedeutung

44:50.180 --> 44:50.380
sind.

44:51.840 --> 44:55.180
Was man auch machen kann, man kann eine Station direkt hintereinander

44:55.180 --> 45:00.620
mehrere Daten schicken lassen, die direkt hintereinander kleben, damit

45:00.620 --> 45:04.020
der Bereich nicht wirklich ungenutzt ist.

45:04.220 --> 45:06.440
Geht natürlich nur, wenn die Station auch wirklich mehr Daten zu

45:06.440 --> 45:06.900
schicken hat.

45:08.300 --> 45:11.660
Dadurch hat man aber wiederum vermieden, dass man sozusagen die ganze

45:11.660 --> 45:14.680
Welt ändern muss, weil der Rest kann schön mit seinen 64 Byte

45:14.680 --> 45:19.720
Dateneinheiten noch arbeiten, und die, die eben Gigabit können, müssen

45:19.720 --> 45:24.700
dann zu solchen Sachen greifen, wie eben auffüllen von Dateneinheiten

45:24.700 --> 45:25.160
und sowas.

45:26.480 --> 45:29.880
Ist eine ganz wichtige Sache, Rückwärtskompatibilität.

45:31.480 --> 45:35.060
Die muss gewährleistet sein, weil Sie können heute in der globalen

45:35.060 --> 45:38.000
Vernetzung nicht einfach mal irgendwo sagen, schwupp, ich ändere da

45:38.000 --> 45:40.420
was und jetzt muss die ganze Welt geändert werden.

45:41.140 --> 45:43.160
Das ging übrigens vor 20 Jahren noch.

45:44.640 --> 45:49.100
Im Jahreswechsel, 20 Jahre zurück, hat man auf den Knopf gedrückt und

45:49.100 --> 45:51.540
hat gesagt, ab heute müssen alle Rechner TCP reden.

45:52.640 --> 45:54.760
Stellen Sie sich das mal jetzt vor, wenn Sie das machen würden.

45:55.460 --> 45:59.020
Es ist faktisch unmöglich, sowas nochmal zu machen.

46:00.860 --> 46:06.400
So, Ethernet, also ein Verfahren mit unkontrolliertem Zugriff, und man

46:06.400 --> 46:08.520
kann sich durchaus ein bisschen wundern, wieso funktioniert es

46:08.520 --> 46:09.200
eigentlich so gut.

46:09.760 --> 46:14.360
Wenn Sie so ein Netz haben, wo Sie im Prinzip einen Wettbewerb haben,

46:15.080 --> 46:18.380
und im Prinzip auch zufällig ist, wer gerade drankommt.

46:19.040 --> 46:21.720
Im schlimmsten Fall könnte es Ihnen ja passieren, dass Sie gar nicht

46:21.720 --> 46:22.340
zum Zuge kommen.

46:23.340 --> 46:26.880
Nämlich, dass das Medium immer belegt ist, wenn Sie darauf hören, oder

46:26.880 --> 46:29.960
dass, wenn Sie es mal frei erkennen, just auch irgendjemand anders

46:29.960 --> 46:31.520
kommt, und meint, der dürfte da senden.

46:33.020 --> 46:34.440
Ist das eine Idee, wieso das überhaupt funktioniert?

46:40.880 --> 46:44.480
Oder finden Sie das natürlich, dass etwas, wo jeder im freien

46:44.480 --> 46:46.260
Wettbewerb drauf losgelassen wird, funktioniert?

46:55.660 --> 47:00.180
Der Trick der Sache daran ist, dass Sie überhaupt nie die Datenrate,

47:00.180 --> 47:01.940
die unten dran angeboten wird, vollbrauchen.

47:02.160 --> 47:03.460
Oder in den allerseltensten Fällen.

47:04.280 --> 47:07.020
Das heißt, Sie haben im Prinzip schlicht und einfach ein Over

47:07.020 --> 47:11.300
-Provisioning, das heißt, mehr Datenrate, als Sie überhaupt benötigen,

47:11.300 --> 47:15.420
und dadurch haben Sie im Regelfall einen Betrieb, wo relativ wenig

47:15.420 --> 47:16.300
Kollisionen auftreten.

47:17.280 --> 47:20.060
Manche Adapter zeigen einem, oder Hubs, die zeigen einem das ja

47:20.060 --> 47:22.740
wunderschön an, durch gelbe und rote Lichter, müssen wir mal drauf

47:22.740 --> 47:25.660
gucken, es gibt eigentlich relativ wenig Kollisionen.

47:26.520 --> 47:30.520
Die Auslastung, bis zu der man maximal gehen kann, liegt irgendwo bei

47:30.520 --> 47:34.100
knapp unter 80% dessen, was angeboten wird.

47:37.220 --> 47:40.520
Und wenn Sie ein Gigabit Ethernet haben, ist Ihnen klar, das kriegen

47:40.520 --> 47:42.060
Sie gar nicht aus dem Rechner raus, das Gigabit.

47:42.560 --> 47:43.740
Das können Sie gar nicht benutzen.

47:45.120 --> 47:49.560
Aber es funktioniert eben genau deshalb so gut, obwohl Sie mehrere

47:49.560 --> 47:51.900
Benutzer dran haben, weil Sie ein Over-Provisioning haben.

47:53.360 --> 47:55.860
Viel geregelter, viel schöner, Token Ring.

47:57.240 --> 48:00.860
Da haben Sie einen kontrollierten Zugriff, da wird festgelegt, wer,

48:01.040 --> 48:02.240
wann und wie lange senden darf.

48:03.120 --> 48:05.320
Für solche Geschichten, wo Sie z.B.

48:05.620 --> 48:09.420
Multimedia-Daten drüber schicken wollen, eigentlich, zumindest

48:09.420 --> 48:11.920
theoretisch, das ist ein sehr viel schöneres Netz.

48:12.800 --> 48:17.560
Weil Sie können tatsächlich Grenzen angeben, wann Sie gesichert wieder

48:17.560 --> 48:20.320
zum Senden kommen, und wie viel Daten Sie dann auch wirklich senden

48:20.320 --> 48:20.600
dürfen.

48:21.260 --> 48:22.560
Das ist bei Ethernet nicht der Fall.

48:22.660 --> 48:24.900
Sie können keinem garantieren, dass der jemals zum Senden kommt.

48:25.520 --> 48:27.340
In der Regel funktioniert es dann trotzdem.

48:28.620 --> 48:29.420
Was ist der Unterschied?

48:30.260 --> 48:33.980
Sie haben hier jetzt Stationen, die aktiv in die Kommunikation

48:33.980 --> 48:39.020
involviert sind, und die per Punkt zu Punkt einen Ring formen, so wie

48:39.020 --> 48:40.960
wir es vorhin auf dem Topologie-Bild gesehen haben.

48:42.600 --> 48:47.340
Damit haben Sie als Station immer definiert einen Vorgänger, von dem

48:47.340 --> 48:49.780
Sie die Daten bekommen, und einen Nachfolger, an den Sie die Daten

48:49.780 --> 48:50.040
schicken.

48:51.480 --> 48:55.740
Sie sind aktiv in die Kommunikation involviert, heißt, alle Bits, die

48:55.740 --> 48:59.820
auf dem Ring gesendet werden, laufen tatsächlich durch Ihre Station

48:59.820 --> 49:04.020
und werden dort wieder verstärkt, was den Vorteil hat, Sie können

49:04.020 --> 49:05.240
größere Distanzen überbrücken.

49:05.860 --> 49:10.040
Auch schöner als bei Ethernet, weil da jeder nur passiv hört, keiner

49:10.040 --> 49:12.160
das Signal verstärkt, und deswegen brauchen Sie die

49:12.160 --> 49:14.760
Signalregeneratoren, um verschiedene Segmente miteinander zu

49:14.760 --> 49:15.120
verbinden.

49:16.840 --> 49:21.200
Dann haben Sie einen sogenannten Token, der wird einfach von Station

49:21.200 --> 49:26.620
zu Station weitergegeben, und der gibt der Station sozusagen das

49:26.620 --> 49:27.100
Senderecht.

49:27.760 --> 49:29.440
Das heißt, wenn ich den Token habe, dann darf ich senden.

49:31.620 --> 49:34.600
Wenn ich nicht mehr senden darf, muss ich den Token weitergeben, an

49:34.600 --> 49:35.260
die nächste Station.

49:40.580 --> 49:43.820
Typischerweise kriege ich so einen Token, also die Netze der ersten

49:43.820 --> 49:49.280
Generation, und das ist der Basistokenring mit IEEE 800 2.5, sind so

49:49.280 --> 49:52.080
designt gewesen, dass ich genau einen Token habe, und der läuft immer

49:52.080 --> 49:52.680
durch das Medium.

49:52.680 --> 49:56.800
Das heißt, ich nehme mir den Token, wenn ich ihn kriege, sende, wenn

49:56.800 --> 49:59.600
die Daten wieder zu mir zurückgekommen sind, müssen sie ja, weil ich

49:59.600 --> 50:03.120
einen Ring habe, dann gebe ich das Token weiter an die nächste

50:03.120 --> 50:05.460
Station, damit die den Ring benutzen darf.

50:08.720 --> 50:13.260
Das klingt alles wunderschön geregelt, und genau daran ist das

50:13.260 --> 50:13.600
Problem.

50:14.300 --> 50:19.360
Das ist ein sehr schönes Konzept, mit dem ich relativ gut sagen kann,

50:20.020 --> 50:23.380
was passiert, wer kriegt welche Datenrate, wer kriegt welchen Dienst

50:23.380 --> 50:27.220
sozusagen angeboten, wenn man jetzt mal Verzögerung beim Zugriff als

50:27.220 --> 50:31.840
Dienstqualitätsparameter nimmt, aber ich muss das Ganze managen, weil

50:31.840 --> 50:36.280
wenn einer den Token verliert, kann keiner mehr kommunizieren.

50:37.640 --> 50:40.340
Wenn einer clever ist und sagt, ich warte nicht, bis so ein Token

50:40.340 --> 50:44.120
kommt, ich produziere mir meinen eigenen Token, funktioniert es auch

50:44.120 --> 50:44.780
nicht mehr wirklich.

50:45.480 --> 50:49.420
Das heißt, ich muss das gesamte System dahingehend überwachen, dass

50:49.420 --> 50:51.100
das Tokenhandling korrekt funktioniert.

50:52.100 --> 50:55.460
Das bedeutet, ich habe ein relativ schönes Protokoll zum

50:55.460 --> 50:58.060
Datenübertragen, und ich habe einen riesen Overhead, um das zu

50:58.060 --> 50:58.340
managen.

50:59.300 --> 51:04.360
Und das ist eigentlich auch der Knackpunkt, an dem der Tokenring

51:04.360 --> 51:06.260
letztendlich irgendwo gescheitert ist.

51:07.000 --> 51:09.240
Es ist viel zu komplex, um das vernünftig zu managen.

51:10.660 --> 51:14.280
Immer wieder interessant ist die Tatsache, wenn man auf Tagungen geht,

51:15.300 --> 51:18.760
ist mir letztes Jahr irgendwann mal passiert, war ich eben auch bei

51:18.760 --> 51:22.880
einer Tagung, hat jemand ein Softwareprotokoll vorgestellt, das

51:22.880 --> 51:28.100
wunderschön geregelt war, des Tokens hatte, um Kommunikation zu

51:28.100 --> 51:30.580
regeln, und dann war der fertig.

51:32.140 --> 51:35.160
Ich meine, es war klar, als der anfing mit seinem Vortrag, dass eine

51:35.160 --> 51:36.780
Frage am Ende auf jeden Fall kommen muss.

51:37.800 --> 51:40.080
Ob er einen Tokenring kennt und weiß, wie der funktioniert.

51:41.280 --> 51:44.060
Weil der hat es schlicht und einfach davon abstrahiert, dass das ganze

51:44.060 --> 51:46.840
Management des Tokens eine komplexe Sache ist.

51:48.500 --> 51:49.920
Das muss einem aber klar sein.

51:50.280 --> 51:53.540
Das ist übrigens auch ein Grund, wieso Sie in manchen von unseren

51:53.540 --> 51:57.500
Vorlesungen alte, in Anführungszeichen, alte Technologie vorgesetzt

51:57.500 --> 51:57.860
kriegen.

51:59.240 --> 52:02.400
Um nämlich tatsächlich mal ein bisschen dran zu hören, wieso ist die

52:02.400 --> 52:03.160
eigentlich gescheitert.

52:03.920 --> 52:06.900
Und um vielleicht dann in Zukunft nicht wieder das gleiche zu

52:06.900 --> 52:09.720
entwickeln, von dem Sie eigentlich schon wissen müssten, dass es

52:09.720 --> 52:10.500
scheitern muss.

52:11.060 --> 52:12.460
Weil es viel zu komplex wird.

52:14.440 --> 52:19.860
Okay, wie ist der Ablauf bei dem Tokenring hier an dem Beispiel

52:19.860 --> 52:20.480
dargestellt?

52:20.620 --> 52:24.840
Zunächst nochmal eben die Tatsache hier, jede Station ist aktiv an dem

52:24.840 --> 52:25.240
Ring dran.

52:25.360 --> 52:28.240
Das heißt, alle Bits gehen hier rein, gehen hier raus.

52:29.840 --> 52:36.920
Bedeutet natürlich auch, was nicht passieren darf, ist, wenn so eine

52:36.920 --> 52:39.580
Station ausgeschaltet wird, dass dann der Ring nicht mehr

52:39.580 --> 52:39.980
funktioniert.

52:42.140 --> 52:44.520
Deswegen hat man, wie ich es vorhin schon angedeutet habe, in der

52:44.520 --> 52:49.740
Regel in der Mitte so einen zentralen Ringverteiler, an den die ganzen

52:49.740 --> 52:52.560
Kabel hier rangehen.

52:53.540 --> 52:56.360
Und in dem ist normalerweise hier einfach ein Relais drin.

52:57.320 --> 53:01.760
Wenn so eine Station sich abschaltet, dann klappt das Relais zu und

53:01.760 --> 53:03.060
damit ist die Verbindung wieder gesichert.

53:04.180 --> 53:07.380
Wenn Sie sich den alten Tokenring-Ringverteiler angucken, ich glaube,

53:07.460 --> 53:09.900
wir haben im Keller tatsächlich noch welche stehen, das ist

53:09.900 --> 53:12.020
wunderschön, wenn Sie eine Station einschalten, dann macht es mal

53:12.020 --> 53:16.320
klick, klick, klick, klick, wenn Sie wieder rausgehen, weil da einfach

53:16.320 --> 53:19.420
plumpe Relais innen drin sitzen.

53:20.360 --> 53:21.800
Okay, wie geht es jetzt mit dem Token?

53:22.320 --> 53:28.080
Der Token an sich ist auch ein normales Paket, mit einer besonderen

53:28.080 --> 53:28.800
Struktur eben.

53:28.800 --> 53:32.540
Der wird jetzt hier übers Netz gesendet, kommt zur Station A.

53:33.620 --> 53:37.320
Station A hat einen Sendewunsch, die muss das Token also jetzt

53:37.320 --> 53:42.400
irgendwie markieren, in dem Fall hier blau dargestellt, um zu zeigen,

53:42.500 --> 53:44.660
das ist jetzt belegt.

53:45.800 --> 53:49.820
Hinten dran werden die Daten geschickt und die Station will jetzt

53:49.820 --> 53:51.720
Daten an die Station C schicken.

53:54.100 --> 53:58.060
Die Daten durchlaufen hier die Station B, die gehen also auch hier

53:58.060 --> 53:58.340
rein.

53:58.800 --> 54:02.940
Immer mit einem Bit Verzögerung, hier wieder raus, dann gehen sie hier

54:02.940 --> 54:06.460
rein, hier rein, hier wieder raus.

54:07.840 --> 54:10.540
Station C stellt irgendwann fest, das sind ihre eigenen Daten, die

54:10.540 --> 54:14.620
kopiert sie sich also im Speicher rein, sendet die Daten aber wieder

54:14.620 --> 54:21.060
weiter, die Daten kommen letztendlich bei A an und werden dort wieder

54:21.060 --> 54:21.720
vom Ring genommen.

54:23.200 --> 54:27.580
Ganz klar ist, so ein Ringmanagement muss erkennen, wenn die Station A

54:27.580 --> 54:31.100
ausgefallen ist, und ihre Daten nicht mehr vom Netz nehmen kann, dann

54:31.100 --> 54:32.300
würden die ja einfach weiter kreisen.

54:33.200 --> 54:36.420
Das muss sie irgendwie erkennen, sonst wäre der Ring ja einfach belegt

54:36.420 --> 54:37.780
und man könnte nicht weiter kommunizieren.

54:38.120 --> 54:41.240
Das sind lauter so Sachen, die man bei so einer Struktur behandeln

54:41.240 --> 54:41.460
muss.

54:42.740 --> 54:46.520
Jetzt kann man sich natürlich noch fragen, wieso werden die Daten denn

54:46.520 --> 54:47.760
hier überhaupt weiter gesendet?

54:49.780 --> 54:51.040
Die Station hat sie ja.

54:52.940 --> 54:55.980
D braucht sie nicht, weil sie da nicht adressiert sind und A hat sie

54:55.980 --> 54:57.640
eigentlich sowieso, da brauche ich sie auch nicht wieder

54:57.640 --> 54:58.140
zurückschicken.

54:59.500 --> 55:01.560
Wieso schickt die Station die Daten weiter?

55:02.280 --> 55:05.360
Das können wir erst gleich klären, wenn wir mal ein bisschen auf die

55:05.360 --> 55:06.260
Datenformate schauen.

55:07.040 --> 55:10.540
Also behalten Sie das Problem nochmal im Hinterkopf, das wird gleich

55:10.540 --> 55:11.600
irgendwo geklärt.

55:15.940 --> 55:21.400
Gehen wir vielleicht tatsächlich mal ein Stück weiter, bei HTLC kommen

55:21.400 --> 55:25.020
wir gleich nochmal zurück, zu der Strukturierung der Datenübertragung.

55:25.020 --> 55:28.420
Denn das braucht man jetzt, um genau dieses Problem bei Token Ring in

55:28.420 --> 55:29.040
den Griff zu kriegen.

55:29.660 --> 55:34.660
Wir haben jetzt ja erstmal darüber geredet, wie ich kontrolliere, wer

55:34.660 --> 55:35.420
senden darf.

55:36.640 --> 55:38.960
Und jetzt muss ich mir ja überlegen, wie baue ich denn so eine

55:38.960 --> 55:42.660
Dateneinheit auf, damit ich alle Informationen drin habe, die ich

55:42.660 --> 55:46.220
brauche, und die Protokollinstanz beim Empfänger damit auch vernünftig

55:46.220 --> 55:47.000
was anfangen kann.

55:49.080 --> 55:53.280
Deswegen werden wir uns hier jetzt beispielhaft die Datenformate von

55:53.280 --> 55:55.800
Ethernet, von Token Ring und von HTLC anschauen.

55:58.160 --> 56:01.700
Und da kommt immer gleich das Stöhnen, müssen wir die alle auswendig

56:01.700 --> 56:01.960
lernen?

56:03.420 --> 56:05.380
Die braucht man gar nicht auswendig lernen, da kann man sich einfach

56:05.380 --> 56:07.160
mal überlegen, was muss denn drinstehen?

56:11.270 --> 56:16.530
Sie haben hier den Bus, Sie haben hier meinetwegen Station A, da eine

56:16.530 --> 56:20.410
ganze Reihe anderer Stationen und hier meinetwegen B.

56:23.990 --> 56:26.250
Situation A will Daten an B senden.

56:28.730 --> 56:33.790
Und die sollen irgendwie dann auch möglichst korrekt ankommen und das

56:33.790 --> 56:34.990
soll B überprüfen können.

56:36.610 --> 56:39.470
Da haben wir eigentlich eine Sache schon mal, die ziemlich natürlich

56:39.470 --> 56:42.050
hier anwendbar ist, die wir gestern diskutiert haben.

56:43.330 --> 56:44.670
Wir haben über Prüfsummen geredet.

56:45.470 --> 56:48.670
Prüfsummen, die werden wir irgendwo unten im Protokoll-Stack sehen, da

56:48.670 --> 56:50.410
wo man typischerweise auch in Hardware ist.

56:51.750 --> 56:55.030
Schicht 2a und Schicht 1, das haben Sie immer in Hardware

56:55.030 --> 56:55.970
implementiert in der Regel.

56:57.850 --> 57:01.590
Also bietet es sich doch da an, eine Prüfsumme zu nehmen, CAC oder

57:01.590 --> 57:05.470
hier als Frame Check Sequence bezeichnet, die Sie irgendwie hinten an

57:05.470 --> 57:06.370
die Daten dranhängen.

57:07.510 --> 57:09.950
Und die müssen hinten dranhängen, weil Sie einfach das ganze durch

57:09.950 --> 57:12.630
Schieberegister durchlaufen lassen und damit, wenn die ganzen Bits

57:12.630 --> 57:15.470
durchgelaufen sind, hinten einfach fertig Ihre Prüfsumme haben.

57:16.730 --> 57:20.650
Das ist also schon mal eine Sache, die man typischerweise verwenden

57:20.650 --> 57:25.350
wird hier, damit die Station B nachher rauskriegen kann, sind denn da

57:25.350 --> 57:26.110
Bitfehler passiert.

57:27.690 --> 57:28.830
Also braucht man sowas.

57:30.150 --> 57:34.490
Dann hatten wir uns eben schon überlegt bei CSMA CD, wir brauchen eine

57:34.490 --> 57:35.330
Mindestpaketlänge.

57:36.350 --> 57:39.410
Wenn die Nutzdaten nicht lang genug sind, weil meinetwegen per Telnet

57:39.410 --> 57:43.250
einfach nur ein Byte verschickt wird, ja, dann brauchen wir sowas wie

57:43.250 --> 57:44.770
ein Paddingfeld, mit dem wir halt auffüllen.

57:47.570 --> 57:49.490
So, dann haben wir Daten, die wir übertragen wollen.

57:50.450 --> 57:52.390
Das wäre sinnvoll, wenn wir die irgendwo in die Dateneinheit

57:52.390 --> 57:52.850
reinpacken.

57:53.490 --> 57:57.230
Das ist das, was jetzt von der Schicht 3 an die Schicht 2 übergeben

57:57.230 --> 57:57.470
wird.

58:00.010 --> 58:02.770
Und die wird man irgendwo begrenzen in der Länge, auch das ist wieder

58:02.770 --> 58:06.950
klar, weil je länger die sind, je größer steigt die

58:06.950 --> 58:09.450
Wahrscheinlichkeit, dass sie einen Bitfehler drin haben.

58:10.010 --> 58:13.450
Und dann müssen wir den ganzen Schlamassel nochmal wieder versenden.

58:14.570 --> 58:18.170
Wenn sie das zu kurz machen, ist auch klar, dann haben sie viel andere

58:18.170 --> 58:20.870
Daten, die sie senden, im Vergleich zu den Nutzdaten, als einen großen

58:20.870 --> 58:21.330
Overhead.

58:23.650 --> 58:26.910
Also gibt es irgendwo bestimmte Längenbegrenzungen.

58:28.150 --> 58:33.250
So, dann, ja, habe ich gesagt, A will an B senden.

58:34.150 --> 58:38.030
Und jetzt hängen hier ja jede Menge Stationen dran, die sich das Netz

58:38.030 --> 58:38.410
anhören.

58:38.410 --> 58:40.910
Die gucken, was auf dem Netz passiert.

58:42.770 --> 58:48.270
So eine Station weiß ja nur, ob die Daten für sie gedacht sind oder

58:48.270 --> 58:50.540
nicht, wenn irgend so etwas wie eine Adresse draufsteht.

58:51.850 --> 58:54.330
Wenn sie einen Brief kriegen, im Briefkasten, dann gucken sie auch auf

58:54.330 --> 58:55.630
die Adresse und sehen, ja, der ist für mich.

58:56.150 --> 58:58.290
Oder Mist, da hat der Briefträger mal wieder den vom Nachbarn bei mir

58:58.290 --> 58:58.790
reingeschmissen.

59:00.530 --> 59:05.010
Also brauchen wir auch hier so etwas wie Adressen, und zwar einmal vom

59:05.010 --> 59:07.990
Ziel B und einmal von der Quelle A.

59:08.410 --> 59:10.010
Das sind die beiden Felder, die hier drin sind.

59:11.090 --> 59:13.070
Destination Adress und die Source Adress.

59:15.190 --> 59:17.970
Das kann man sich auch relativ leicht herleiten, dass die in der

59:17.970 --> 59:22.990
Reihenfolge sein sollten, weil das Ziel analysiert ja den Datenstrom

59:22.990 --> 59:26.470
und da wäre es vernünftig, wenn man den Anfang angucken muss, um

59:26.470 --> 59:28.590
rauszukriegen, die sind für mich oder nicht.

59:30.710 --> 59:33.990
So, dann haben wir noch ein Problem zu lösen.

59:35.030 --> 59:36.450
Auch darüber hatten wir schon gesprochen.

59:36.970 --> 59:39.970
Sie haben jetzt das Kabel, dahinten kommen die Bits raus.

59:40.590 --> 59:42.650
Wie kriegen Sie denn raus, dass jetzt eine Dateneinheit anfängt?

59:43.450 --> 59:46.350
Und wie synchronisieren Sie sich auf den gleichen Takt drauf?

59:46.910 --> 59:48.830
Das ist wieder physikalische Geschichte.

59:49.590 --> 59:55.390
Um das zu gewährleisten, gibt es meistens irgendwelche Präambeln vorne

59:55.390 --> 59:58.410
dran, die jetzt schlicht und einfach das Ziel haben, dass die

59:58.410 --> 01:00:03.310
Statistik sich synchronisiert und erkennt einmal, wo ist der Bit

01:00:03.310 --> 01:00:06.730
-Anfang und zum zweiten erkennt, wo ist der Rahmen-Anfang.

01:00:08.450 --> 01:00:13.390
So, dann sind wir fast fertig, weil was wir jetzt noch brauchen,

01:00:13.550 --> 01:00:17.230
irgendwie müssen wir herausfinden, wie lang ist das Ganze denn?

01:00:18.410 --> 01:00:21.870
Denn die Daten hier haben eine Variabellänge.

01:00:24.670 --> 01:00:28.210
Auch das ist wieder logisch, weil wenn Sie eine starre Länge machen,

01:00:28.810 --> 01:00:32.050
Sie wissen ja nie, wie viel der Benutzer eigentlich senden will.

01:00:33.150 --> 01:00:35.270
Entweder ist die Länge zu kurz und Sie brauchen mehr solcher

01:00:35.270 --> 01:00:38.630
Dateneinheiten, oder sie ist zu lang und Sie benutzen nur einen

01:00:38.630 --> 01:00:42.210
kleinen Teil und haben damit wieder einen unnötigen Overhead erzeugt.

01:00:45.450 --> 01:00:49.550
Dann macht man es bei CSM ACD in dem Fall so, dass man hier einfach

01:00:49.550 --> 01:00:53.310
ein Längenfeld angibt und das besagt, wie lang die ganze Geschichte

01:00:53.310 --> 01:00:53.610
ist.

01:00:54.130 --> 01:00:57.870
Dann weiß ich, wann ich am Ende bin, wann ich die Prüfsumme erreicht

01:00:57.870 --> 01:01:02.150
habe, die kann ich überprüfen und weiß, ob das Ganze okay oder nicht

01:01:02.150 --> 01:01:02.630
okay ist.

01:01:04.250 --> 01:01:07.350
Also, relativ einfach sich herzuleiten, was in solchen Dateneinheiten

01:01:07.350 --> 01:01:07.910
drin ist.

01:01:09.070 --> 01:01:13.110
Bei so einfachen wie denen hier, kann man sich fast jedes Feld

01:01:13.110 --> 01:01:13.590
herleiten.

01:01:13.690 --> 01:01:16.310
Es gibt kompliziertere, da gibt es noch Herr Felder, die sind irgendwo

01:01:16.310 --> 01:01:19.270
im Kopf drin, wo man wirklich nicht wissen muss, ob das Feld an

01:01:19.270 --> 01:01:20.910
dritter oder vierter oder fünfter Stelle ist.

01:01:21.630 --> 01:01:23.010
Das guckt man nach, wenn man es implementiert.

01:01:31.520 --> 01:01:34.480
Gute Frage, hier haben wir noch eine Variabilität drin, da gibt es

01:01:34.480 --> 01:01:35.780
zwei verschiedene Adressen.

01:01:37.420 --> 01:01:40.400
Auf die Struktur will ich jetzt weiter nicht eingehen, aber die geben

01:01:40.400 --> 01:01:44.620
einmal an, ob das eine lokale Adresse ist, die nur in diesem lokalen

01:01:44.620 --> 01:01:49.880
Netz gültig ist, das ist die kürzere 16-Bit-Adresse, oder ob das eine

01:01:49.880 --> 01:01:53.660
48 -Bit-Adresse ist, das, was Sie typischerweise verwenden, die global

01:01:53.660 --> 01:01:55.100
eindeutig sein sollte.

01:01:57.500 --> 01:02:01.780
Da gibt es ganz einfach hier vorne wieder ein Bit, was mir sagt, lang

01:02:01.780 --> 01:02:02.220
oder kurz.

01:02:03.820 --> 01:02:08.380
Und global eindeutig sein sollte, sage ich bewusst, weil es gibt

01:02:08.380 --> 01:02:12.920
doppelte Adressen und es ist durchaus auch möglich, wenn man clever

01:02:12.920 --> 01:02:15.040
genug ist, dass man sich diese Adresse selber ändert.

01:02:15.920 --> 01:02:17.420
Und damit kann man doppelte Adressen hervorrufen.

01:02:20.020 --> 01:02:22.220
So, soweit zum CSMA CD.

01:02:22.440 --> 01:02:25.240
Die Besonderheit in der Dateneinheit hinsichtlich des

01:02:25.240 --> 01:02:27.040
Zugriffsverfahren war einfach das Padding-Feld.

01:02:27.880 --> 01:02:29.240
Der Rest ist ziemlich Standard.

01:02:29.240 --> 01:02:32.540
Das werden wir jetzt gleich wieder sehen, weil jetzt müssen wir uns ja

01:02:32.540 --> 01:02:36.480
darum kümmern, wie sieht denn die Strukturierung der Daten im Token

01:02:36.480 --> 01:02:37.000
-Ring aus.

01:02:38.000 --> 01:02:40.460
Was wir wieder haben, klar, das Datenfeld da hinten.

01:02:41.500 --> 01:02:42.940
Padding-Feld brauchen wir keins.

01:02:44.000 --> 01:02:45.720
Wir haben wieder eine Frame-Check-Sequenz.

01:02:46.480 --> 01:02:49.420
Das hatten wir einfach, damit ich Bit-Fehler erkennen kann.

01:02:50.400 --> 01:02:53.020
Wir werden wieder Ziel- und Quelladressen haben.

01:02:53.620 --> 01:02:56.780
Hier, also auch das, absoluter Standard.

01:02:57.900 --> 01:03:01.060
Naja, und das Besondere, was jetzt reinkommt, wir hatten sowas wie ein

01:03:01.060 --> 01:03:01.400
Token.

01:03:02.300 --> 01:03:03.660
Und der muss ja auch eine Struktur haben.

01:03:04.000 --> 01:03:06.520
Das sind ja auch Bits, die nachher einfach über die Leitung gesendet

01:03:06.520 --> 01:03:06.720
werden.

01:03:08.260 --> 01:03:09.720
Und das ist dieses Teil hier.

01:03:11.760 --> 01:03:12.780
Wieder Standard.

01:03:13.020 --> 01:03:17.420
Sie haben sowas wie ein Start-Delimiter vorne dran, um sich zu

01:03:17.420 --> 01:03:18.080
synchronisieren.

01:03:20.280 --> 01:03:24.940
Dann haben wir sowas wie ein Access-Control-Feld, AC, das die

01:03:24.940 --> 01:03:26.060
Zugriffskontrolle regelt.

01:03:26.060 --> 01:03:27.960
Das kommt jetzt auf den Ring, tatsächlich.

01:03:28.360 --> 01:03:31.780
Und Sie haben nachher einen End-Delimiter hinten dran hängen, den wir

01:03:31.780 --> 01:03:33.080
hier auch wieder finden.

01:03:34.780 --> 01:03:37.740
So, wie sieht das Zugriffsfeld aus?

01:03:38.560 --> 01:03:41.680
Das ist im Prinzip jetzt ein Bit, was ganz wichtig ist.

01:03:42.560 --> 01:03:46.080
Das sogenannte Token-Bit, das schlicht und einfach regelt, ist der

01:03:46.080 --> 01:03:47.620
Token, der vorbeikommt, frei?

01:03:48.500 --> 01:03:49.500
Das heißt, ich darf ihn belegen?

01:03:49.880 --> 01:03:50.700
Oder ist er belegt?

01:03:51.340 --> 01:03:55.340
Das heißt, er ist hier vorne in der Dateneinheit drin.

01:03:57.460 --> 01:04:00.220
Dann gibt es eine ganze Reihe anderer cleverer Sachen, wo wir nicht

01:04:00.220 --> 01:04:01.420
weiter darauf eingehen wollen.

01:04:02.240 --> 01:04:05.400
Prioritätsregelungen, dazu gehören auch die reservierten Bits, die man

01:04:05.400 --> 01:04:06.500
da noch verwendet hat.

01:04:07.420 --> 01:04:10.580
Und es gibt ein M-Bit, das ist ein Monitor-Bit.

01:04:11.640 --> 01:04:14.440
Im Prinzip wird in diesem Ring nachher eine ausgezeichnete Station

01:04:14.440 --> 01:04:16.240
bestimmt, die den Ring überwacht.

01:04:17.100 --> 01:04:20.860
Und die erkennt zum Beispiel an dem Bit hier, wenn eine Dateneinheit

01:04:20.860 --> 01:04:23.220
vorbeikommt, setzt sie das Monitor-Bit.

01:04:23.640 --> 01:04:27.640
Wenn die nochmal vorbeikommt, ist das Monitor-Bit noch gesetzt, dann

01:04:27.640 --> 01:04:29.920
weiß sie, die Dateneinheit kommt zum zweiten Mal herum.

01:04:31.000 --> 01:04:33.340
Das ist beispielsweise dann der Fall, wenn die sendende Station

01:04:33.340 --> 01:04:35.540
ausfällt und die Dateneinheit nicht mehr vom Ring nimmt.

01:04:39.480 --> 01:04:41.980
Ja, und sonst ist schon fast gar nichts Besonderes drin.

01:04:44.740 --> 01:04:47.520
Eine Merkwürdigkeit des Token-Rings, muss man fast sagen, ist dieses

01:04:47.520 --> 01:04:48.420
hintere Byte hier.

01:04:49.360 --> 01:04:51.820
Da hat man nochmal ein Byte hinten dran geklackt.

01:04:52.440 --> 01:04:56.320
Und hat gesagt, naja, wenn die Station jetzt die Daten vom Ring nimmt,

01:04:56.400 --> 01:05:03.140
also die Daten liest, also, ich bleibe da mal zurück, die Station C

01:05:03.140 --> 01:05:07.700
hier, wenn die jetzt die Daten liest, dann sieht die ja auch die

01:05:07.700 --> 01:05:13.260
Prüfsumme, dann kann die im Prinzip, wenn die Daten raus sind, ja

01:05:13.260 --> 01:05:18.520
sagen, ob sie ihre Adresse erkannt hat, ob sie die Daten kopiert hat,

01:05:19.180 --> 01:05:20.300
ob irgendein Fehler drin war.

01:05:22.180 --> 01:05:26.360
Also ist man hergegangen und hat dieses merkwürdige Byte da hinten

01:05:26.360 --> 01:05:30.480
dran gestopft und hat halt gesagt, naja, ich kann jetzt solche Dinge

01:05:30.480 --> 01:05:34.640
sagen, wie mit dem A-Bit, ich habe die Adresse erkannt, meine eigene

01:05:34.640 --> 01:05:42.320
Adresse, ich habe mit dem C-Bit die auch tatsächlich kopiert, oder ich

01:05:42.320 --> 01:05:45.220
habe bei E irgendwo einen Fehler entdeckt da drin, könnte ja sein

01:05:45.220 --> 01:05:45.780
Prüfsumme.

01:05:46.060 --> 01:05:48.320
Die Prüfsumme kann ich on the fly einfach mit berechnen, das ist kein

01:05:48.320 --> 01:05:48.700
Problem.

01:05:50.560 --> 01:05:55.840
Die Idee, die dahinter steckt, ist, naja, ich kann der sendenden

01:05:55.840 --> 01:05:59.580
Station, die die Daten wieder zurückkriegt, damit Informationen geben,

01:05:59.660 --> 01:06:03.220
ob was schief lief, und wenn was schief lief, könnte die die Daten

01:06:03.220 --> 01:06:03.980
nochmal wiederholen.

01:06:06.120 --> 01:06:07.420
Implementiert ist das überhaupt nicht.

01:06:08.340 --> 01:06:12.400
Das ist eine Sache, die zum Ärgernis der Studierenden, die die Dinge

01:06:12.400 --> 01:06:16.320
lernen, vorhanden ist, die aber eigentlich überhaupt nicht

01:06:16.320 --> 01:06:17.320
praxisrelevant ist.

01:06:19.060 --> 01:06:22.180
Man hat die Dinger dann hier auch zweimal reingemacht, aus dem

01:06:22.180 --> 01:06:25.840
einfachen Grund, weil die hängen ja hinter der Prüfsumme, das heißt,

01:06:25.920 --> 01:06:28.240
die kann ich nicht nochmal wieder absichern, also schreibe ich sie

01:06:28.240 --> 01:06:30.760
zweimal rein und schaue nachher, ob die Bits gleich sind.

01:06:36.080 --> 01:06:41.240
Die Präambel hier vorne spare ich mir, weil ich den Anfang der

01:06:41.240 --> 01:06:44.160
Rahmenerkennung über Coderegelverletzungen mache.

01:06:45.060 --> 01:06:48.360
Coderegelverletzungen sind, je nachdem welchen Code ich auf Schicht 1

01:06:48.360 --> 01:06:52.760
nehme, kann ich gezielt irgendwie Regelwidrigkeiten einbauen und die

01:06:52.760 --> 01:06:54.000
dann auf den höheren Schichten ausnutzen.

01:06:55.040 --> 01:06:57.220
Wollen wir uns im Detail nicht angucken, schauen wir uns in der

01:06:57.220 --> 01:06:58.700
Telematik relativ detailliert an.

01:07:01.060 --> 01:07:08.360
Jetzt stand noch eine Frage im Raum, von vorhin, nämlich die Frage,

01:07:08.500 --> 01:07:11.060
wieso die Station C hier nicht die Daten einfach vom Netz nimmt.

01:07:14.380 --> 01:07:17.160
Hier belasten die Daten ja das Netz eigentlich unnötig.

01:07:18.800 --> 01:07:20.500
Hat jemand eine Idee, wieso es nicht geht?

01:07:41.520 --> 01:07:45.720
Jetzt kommt das Antwort hier wegen dem letzten Byte, damit A nachher

01:07:45.720 --> 01:07:48.700
weiß, ob das tatsächlich kopiert worden ist oder nicht.

01:07:50.700 --> 01:07:54.200
Das wäre so, wenn man tatsächlich dieses Byte als für einen

01:07:54.200 --> 01:07:56.080
zuverlässigen Dienst verwenden würde.

01:07:56.580 --> 01:07:58.920
Wie gesagt, das Byte ist eigentlich Luxus, man könnte es genauso gut

01:07:58.920 --> 01:07:59.880
weglassen können.

01:08:00.200 --> 01:08:01.540
Das hat eigentlich keine Bedeutung.

01:08:02.640 --> 01:08:04.180
Wenn man es verwenden würde, ja.

01:08:06.700 --> 01:08:10.540
Wir stellen aber, und das muss nochmal klar sein, oberhalb der Schicht

01:08:10.540 --> 01:08:13.180
1, 2a, einen unzuverlässigen Dienst bereit.

01:08:14.940 --> 01:08:18.020
Mit dem Byte war so der Versuch, ein bisschen zuverlässiger zu werden.

01:08:35.260 --> 01:08:36.580
Jetzt kommen zwei Sachen.

01:08:37.100 --> 01:08:40.040
Einmal wurde gesagt, naja, C hat ja eigentlich keinen Token.

01:08:41.160 --> 01:08:45.760
Und die andere Sache war, A könnte ja noch auch an beispielsweise D

01:08:45.760 --> 01:08:46.860
was senden wollen.

01:08:46.860 --> 01:08:49.420
Und deswegen den Token nicht freigeben wollen.

01:08:51.620 --> 01:08:54.820
Ja, ja, aber A darf den Token sowieso noch für eine bestimmte Zeit

01:08:54.820 --> 01:08:55.200
behalten.

01:08:55.420 --> 01:08:56.660
Also irgendwann muss es wieder los werden.

01:08:56.980 --> 01:08:59.280
Das mit dem Token bei C habe ich nicht ganz verstanden.

01:09:09.500 --> 01:09:13.240
C hat den Token nicht, aber C will vielleicht auch gar nicht senden.

01:09:13.380 --> 01:09:19.380
Also die Frage ist, könnte ich nicht mir das hier ersparen?

01:09:20.240 --> 01:09:24.480
Und A könnte ja den Token einfach, wenn es fertig ist, nach einer

01:09:24.480 --> 01:09:25.720
bestimmten Zeit wieder weitergeben.

01:09:35.280 --> 01:09:40.800
Okay, A weiß nicht, wann es den Token weitergeben darf.

01:09:40.980 --> 01:09:41.960
Das müsste man regeln.

01:09:42.440 --> 01:09:44.260
Jetzt mal gesetzt den Fall, wir könnten das regeln.

01:09:44.740 --> 01:09:48.840
Dass A den Token dann einfach, wenn es drei Millisekunden gesendet

01:09:48.840 --> 01:09:49.660
hat, weitergeben muss.

01:10:05.720 --> 01:10:09.680
Er meint gerade, naja, wenn jetzt C den Token einfach freigibt und

01:10:09.680 --> 01:10:13.080
wieder was an A sendet, und dann A den Token freigibt und wieder was

01:10:13.080 --> 01:10:14.620
an C sendet, dann ist er der Loser hier.

01:10:15.220 --> 01:10:16.500
Weil er nie einen freien Token kriegt.

01:10:16.700 --> 01:10:21.600
Ja, der freie Token müsste absolut von A weitergegeben werden.

01:10:22.100 --> 01:10:24.880
Ich habe vorhin die Frage nicht beantwortet, weil ich gesagt habe, wir

01:10:24.880 --> 01:10:26.980
müssen uns die Struktur der Dateneinheiten erstmal ein bisschen

01:10:26.980 --> 01:10:27.480
anschauen.

01:10:29.200 --> 01:10:32.220
Vielleicht gehen wir da nochmal auf die Dateneinheit.

01:10:33.000 --> 01:10:38.160
Zu welchem Zeitpunkt weiß denn Station C, dass die Daten für sie

01:10:38.160 --> 01:10:38.760
bestimmt sind?

01:10:46.630 --> 01:10:46.970
Ja?

01:10:57.290 --> 01:10:57.970
Genau.

01:10:59.130 --> 01:11:04.170
Station C weiß ja erst, wenn sie die gesamte Zieladresse gelesen hat,

01:11:04.830 --> 01:11:06.290
dass das Datum für sie ist.

01:11:07.890 --> 01:11:12.430
Wenn es jetzt die Daten nicht weitergeben würde, dann müsste die

01:11:12.430 --> 01:11:14.450
Adresse ja erstmal gepuffert werden.

01:11:15.650 --> 01:11:18.690
Und dann war ganz korrekt gesagt, genau dadurch erzeuge ich ja dann

01:11:18.690 --> 01:11:23.110
nachher praktisch eine 6-Byte-Verzögerung in jeder Station, wodurch

01:11:23.110 --> 01:11:26.130
ich die Ende-zu-Ende-Verzögerung einfach erhöhen würde.

01:11:26.950 --> 01:11:29.490
Ich habe vorhin aber gesagt, in jeder Station wird genau um ein Bit

01:11:29.490 --> 01:11:30.510
verzögert.

01:11:31.870 --> 01:11:35.950
Das heißt, deswegen kann die Station gar nicht wissen, dass das Datum

01:11:35.950 --> 01:11:37.610
für sie ist und muss es weitergeben.

01:11:45.190 --> 01:11:47.830
Da hatten wir auch nochmal irgendwo...

01:11:54.140 --> 01:11:57.040
Guter Punkt, immer wieder beliebte Prüfungsfrage, woher weiß eine

01:11:57.040 --> 01:11:58.720
Station A, dass es die Daten wegnehmen darf?

01:12:01.640 --> 01:12:04.920
A sendet ja, woher weiß denn A, das könnte ja schon lange fertig sein

01:12:04.920 --> 01:12:06.220
mit senden, bevor es zurückkommt.

01:12:09.440 --> 01:12:12.240
Es gibt nur einen Token und A weiß, ich habe den Token.

01:12:13.960 --> 01:12:16.760
Und der wird freigegeben, wenn die Daten empfangen wurden.

01:12:17.360 --> 01:12:18.740
Dadurch weiß er, dass die Daten wegkommen.

01:12:23.960 --> 01:12:26.320
Jetzt frage ich mich gerade, wie ich hier gezielt zurückkomme.

01:12:52.260 --> 01:12:55.720
Also Sie sehen schon, da sind jede Menge andere Applets, das lohnt

01:12:55.720 --> 01:12:57.960
sich mal beim Herrn Effelsberg auf die Webseite draufzugucken.

01:13:03.220 --> 01:13:09.040
Informatik, unimannheim.de Ja, okay, Herr Walter legt den Link

01:13:09.040 --> 01:13:10.680
irgendwo auf die Webseite drauf.

01:13:11.580 --> 01:13:14.000
Also da gibt es alles mögliche, ich will jetzt aber genau den

01:13:14.000 --> 01:13:15.220
Tokenring eigentlich finden.

01:13:29.650 --> 01:13:31.390
So, jetzt können wir mal sagen, dass der...

01:13:34.170 --> 01:13:36.030
Kann ich das irgendwie auswählen, wer an wen sendet?

01:13:42.080 --> 01:13:46.240
So, jetzt sehen wir da unten einen Token, da ich aber keinen Sender

01:13:46.240 --> 01:13:47.080
ausgewählt habe.

01:13:49.460 --> 01:13:50.820
Es dürfte nicht viel passieren.

01:13:51.380 --> 01:13:56.280
Was Sie aber hier sehen, ist schon mal dieses Zugriffskontrollfeld vom

01:13:56.280 --> 01:13:56.500
Tokenring.

01:13:57.440 --> 01:13:59.560
Und da sehen Sie die Prioritäten und Reservierungsbits, haben wir uns

01:13:59.560 --> 01:14:00.300
da nicht angeguckt.

01:14:01.940 --> 01:14:08.080
Da sieht man das Tokenbit und hier sieht man das Monitorbit, was von

01:14:08.080 --> 01:14:10.920
der Monitorstation, und das ist wohl diese rote hier, gesetzt worden

01:14:10.920 --> 01:14:11.200
ist.

01:14:12.700 --> 01:14:14.960
Genau, Monitor auf Station 0.

01:14:26.020 --> 01:14:28.520
Ah, so, jetzt müsste der Daten senden.

01:14:31.420 --> 01:14:33.280
Genau, jetzt sehen Sie die Daten.

01:14:35.780 --> 01:14:38.460
Da sehen Sie jetzt gleich hoffentlich das Monitorbit umkippen.

01:14:39.560 --> 01:14:39.800
Nicht?

01:14:40.060 --> 01:14:40.400
Schade.

01:14:43.200 --> 01:14:44.880
So, das sind die weitergeleiteten Daten.

01:14:48.280 --> 01:14:51.060
Und jetzt müsste eigentlich Station... genau, jetzt geht das Token

01:14:51.060 --> 01:14:51.420
weiter.

01:14:51.420 --> 01:14:54.240
Jetzt nimmt der sich wieder das Token, Tokenbit auf 0.

01:14:54.920 --> 01:14:56.420
Die Daten werden weitergeleitet.

01:15:00.080 --> 01:15:02.000
Kommen an Station 3.

01:15:10.850 --> 01:15:13.490
Okay, und so geht es dann einfach weiter.

01:15:16.250 --> 01:15:20.350
Ist einfach ganz nützlich, sich das mal anzuschauen, weil man nochmal

01:15:20.350 --> 01:15:23.280
einen ganz anderen Blick drauf kriegt als auf den Folien.

01:15:26.600 --> 01:15:33.730
So, genau, jetzt haben wir also lokale Netze gesehen.

01:15:34.510 --> 01:15:37.910
Eine Sache auf Schicht 2, die nochmal ein anderes

01:15:37.910 --> 01:15:43.230
Medienzugriffsverfahren darstellt, ist ein kontrollierter Zugriff bei

01:15:43.230 --> 01:15:43.830
HDLC.

01:15:45.070 --> 01:15:48.390
HDLC ist jetzt kein lokales Netz, sondern HDLC ist ein

01:15:48.390 --> 01:15:53.730
Standardprotokoll auf Schicht 2, das Ihnen in fast jedem

01:15:53.730 --> 01:15:55.310
Telekommunikationsnetz begegnet.

01:15:55.670 --> 01:15:59.310
Das ist bei ISDN drin, das ist bei GSM drin, das ist fast überall

01:15:59.310 --> 01:16:00.610
drin, bloß nicht in lokalen Netzen.

01:16:02.130 --> 01:16:06.470
Da gibt es eine Form, die davon ausgeht, dass wir eine Leitstation

01:16:06.470 --> 01:16:06.930
haben.

01:16:07.730 --> 01:16:10.490
Das ist eine Betriebsform, es gibt mehrere bei HDLC.

01:16:12.210 --> 01:16:16.950
Und sozusagen dumme Folgestationen und diese Leitstation, die polt

01:16:16.950 --> 01:16:21.210
jetzt nacheinander die Folgestation beispielsweise und fragt ab, habt

01:16:21.210 --> 01:16:22.230
ihr mir was zu senden?

01:16:22.610 --> 01:16:24.930
Wenn die was zu senden haben, dann dürfen die antworten.

01:16:25.590 --> 01:16:29.030
Dann nimmt er die nächste Station, dürfen die wieder antworten und so

01:16:29.030 --> 01:16:29.310
weiter.

01:16:32.030 --> 01:16:35.590
Wie gesagt, das HDLC an sich ein typisches Protokoll, was man irgendwo

01:16:35.590 --> 01:16:36.990
im Weitverkehrsnetz findet.

01:16:37.850 --> 01:16:42.090
Die Art und Weise, so zu kommunizieren, wie das hier dargestellt ist

01:16:42.090 --> 01:16:45.010
mit Leitstation und Folgestation, finden Sie sehr viel in der

01:16:45.010 --> 01:16:46.130
Automatisierungstechnik.

01:16:46.950 --> 01:16:49.630
Nicht im Datenkommunikationsbereich, aber im

01:16:49.630 --> 01:16:53.010
Automatisierungstechnikbereich ist das eher wieder eine relativ

01:16:53.010 --> 01:16:56.090
typische Sache, wo Sie genau kontrollieren können müssen, was macht

01:16:56.090 --> 01:16:56.650
welche Station.

01:16:57.910 --> 01:17:04.670
Ist durchaus auch ein typisches Betriebsmuster, das Sie beispielsweise

01:17:04.670 --> 01:17:10.110
in Netzen finden, die Sie im Auto haben, wo eben ständig gewisse Teile

01:17:10.110 --> 01:17:14.030
des Netzes abgefragt werden und Sie sehr genau kontrollieren können

01:17:14.030 --> 01:17:15.370
wollen, mit wem Sie gerade reden.

01:17:16.310 --> 01:17:21.130
Also da ist so ein ISANET nicht gerade so unbedingt angesagt, das ist

01:17:21.130 --> 01:17:23.490
ganz klar, wenn Sie da irgendwie auf die Bremse treten und da erstmal

01:17:23.490 --> 01:17:26.150
eine Kollision passiert und deswegen Ihre Bremse nicht funktioniert,

01:17:27.050 --> 01:17:29.270
ist nicht das, was man wirklich haben will.

01:17:31.110 --> 01:17:33.630
So, dann schauen wir uns nochmal an, wie sehen bei HDLC jetzt die

01:17:33.630 --> 01:17:34.670
Dateneinheiten aus.

01:17:36.250 --> 01:17:38.990
Und auch das kann man sich jetzt dann wieder relativ einfach

01:17:38.990 --> 01:17:39.470
herleiten.

01:17:40.530 --> 01:17:45.350
Auch hier habe ich wieder eine Prüfsumme drin, auch hier habe ich

01:17:45.350 --> 01:17:48.350
wieder die Daten in eher relativ kurzen Dateneinheiten.

01:17:49.750 --> 01:17:52.190
Ein Kontrollfeld, mit dem ich den Ablauf kontrolliere und ich habe die

01:17:52.190 --> 01:17:52.710
Adressen drin.

01:17:53.110 --> 01:17:55.490
Da kann man gar nicht so viel weiter drauf eingehen.

01:17:56.730 --> 01:18:00.870
Eine interessante Sache, die jetzt hier reinkommt, man hat ein

01:18:00.870 --> 01:18:03.930
sogenanntes Flag, mit dem man Anfang und Ende der Dateneinheit

01:18:03.930 --> 01:18:04.390
begrenzt.

01:18:05.510 --> 01:18:08.990
Sie sehen hier jetzt kein Längenfeld drin, sondern Sie haben einen

01:18:08.990 --> 01:18:11.830
Flag und das gleiche Flag wieder hier am Ende.

01:18:12.990 --> 01:18:15.490
Hatten wir auch schon vor zwei Wochen besprochen sowas.

01:18:16.330 --> 01:18:21.050
Was müssen Sie also machen, da die ganzen Sachen hier ja transparent

01:18:21.050 --> 01:18:21.430
sind?

01:18:23.050 --> 01:18:26.030
Und da durchaus beispielsweise in den Daten so ein Flag wieder

01:18:26.030 --> 01:18:30.470
auftreten könnte, müssen Sie einfach verhindern, dass das Flag

01:18:30.470 --> 01:18:33.710
irgendwo innen drin auftauchen kann.

01:18:34.050 --> 01:18:37.170
Was machen Sie schlicht und einfach beim Senden, also nachdem Sie

01:18:37.170 --> 01:18:39.090
diese Dateneinheit hier zusammengebaut haben.

01:18:40.010 --> 01:18:44.410
Beim Senden jedes Mal, wenn Sie 5 Einser haben, fügen Sie einen Null

01:18:44.410 --> 01:18:44.690
ein.

01:18:45.350 --> 01:18:48.650
Beim Empfangen jedes Mal, wenn Sie 5 Einser gesehen haben, nehmen Sie

01:18:48.650 --> 01:18:49.230
eine Null raus.

01:18:49.890 --> 01:18:54.170
Und damit können Sie transparent solche, die Flags eben auch im

01:18:54.170 --> 01:18:55.590
Datenbereich übertragen.

01:18:57.530 --> 01:18:59.430
Ah genau, das ist hier nochmal ein Beispiel dargestellt.

01:19:00.170 --> 01:19:05.030
So, das war es erstmal zur Sicherungsschicht und zu den

01:19:05.030 --> 01:19:07.450
Dateneinheiten, wie sie dort aussehen.

01:19:07.450 --> 01:19:14.130
Es ist als Beispiel zu sehen, jeweils eben jetzt am Ethernet-Tokenring

01:19:14.130 --> 01:19:18.790
oder HTLC, wie die Protokolle nachher nochmal weiter im Detail

01:19:18.790 --> 01:19:19.650
funktionieren.

01:19:20.170 --> 01:19:23.210
Das gucken wir uns tatsächlich in der Telematik noch sehr viel genauer

01:19:23.210 --> 01:19:23.570
an.

01:19:26.290 --> 01:19:28.570
Damit kommen wir zum nächsten Kapitel.

01:19:32.470 --> 01:19:39.430
Nochmal eines, wo wir uns an einem Protokoll so ein Komplettbildchen

01:19:39.430 --> 01:19:40.270
anschauen wollen.

01:19:40.730 --> 01:19:43.730
Und auch ein bisschen anschauen wollen, ja wie beschreibe ich denn

01:19:43.730 --> 01:19:45.570
jetzt formal eigentlich Protokolle.

01:19:46.870 --> 01:19:51.990
Weil bisher haben wir das relativ informell eigentlich nur

01:19:51.990 --> 01:19:54.030
beschrieben, ohne irgendein formales Rüstwerk.

01:19:55.230 --> 01:19:57.970
Auch das gibt es für den Bereich natürlich.

01:19:59.170 --> 01:20:01.630
Wobei es nicht immer wirklich schön angewendet wird.

01:20:01.870 --> 01:20:04.550
Wenn Sie sich Standards im Internet anschauen, dann kriegen Sie

01:20:04.550 --> 01:20:09.510
irgendwie 20 Seiten Text, mit ziemlich viel Interpretationsfreiheit

01:20:09.510 --> 01:20:10.410
gelegentlich dazwischen.

01:20:11.470 --> 01:20:16.350
Was dann gerne dazu führt, dass natürlich Implementierungen, wo die

01:20:16.350 --> 01:20:19.570
Sachen unterschiedlich interpretiert wurden, nicht miteinander

01:20:19.570 --> 01:20:21.070
zusammenspielen können.

01:20:21.410 --> 01:20:22.590
Und das ist natürlich eine schlechte Sache.

01:20:23.450 --> 01:20:26.530
Deswegen ist es wichtig, solche Dinge auch tatsächlich formal

01:20:26.530 --> 01:20:26.810
darzustellen.

01:20:28.310 --> 01:20:31.070
Und da wollen wir gerade noch ein Stückchen reintauchen.

01:20:33.390 --> 01:20:37.490
Ganz abstrakt nochmal wieder aufsetzen, hier bei einem Dienstmodell.

01:20:39.370 --> 01:20:43.150
Wie wir es eigentlich jetzt in verschiedenen Stellen immer wieder

01:20:43.150 --> 01:20:43.850
gesehen haben.

01:20:44.750 --> 01:20:48.170
Wir haben ein Medium, das kann jetzt tatsächlich die physikalische

01:20:48.170 --> 01:20:49.670
Schicht, also das Medium selbst sein.

01:20:49.670 --> 01:20:54.870
Oder von dem, was wir eben gesehen haben, physikalische Schicht und

01:20:54.870 --> 01:20:57.610
Schicht 2 zusammen, wäre sowas wie das abstrakte Medium.

01:20:59.110 --> 01:21:02.970
Also ein abstraktes Medium, physikalische Schicht plus ein paar

01:21:02.970 --> 01:21:03.630
Protokolle.

01:21:04.110 --> 01:21:07.670
Sie haben immer die Dienstschnittstellen hier, mit den

01:21:07.670 --> 01:21:09.930
Dienstzugangspunkten und oben die Dienstnehmer.

01:21:10.990 --> 01:21:13.790
Von der Sicherungsschicht wäre das jetzt die Vermittlungsschicht.

01:21:16.370 --> 01:21:18.310
Ich finde das eigentlich gemein.

01:21:20.450 --> 01:21:23.190
Die, die hinter Ihnen sitzen, die können noch sehen, über was Sie sich

01:21:23.190 --> 01:21:24.430
amüsieren an Ihrem Bildschirm.

01:21:25.950 --> 01:21:26.870
Die vorne dran nicht.

01:21:34.310 --> 01:21:36.170
Schauen Sie sich eigentlich gerade die Vorlesungsfolien an?

01:21:37.310 --> 01:21:38.030
Ja, natürlich.

01:21:44.410 --> 01:21:49.230
So, dann können wir so einen Dienst, wie wir ihn hier in Anspruch

01:21:49.230 --> 01:21:53.290
nehmen, den zerlegen wir jetzt in eine Reihe von Dienstprimitiven.

01:21:55.050 --> 01:21:57.770
Deren Folge nachher wieder eine Dienstprozedur ist, wie wir am Anfang

01:21:57.770 --> 01:21:58.330
gelernt haben.

01:21:59.810 --> 01:22:01.230
Was gibt es für Dienstprimitive?

01:22:01.330 --> 01:22:05.650
Jetzt jeweils gekennzeichnet typischerweise durch die Schicht, in der

01:22:05.650 --> 01:22:06.510
sie verwendet werden.

01:22:06.830 --> 01:22:11.050
Also mit PH für die physikalische Schicht, mit DL für die Datalink

01:22:11.050 --> 01:22:11.350
-Schicht.

01:22:11.490 --> 01:22:13.870
Da war gestern schon so ein Beispiel drin, was sich reingemogelt hat,

01:22:13.930 --> 01:22:15.510
wo die Abkürzungen verwendet wurden.

01:22:15.870 --> 01:22:17.170
N für Networkschicht und so weiter.

01:22:18.210 --> 01:22:21.290
Sie haben dann verschiedene Dienstleistungen, wie Verbindungsaufbau.

01:22:24.950 --> 01:22:27.470
Datenübertragung, Verbindungsabbau, Unterbrechung der Verbindung,

01:22:28.070 --> 01:22:33.790
Unterbrechung durch den Dienstgeber, also einmal durch sie selber,

01:22:34.070 --> 01:22:36.030
einmal durch den Dienstgeber, der kann ja auch auf die Idee kommen,

01:22:36.150 --> 01:22:39.670
dass er sie nicht mehr weiter kommunizieren lassen will, und regulärer

01:22:39.670 --> 01:22:40.470
Verbindungsabbau.

01:22:42.210 --> 01:22:45.430
Dann wird typischerweise in verschiedene Dienstgrundtypen unterteilt,

01:22:46.290 --> 01:22:50.030
nämlich einmal den Request, also die eigentliche Anforderung, das

01:22:50.030 --> 01:22:56.070
Indication, das Anzeigen einer Anforderung beim Kommunikationspartner,

01:22:56.110 --> 01:23:00.030
beim Gewünschten, Response, die Antwort, die von dem kommt, und

01:23:00.030 --> 01:23:04.610
Confirmation, die Anzeige wieder, die beim Anfragenden nachher

01:23:04.610 --> 01:23:05.130
ankommt.

01:23:05.850 --> 01:23:08.390
Das findet man auf jeder Schicht irgendwo.

01:23:08.970 --> 01:23:11.910
Die einzelnen Parameter, die sie darin übergeben, sind natürlich dann

01:23:11.910 --> 01:23:12.930
abhängig von der Schicht.

01:23:12.930 --> 01:23:18.590
Also da könnten so Sachen kommen wie, ich will meine Verbindung

01:23:18.590 --> 01:23:22.890
innerhalb von x Sekunden aufgebaut haben, das heißt sie geben eine

01:23:22.890 --> 01:23:25.890
bestimmte Zeit vor, in der die Verbindung aufgebaut worden sein muss,

01:23:25.950 --> 01:23:26.670
und solche Geschichten.

01:23:28.150 --> 01:23:32.010
Und da sind natürlich Parameter auch die Adressen, beispielsweise, die

01:23:32.010 --> 01:23:32.650
wir gesehen haben.

01:23:33.770 --> 01:23:38.710
Das sind einfach zwei Beispiele, ein Verbindungsaufbau auf der

01:23:38.710 --> 01:23:42.230
Transportschicht, das sind die Adressen, zwischen denen die Verbindung

01:23:42.230 --> 01:23:45.870
etabliert werden soll, oder ein HTTP-Get beispielsweise.

01:23:46.410 --> 01:23:52.310
Die Sachen spielen sich jetzt hier am Dienstzugangspunkt ab.

01:23:53.370 --> 01:24:00.130
Dafür werden Sie in den Standards keine Beschreibung des Formates

01:24:00.130 --> 01:24:00.550
finden.

01:24:01.090 --> 01:24:05.570
Das Format wird hier für die Protokollinstanz definiert, und das

01:24:05.570 --> 01:24:09.790
definiert die Daten, die tatsächlich jetzt eben horizontal

01:24:09.790 --> 01:24:10.750
ausgetauscht werden.

01:24:11.130 --> 01:24:15.350
Für die Dienstprimitive, hier vertikal, in der Regel kein Datenformat

01:24:15.350 --> 01:24:16.290
spezifiziert.

01:24:17.270 --> 01:24:18.650
So, wie sieht sowas am Beispiel aus?

01:24:19.230 --> 01:24:22.250
Wegzeitdiagramm ist die eine Möglichkeit, die wir gerne zu Rate

01:24:22.250 --> 01:24:26.810
ziehen, um was anschaulich darzustellen, aber damit kann ich natürlich

01:24:26.810 --> 01:24:28.530
nur relativ beschränkt was darstellen.

01:24:28.530 --> 01:24:35.750
Wir sehen hier das Beispiel Verbindungsaufbau, Connect-Request, das

01:24:35.750 --> 01:24:41.410
hier ist der Dienstzugangspunkt jeweils, einen Dienstzugangspunkt als

01:24:41.410 --> 01:24:42.570
Aufforderung an die Schicht.

01:24:43.270 --> 01:24:46.930
Das Protokoll tauscht dann irgendwie eine Protokolldateneinheit aus

01:24:46.930 --> 01:24:49.690
mit dem anderen, hier wieder am Dienstzugangspunkt, das Indication,

01:24:50.130 --> 01:24:51.690
Response und Confirmation.

01:24:52.670 --> 01:24:55.690
Und gestern haben wir eigentlich schon gelernt, dass das nicht

01:24:55.690 --> 01:24:56.250
ausreicht.

01:24:56.250 --> 01:24:58.490
Das ist ein sogenannter Zwei-Wege-Handshake.

01:25:01.550 --> 01:25:03.870
Gestern ganz am Schluss hatten wir noch den Drei-Wege-Handshake

01:25:03.870 --> 01:25:06.610
gesehen, den ich eigentlich brauche, damit der nachher auch sicher

01:25:06.610 --> 01:25:09.250
ist, dass die Datenverbindung aufgebaut ist.

01:25:11.570 --> 01:25:15.350
Ja, hier so ein Beispiel, wie vom Provider, also vom abstrakten

01:25:15.350 --> 01:25:20.090
Medium, nachher ein Abbruch kommen kann.

01:25:20.090 --> 01:25:26.530
Das heißt, hier kommt ein Abort-Indication, das P hier ist glaube ich

01:25:26.530 --> 01:25:31.050
zu viel bei beiden, ein Abort-Indication, ah nee, halt, das stimmt,

01:25:31.130 --> 01:25:34.810
das steht für Provider-Abort-Indication, sorry, P steht für Provider,

01:25:36.290 --> 01:25:38.270
und damit wird eben die Verbindung nicht etabliert.

01:25:40.210 --> 01:25:43.430
Ja, dann kann man hier unterscheiden, so etwas wie den

01:25:43.430 --> 01:25:45.450
Richtungsbetrieb, hatten wir gestern auch schon kurz darüber

01:25:45.450 --> 01:25:48.230
gesprochen, dass sie einmal nur simplex kommunizieren dürfen, in diese

01:25:48.230 --> 01:25:53.110
Richtung, oder in beide Richtungen gleichzeitig, oder entweder in die

01:25:53.110 --> 01:25:53.950
oder in die Richtung.

01:25:55.590 --> 01:25:58.270
Das ist das Typische, was wir heute im Internet finden, oder beim

01:25:58.270 --> 01:26:02.130
Telefon, Wechselsprechanlage ist dafür ein Beispiel, oder eine

01:26:02.130 --> 01:26:06.270
Flugbuchung zum Beispiel, da kommt erstmal die Aufforderung in der

01:26:06.270 --> 01:26:09.290
Richtung, dann kommt hier irgendwie eine Gegenantwort usw.

01:26:10.810 --> 01:26:14.050
So etwas wäre typischerweise für Sensoren, wenn Sie Temperatursensoren

01:26:14.050 --> 01:26:17.070
oder so etwas haben, die über das Internet eine Temperatur

01:26:17.070 --> 01:26:20.230
kommunizieren, dann geht es genau in eine Richtung.

01:26:22.610 --> 01:26:27.770
Genau, hier ist nochmal das Beispiel, oder ein paar Beispiele dafür,

01:26:29.010 --> 01:26:33.130
Informationsabfrage für ein Simplex, Halbduplex, das Buchungsbeispiel,

01:26:33.330 --> 01:26:37.250
Sie denken wieder an unseren Flugreisenden, der seine Flug umbuchen

01:26:37.250 --> 01:26:41.390
will, oder das Ganze irgendwie hier auch im Duplex, wenn der einen

01:26:41.390 --> 01:26:44.370
neuen Request wegschicken kann, bevor eben die alte Antwort

01:26:44.370 --> 01:26:46.050
tatsächlich angekommen ist.

01:26:48.030 --> 01:26:50.730
Ja, und jetzt kommen alle möglichen Beispiele hier mit, lassen wir uns

01:26:50.730 --> 01:26:55.010
das gerade noch durchgehen, nochmal Verbindungsaufbau, Connection

01:26:55.010 --> 01:26:59.410
Request, hier jetzt gerade nicht angegeben, auf welcher Schicht, mit

01:26:59.410 --> 01:27:03.850
Beispielparametern, um das mal zu sehen, Quelladresse, Zieladresse, wo

01:27:03.850 --> 01:27:07.710
die ganze Verbindung hin aufgebaut werden muss, Qualitätsparameter,

01:27:07.810 --> 01:27:10.130
das könnte jetzt irgendwie so Zeit für den Verbindungsaufbau zum

01:27:10.130 --> 01:27:14.150
Beispiel sein, irgendwelche weiteren Sachen, und gegebenenfalls können

01:27:14.150 --> 01:27:15.730
Sie da schon kurze Nutzdaten mitschicken.

01:27:16.630 --> 01:27:18.930
Die Daten, die Sie da mitschicken, sind unzuverlässig.

01:27:20.550 --> 01:27:22.730
Da wird nicht garantiert, dass die irgendwie abgeliefert werden.

01:27:23.670 --> 01:27:27.850
So, jetzt kommt das Ganze am Dienstzugangspunkt hier beim Gerufenen

01:27:27.850 --> 01:27:33.230
an, die beiden Adressen sollten tunlichst die gleichen noch sein, was

01:27:33.230 --> 01:27:36.570
Sie jetzt hier sehen, da gibt es ein Sternchen an manchen Parametern,

01:27:38.790 --> 01:27:40.990
das bedeutet, die können verändert worden sein.

01:27:41.950 --> 01:27:46.030
Es kann sein, dass Sie hier Parameter anfordern, die das Medium gar

01:27:46.030 --> 01:27:50.250
nicht bereitstellen kann, die deswegen hier schon in einer vielleicht

01:27:50.250 --> 01:27:51.670
abgemilderten Form ankommen.

01:27:52.810 --> 01:27:55.570
Hier können die nochmal geändert werden, weil möglicherweise der

01:27:55.570 --> 01:27:58.950
Empfänger das gar nicht bereitstellen will, was eigentlich der Sender

01:27:58.950 --> 01:28:03.510
jetzt von ihm erwartet, und die werden nachher hier rüber

01:28:03.510 --> 01:28:08.170
kommuniziert, das heißt, der kriegt veränderte Parameter und kann sich

01:28:08.170 --> 01:28:10.890
dann entscheiden, ob er die Verbindung tatsächlich akzeptieren will

01:28:10.890 --> 01:28:13.810
oder ob er sagt, unter den Umständen verzichte ich drauf.

01:28:14.510 --> 01:28:17.950
Der kann hier auch wieder andere Nutzdaten zurückschicken, Nutzdaten

01:28:17.950 --> 01:28:22.310
übertragen, in dem Fall, wie gesagt, unzuverlässig, und ich habe so

01:28:22.310 --> 01:28:24.650
das dumpfe Gefühl, dass meine Zeit für heute abgelaufen ist.

01:28:25.370 --> 01:28:27.830
Dann machen wir Schluss und Übung ist jetzt nachher noch.