WEBVTT 00:03.980 --> 00:06.810 Sondern wir steigen gleich mit der Besprechung vom zweiten Übungsblatt 00:06.810 --> 00:07.250 ein. 00:07.990 --> 00:10.890 Ein bisschen mehr zu rechnen in diesem Übungsblatt. 00:11.230 --> 00:14.170 Ein paar Aufgaben für die Klausur, die vielleicht so ähnlicherweise 00:14.170 --> 00:14.890 kommen könnten. 00:15.490 --> 00:17.750 Im dritten machen wir wahrscheinlich wieder auch ein bisschen mehr 00:17.750 --> 00:20.130 Architektur, weniger Mathematik. 00:21.010 --> 00:24.290 Dennoch, die Aufgaben sind eben in dieser Hinsicht so gemischt. 00:24.990 --> 00:28.170 Und die erste war, wir wollten gleich mal beginnen mit Multiplex 00:28.170 --> 00:28.670 -Verfahren. 00:30.810 --> 00:33.170 In diesem Fall Zeit-Multiplex von verschiedenen 00:33.170 --> 00:33.670 Übertragungsanforderungen. 00:34.670 --> 00:37.170 Manche Duplex, manche Simplex, alle mit unterschiedlichen 00:37.170 --> 00:40.370 Übertragungsraten von zwei verschiedenen Orten. 00:41.310 --> 00:44.470 Wenn wir Zeit-Multiplex machen, muss uns klar sein, wir brauchen 00:44.470 --> 00:47.150 natürlich dann genug Bandbreite, um alle Übertragungsanforderungen 00:47.150 --> 00:49.350 unterzubringen und das wollten wir hier ausrechnen. 00:50.690 --> 00:56.130 Wir hatten also jeweils den Unterschied, ob die Verbindungen Duplex, 00:56.270 --> 00:59.030 Simplex oder Halbduplex waren und in welche Richtung sie flossen. 00:59.690 --> 01:03.790 Die Übertragungsanforderung 1 ging also nur von X nach Y und zwar 01:03.790 --> 01:06.650 Simplex und war 1000 Bit pro Sekunde. 01:11.100 --> 01:14.020 Die Übertragungsanforderung 2 war Duplex, ging also in beide 01:14.020 --> 01:16.960 Richtungen und hatte 64.000 Bit pro Sekunde. 01:17.940 --> 01:20.880 Ich setze jetzt extra mal keine Punkte oder Kommas, dass wir keine 01:20.880 --> 01:23.520 Missverständnisse kriegen. 01:24.300 --> 01:26.340 Die dritte Anforderung war Halbduplex. 01:27.860 --> 01:30.940 Halbduplex heißt ja getrennter Betrieb, jeweils nacheinander. 01:31.280 --> 01:35.620 Ich kann die Leitung nur in eine Richtung nutzen, zur gleichen Zeit, 01:35.820 --> 01:38.120 aber ich kann sie abwechselnd in beide Richtungen nutzen. 01:38.240 --> 01:41.180 Das muss uns bei dieser Aufgabe klar sein, denn ich brauche natürlich 01:41.180 --> 01:44.560 im notwendigen Fall die Bandbreite trotzdem in beide Richtungen. 01:45.700 --> 01:49.040 Das heißt, ich habe hier nochmal 100.000 Bit pro Sekunde für die 01:49.040 --> 01:50.360 Übertragungsanforderung 3. 01:51.380 --> 01:56.700 Dann kommen wir also für die Richtung von X nach Y auf 165.000 Bit pro 01:56.700 --> 01:57.140 Sekunde. 01:59.820 --> 02:02.000 Das gleiche für die Richtung von Y nach X. 02:02.120 --> 02:04.860 Hier brauchen wir für die Übertragungsanforderung 1 keine Bandbreite 02:04.860 --> 02:07.440 reservieren, weil sie eben nur Simplex in eine Richtung war. 02:08.080 --> 02:09.840 Das ist auch schon der einzige Unterschied hier drin. 02:10.540 --> 02:15.440 Ansonsten haben wir für beide anderen Anforderungen im schlimmsten 02:15.440 --> 02:17.020 Fall Bandbreite bereitzustellen. 02:17.200 --> 02:19.840 Wir kommen hier nur auf 164.000 Bit pro Sekunde. 02:21.140 --> 02:22.640 Was sollte man aus dieser Aufgabe lernen? 02:23.260 --> 02:25.280 Wie addiere ich drei sechsstellige Zahlen? 02:27.680 --> 02:29.120 Das macht man immer wieder falsch gerne. 02:29.900 --> 02:30.840 Spaß beiseite. 02:31.100 --> 02:33.880 Beachten Sie bei solchen Aufgaben in der Klausur, in welche Richtung 02:33.880 --> 02:34.460 laufen sie. 02:34.580 --> 02:38.420 Sind sie Simplex, Duplex, Halbduplex und in welche Richtung jeweils? 02:38.920 --> 02:40.700 Das wird immer wieder gerne falsch gemacht. 02:42.580 --> 02:45.680 So, wenn wir das gleiche machen, Bandbreiten können wir natürlich auch 02:45.680 --> 02:48.260 nachrichtentechnisch als Frequenzen angeben. 02:48.380 --> 02:51.500 Da habe ich Ihnen das Nyquist-Theorem noch dazu geschrieben. 02:52.020 --> 02:54.960 Praktisch, als Nachrichtentechniker würde man jetzt an der Hals 02:54.960 --> 02:55.280 springen. 02:55.400 --> 02:57.640 Aber praktisch halt die Umkehrung von Shannon und Raber, das 02:57.640 --> 02:58.160 Gegenstück. 02:59.340 --> 03:01.780 Wir wollten jetzt also ein Frequenzmultiplexing einführen. 03:01.880 --> 03:05.240 Das heißt, wir übertragen alle Anforderungen gleichzeitig, aber auf 03:05.240 --> 03:06.220 verschiedenen Frequenzen. 03:06.220 --> 03:09.340 Wir brauchen für die Anforderungen, je nach ihrer gewünschten 03:09.340 --> 03:12.860 Bandbreite, natürlich auch bestimmte Bandbreite an Frequenzen dann. 03:14.260 --> 03:20.740 Und die konnten wir ausrechnen eben, über das Nyquist-Theorem. 03:21.640 --> 03:24.940 Das gibt eben an, dass die Schrittgeschwindigkeit des Kanals, 03:29.800 --> 03:40.040 Kanalbandbreite in Hertz, dass die also nicht größer sein muss, darf, 03:42.960 --> 03:44.680 als zweimal die Schrittgeschwindigkeit. 03:47.360 --> 03:50.400 Überlegen wir es uns mal ganz einfach für die Übertragungsanforderung 03:50.400 --> 03:50.840 1. 03:51.500 --> 03:54.480 Wir haben 1000 Bit pro Sekunde, das heißt, wenn ich es mit einem 03:54.480 --> 03:57.820 Gleichstromverfahren übertrage, brauche ich also 1000 Schritte. 03:58.000 --> 03:59.520 Das heißt, ich brauche wie viel Hertz dafür. 04:07.240 --> 04:08.780 Bisschen lauter, irgendjemand. 04:10.260 --> 04:12.600 Ne, umgekehrt ist es, also mit 500 Hertz. 04:13.520 --> 04:16.680 Mit 500 Hertz kann ich dann die doppelte Menge Schritte reinbringen. 04:19.500 --> 04:23.260 Also lesen Sie sich die Definition vom Übungsblatt nochmal durch, dann 04:23.260 --> 04:24.380 soll es eigentlich klar werden. 04:24.800 --> 04:29.400 Wir brauchen hier 500 Hertz, damit wir die 1000 Schritte pro Sekunde 04:29.400 --> 04:32.460 machen können, die Anforderung 1 benötigt. 04:33.320 --> 04:36.200 So, vorgegeben war auch, dass wir jeweils 50 Hertz als 04:36.200 --> 04:37.640 Schutzbandbreite dazwischen haben. 04:37.800 --> 04:40.180 Klar, das macht man natürlich zur Vermeidung von Störungen, legt man 04:40.180 --> 04:42.500 die ganzen Frequenzbänder nicht genau nebeneinander. 04:43.980 --> 04:47.540 Für die Übertragungsanforderung 2 brauchen wir, wenn wir nur ein 04:47.540 --> 04:52.680 Adernpaar haben und jetzt duplex übertragen wollen, natürlich 04:52.680 --> 04:55.620 Frequenzbänder, zwei Stück, weil in beide Richtungen gleichzeitig 04:55.620 --> 04:56.660 übertragen werden kann. 04:57.120 --> 04:59.640 So, wie viel brauchen wir hier, wenn wir 64 Kilobit hatten? 05:04.340 --> 05:05.060 Habe ich es gehört? 05:06.080 --> 05:09.200 Also ich hoffe, 32.000 Hertz brauchen wir dann hier. 05:09.820 --> 05:13.460 Haben wir dann eine Schutzbandbreite, haben das gleiche hier jetzt 05:13.460 --> 05:14.820 eben auch in die Gegenrichtung. 05:17.000 --> 05:19.640 Und jetzt noch das letzte Interessante an dieser Aufgabe für die 05:19.640 --> 05:24.360 Anforderung 3, die wir nur Halbduplex haben, die also entweder in die 05:24.360 --> 05:27.120 eine Richtung oder in die andere Richtung geht, aber nicht beides 05:27.120 --> 05:29.900 gleichzeitig, brauchen wir natürlich nur ein Frequenzband, das wir 05:29.900 --> 05:32.140 dann abwechselnd nutzen können. 05:33.260 --> 05:36.660 Und zwar für 100.000 Bit pro Sekunde natürlich 50.000 Hertz. 05:37.860 --> 05:45.200 Wobei uns klar sein sollte, wie die Übertragungsanforderung 3 jetzt 05:45.200 --> 05:47.980 das Umschalten regelt, ist hier natürlich unklar. 05:49.460 --> 05:52.560 Das heißt, die Entscheidung ja, wann sendet der eine, wann sendet der 05:52.560 --> 05:54.820 andere, wann sende ich in die eine, wann sende ich in die andere 05:54.820 --> 05:55.120 Richtung. 05:55.120 --> 05:59.380 In diesem Fall, wenn wir nur genau die Bandbreite reserviert haben, 05:59.440 --> 06:02.960 die die Übertragungsanforderung eigentlich bräuchte, signalisieren wir 06:02.960 --> 06:05.180 natürlich dann auch in dieser Bandbreite. 06:05.320 --> 06:08.060 Das heißt, wir haben eine sogenannte Inband-Signalisierung hier. 06:10.280 --> 06:14.020 Also das Umschalten oder das Aushandeln, wer sendet wann, wird 06:14.020 --> 06:16.360 innerhalb der Daten praktisch geregelt. 06:19.420 --> 06:20.580 Das nennt sich dann Inband. 06:22.100 --> 06:25.980 Die Alternative Outband wäre praktisch, wir bräuchten nochmal eine 06:25.980 --> 06:28.700 kleine Frequenzbandbreite als Steuerkanal. 06:35.160 --> 06:36.820 So, das war auch schon die ganze Aufgabe 1. 06:36.920 --> 06:37.680 Haben Sie dazu Fragen? 06:38.820 --> 06:41.260 Sie sehen, wenn wir so schnell weitermachen, gibt es frühes 06:41.260 --> 06:41.700 Mittagessen. 06:45.940 --> 06:48.640 Wenn nein, machen wir gleich mit 2 weiter. 06:49.500 --> 06:53.700 Welche Isoosischicht ist dazu verpflichtet, die ankommenden Daten 06:53.700 --> 06:55.340 tatsächlich in ein Signal zu wandeln? 06:56.500 --> 06:57.780 Das müssen Sie alle wissen. 06:59.180 --> 07:06.020 Die 1, wir nennen es Bitübertragungsschicht. 07:09.420 --> 07:12.340 So, und jetzt sollten wir das Ganze mal mit dem Manchester-Code 07:12.340 --> 07:14.520 machen, der war auch angegeben auf dem Übungsblatt. 07:16.820 --> 07:21.320 In dem Fall codieren wir eine 1 mit einem Taktwechsel von einem hohen 07:21.320 --> 07:22.720 Pegel zu einem niedrigen Pegel. 07:23.220 --> 07:26.840 Wir haben mal noch angegeben, als erstes natürlich Einfachstrom. 07:26.980 --> 07:32.160 Wenn wir praktisch ein einzelnes Bit durch einen positiven Pegel 07:32.160 --> 07:36.520 übertragen und die 0, ja, entweder durch einen negativen Pegel oder 07:36.520 --> 07:36.900 die 0. 07:37.480 --> 07:39.800 Also das einfachste Übertragungsverfahren überhaupt, also 07:39.800 --> 07:40.520 Einfachstrom. 07:41.320 --> 07:44.760 Wenn wir jetzt Manchester-Code machen, dann codieren wir also eine 1 07:44.760 --> 07:46.440 durch einen Wechsel von oben nach unten. 07:47.000 --> 07:49.900 Und merken Sie sich am besten auch, wie man das einfach sich dann 07:49.900 --> 07:53.600 herleitet, sowohl für mündliche Prüfungen als auch für die Klausur. 07:55.020 --> 07:58.560 Der Taktwechsel, der die 1 angibt, findet dann in der Mitte des 07:58.560 --> 08:01.760 Taktrasters statt, das haben wir hier auch schon eingezeichnet. 08:02.220 --> 08:05.820 Das heißt, eine 1 können wir einfach in der Mitte des Taktrasters, 08:06.120 --> 08:09.200 einen Wechsel von oben nach unten einzeichnen. 08:10.280 --> 08:11.940 Und das können wir bei jeder 1 machen. 08:13.220 --> 08:15.740 Und so einfach können Sie dann hier schon diese Dinge codieren. 08:16.920 --> 08:19.340 So, jetzt brauchen wir natürlich, damit wir ein zusammenhängendes 08:19.340 --> 08:24.860 Signal hinkriegen, die Zwischenschritte und natürlich auch die 0. 08:25.700 --> 08:28.620 Bei der 0 war das Ganze dann natürlich umgekehrt, wir haben also einen 08:28.620 --> 08:29.820 Wechsel von unten nach oben. 08:30.080 --> 08:32.500 Und malen Sie die ruhig erstmal in die Mitte der Taktraster. 08:33.300 --> 08:35.460 Und noch nicht mehr, Sie kommen sonst nur durcheinander. 08:37.600 --> 08:41.420 So, das waren jetzt die innerhalb des Taktrasters stattfindenden 08:41.420 --> 08:44.400 Wechsel der Pegel für die 0 und 1. 08:45.740 --> 08:48.340 Und jetzt können wir das Ganze einfach noch verbinden, denn wir 08:48.340 --> 08:54.920 brauchen natürlich jetzt, beispielsweise an dieser Stelle hier, wenn 08:54.920 --> 08:57.100 eine gleiche Anzahl von Zeichen kommt, Hilfsschritte. 08:57.820 --> 09:00.660 Weil wir ja hier jetzt einen Low-Pegel haben und hier oben machen wir 09:00.660 --> 09:03.260 nachher mit einem High-Pegel weiter, brauchen wir also noch zwischen 09:03.260 --> 09:07.240 den Takten, an den Taktgrenzen, nochmal Hilfsschritte. 09:08.820 --> 09:11.360 Wo das nicht der Fall ist, brauchen wir die natürlich nicht. 09:12.420 --> 09:14.280 Das heißt, da geht das Ganze einfach weiter. 09:16.680 --> 09:17.360 Und hier haben wir noch... 09:20.580 --> 09:23.380 So, auf diese Art und Weise können Sie so eine Übertragung völlig 09:23.380 --> 09:25.480 fehlerfrei zusammenbauen, wenn Sie sowas gefragt werden. 09:26.260 --> 09:29.320 Es ist Ihnen normalerweise dann angegeben, wenn Sie es nicht auswendig 09:29.320 --> 09:32.000 wissen, oder es wird in der mündlichen Prüfung meistens gesagt, oder 09:32.000 --> 09:34.140 nicht so sehr als Fehler angerechnet, wenn Sie die Schritte 09:34.140 --> 09:37.800 verwechseln, ob jetzt eine 0 von unten nach oben geht oder von oben 09:37.800 --> 09:40.540 nach unten, wäre in dem Fall gar nicht so das Problem. 09:40.540 --> 09:42.860 Das war jetzt hier halt der Vorschlag vom ZIT. 09:44.280 --> 09:47.080 Welche Vorteile haben wir, die wir in der Vorlesung angesprochen 09:47.080 --> 09:52.140 haben, durch dieses Manchester-Verfahren gegenüber dem Einfachstrom 09:52.140 --> 09:52.620 -Verfahren? 09:52.800 --> 09:55.560 Beim Einfachstrom-Verfahren sehen wir zum Beispiel hier, wenn mal zwei 09:55.560 --> 09:57.480 Einser nacheinander kommen, was haben wir dann? 09:58.800 --> 09:59.600 Was haben wir nicht? 10:05.140 --> 10:06.360 Wir haben keinen Takt. 10:07.820 --> 10:11.680 Wir haben einen Takt, auf den sich Sender und Empfänger natürlich 10:11.680 --> 10:14.000 jeweils einigen müssen, wenn wir solche Übertragungen machen. 10:14.120 --> 10:16.580 Das heißt, sie müssen sich natürlich einig sein, wann tasten sie das 10:16.580 --> 10:17.420 Datensignal ab. 10:18.720 --> 10:21.160 Wir haben den natürlich auch in dem Fall, aber wir könnten ihn bei 10:21.160 --> 10:24.040 längeren Sequenzen von gleichen Ziffern verlieren, weil wir hier 10:24.040 --> 10:25.580 keinen Wechsel im Signal haben. 10:26.900 --> 10:29.580 Das heißt, wenn sich Empfänger und Sender miteinander synchronisiert 10:29.580 --> 10:33.020 haben und es kommt eine ganze Reihe an Einsen, dann könnten die Uhren 10:33.020 --> 10:36.080 auseinander driften und es könnten Differenzen entstehen, wann ich das 10:36.080 --> 10:37.320 Signal eigentlich abtaste. 10:37.920 --> 10:40.600 Und das ist natürlich auch genau der Vorteil vom Manchester-Code. 10:41.080 --> 10:43.580 Ich kann den Takt wieder rückgewinnen, 10:49.460 --> 10:53.560 weil ich in jedem Schritt mindestens einen Signalwechsel habe. 10:54.760 --> 10:57.440 Und das können Sender und Empfänger nutzen, um ihre Uhren immer wieder 10:57.440 --> 10:59.680 bei winzigen Differenzen aneinander anzugleichen. 11:01.320 --> 11:06.220 Ein weiterer Vorteil noch, ich könnte eventuell auch Signalfehler 11:06.220 --> 11:06.980 sogar noch erkennen. 11:12.100 --> 11:15.280 Ganz einfach, wenn dieser Taktschritt fehlt, der mindestens in jedem 11:15.280 --> 11:16.660 Takt einmal auftreten sollte. 11:17.460 --> 11:18.320 Was ist der Nachteil? 11:18.580 --> 11:19.360 Ganz klar... 11:31.480 --> 11:33.060 Das stimmt beides, ja. 11:33.440 --> 11:35.800 Also wir brauchen natürlich eine doppelte Schrittgeschwindigkeit. 11:41.930 --> 11:44.550 Unklar, wenn sie sich mal verloren haben, habe ich das Problem, dann 11:44.550 --> 11:46.190 würden sie sich sauber darauf einschwingen. 11:47.130 --> 11:48.730 Aber der Hauptnachteil, ich brauche eine doppelte 11:48.730 --> 11:50.910 Schrittgeschwindigkeit und die Schrittgeschwindigkeit, wie wir die 11:50.910 --> 11:54.090 Aufgabe vorher schon gehört haben, ist natürlich in gewisser Weise, 11:54.270 --> 11:55.790 was uns in der Bandbreite beschränkt. 11:55.910 --> 11:57.970 Für eine höhere Schrittgeschwindigkeit brauche ich dann natürlich auch 11:57.970 --> 11:59.150 ein breiteres Frequenzband. 11:59.950 --> 12:01.010 Das ist unser Nachteil. 12:04.010 --> 12:04.430 Fragen? 12:19.320 --> 12:22.120 Ich glaube nicht, dass das gewährleistet ist bei Manchester Code. 12:22.120 --> 12:24.120 Also wir haben zum Beispiel hier das Problem, dass wir... 12:30.550 --> 12:33.230 Ja, was ist meiner Meinung nach nicht durch den Code allein 12:33.230 --> 12:35.310 ausgeglichen, wie lange ich jetzt auf welchem Pegel bin. 12:35.470 --> 12:36.690 Also möchte ich jetzt ungern... 12:59.240 --> 13:01.680 Also worüber wir gerade diskutieren ist natürlich, es gibt noch 13:01.680 --> 13:04.800 Folgen, wenn ich sehr lange Zeit auf dem gleichen Pegel fahre, dann 13:04.800 --> 13:07.060 übertrage ich ja praktisch auch Gleichstrom und es fließt auch 13:07.060 --> 13:07.940 tatsächlich Strom. 13:07.940 --> 13:12.700 Was man als Betreiber von so einer Übertragungsleitung immer vermeiden 13:12.700 --> 13:13.040 möchte. 13:13.540 --> 13:15.900 Mit verschiedenen Codes kann man das tatsächlich ausgleichen. 13:16.000 --> 13:17.280 Das heißt, dass es nicht der Fall ist. 13:17.780 --> 13:20.140 Wenn wir also bei einem Einfachstromverfahren lange Zeit Einsen 13:20.140 --> 13:23.380 übertragen, dann haben wir lange Zeit einen High-Pegel und dadurch das 13:23.380 --> 13:25.140 Problem, dass praktisch Strom fließen kann. 13:26.460 --> 13:28.780 Und bei Manchester Code wechseln wir tatsächlich die Pegel. 13:28.840 --> 13:30.800 Das heißt, wir haben dadurch einen weiteren Vorteil. 13:36.780 --> 13:38.120 Ansonsten gehen wir mal weiter. 13:38.260 --> 13:40.880 Jetzt anstelle vom Basisbandverfahren gehen wir zu den drei 13:40.880 --> 13:43.700 Trägerfrequenzverfahren, die wir in der Vorlesung kennengelernt haben. 13:44.480 --> 13:46.000 Ich wollte sie jetzt nicht einzeln von Ihnen hören. 13:46.120 --> 13:47.720 Ich habe sie links unten schon dran geschrieben. 13:49.440 --> 13:51.760 Wir haben die Amplitudentastung kennengelernt. 13:51.860 --> 13:54.600 Wir haben die Frequenztastung und die Phasentastung kennengelernt. 13:56.600 --> 13:59.240 Die Schaltbilder, wie man so etwas herstellen kann, sind also auf den 13:59.240 --> 14:00.980 Vorlesungsvorlinien jeweils drauf gewesen. 14:03.940 --> 14:07.660 Wenn wir jetzt also bei der Amplitudentastung zum Beispiel eine 1 14:07.660 --> 14:11.440 kodieren mit einer hohen Amplitude, dann sieht das Ganze so aus. 14:13.200 --> 14:15.640 Wobei uns die Frequenz hier jetzt relativ egal ist. 14:16.340 --> 14:19.020 Wir kodieren auf jeden Fall eine 1 mit einer hohen Amplitude. 14:19.760 --> 14:23.560 Die 0 kodieren wir mit einer anderen Amplitude, normalerweise mit 14:23.560 --> 14:24.340 einer kleineren. 14:24.740 --> 14:27.380 Im Idealfall, naja, was heißt Idealfall? 14:27.460 --> 14:31.380 Im einfachsten Fall natürlich ganz einfach mit einer sehr kleinen 14:31.380 --> 14:32.400 Amplitude, nämlich 0. 14:35.080 --> 14:36.920 Und die 1 schwingt dann natürlich wieder. 14:37.820 --> 14:39.340 Dann machen wir wieder die Amplitude rein. 14:42.320 --> 14:42.680 So. 14:42.680 --> 14:44.080 Und so geht das Ganze dann weiter. 14:50.550 --> 14:52.990 Ich ging davon aus, dass ich es schon nach den ersten drei Fehlern 14:52.990 --> 14:54.230 vollständig verstanden habe. 14:54.350 --> 14:55.910 Wir müssen es nicht bis zum Ende ausfüllen. 14:56.650 --> 14:58.290 Ich gebe hohe Stücke auf Sie, sehen Sie schon. 14:59.610 --> 15:02.470 Bei der Frequenztastung machen wir was ähnliches. 15:02.590 --> 15:04.910 Wir machen aber, anstatt dass wir die Amplitude variieren, variieren 15:04.910 --> 15:05.570 wir die Frequenz. 15:05.630 --> 15:07.990 Das heißt, wir haben zwei verschiedene Trägerfrequenzen jetzt. 15:08.810 --> 15:13.110 Nehmen wir zum Beispiel mal für die 1 eine ähnliche Frequenz, wie wir 15:13.110 --> 15:13.690 sie hier hatten. 15:16.410 --> 15:19.170 Und nehmen wir jetzt mal für die 0, das ist Ihnen dann auch 15:19.170 --> 15:21.370 normalerweise vorgegeben, nehmen wir einfach mal eine schnellere 15:21.370 --> 15:22.750 Frequenz, zum Beispiel die doppelte. 15:24.250 --> 15:27.670 Ohne, dass Sie jetzt bitte die genauen Anzahlen hier zählen. 15:27.790 --> 15:29.030 Sie wissen, worauf ich hinaus will. 15:30.630 --> 15:30.990 So. 15:31.610 --> 15:36.250 Und für die 1 nehmen wir jetzt auch wieder die langsame Frequenz. 15:43.330 --> 15:44.950 Und genau so geht es dann auch hier weiter. 15:47.890 --> 15:48.510 Alles klar? 15:50.350 --> 15:52.410 So, machen wir das Ganze noch mit einer Phasentastung. 15:52.930 --> 15:55.210 Phasentastung haben wir vorgegeben gehabt, wir machen an den 15:55.210 --> 15:58.950 Taktgrenzen einen Phasensprung um 180°. 15:59.110 --> 16:00.970 Das heißt, wir kehren das Signal praktisch um. 16:02.990 --> 16:08.230 Und bei einer 0, das machen wir genau dann, wenn wir eine 0 übertragen 16:08.230 --> 16:08.490 wollen. 16:08.610 --> 16:11.890 Das heißt, wir machen also unser Signal, in welche Richtung auch 16:11.890 --> 16:12.130 immer. 16:12.750 --> 16:16.310 Wie gesagt, das so ganz ideal zu zeichnen, ist nicht so einfach. 16:16.770 --> 16:19.050 Jetzt wollen wir eine 0 übertragen, das heißt, wir machen tatsächlich 16:19.050 --> 16:19.850 einen Phasensprung. 16:20.050 --> 16:23.510 Das heißt, das Signal geht jetzt nicht so weiter, sondern springt 16:23.510 --> 16:23.970 jetzt um. 16:24.890 --> 16:25.810 In seiner Phase. 16:28.810 --> 16:30.850 So, bei einer 1 braucht man das nicht zu machen. 16:38.530 --> 16:40.710 Das heißt, bei der nächsten 1 braucht man das auch nicht zu machen, 16:40.810 --> 16:41.770 machen auch genauso weiter. 16:41.890 --> 16:43.590 Bei der nächsten 0 machen wir wieder einen Phasensprung. 16:45.470 --> 16:45.870 Hier. 16:46.720 --> 16:47.030 Und 16:50.220 --> 16:53.060 welches dieser 3 Verfahren ist am zuverlässigsten? 16:58.100 --> 16:59.760 1, 2 oder 3, welches Tor? 17:01.400 --> 17:02.020 Publikumsjoker? 17:06.570 --> 17:06.990 Ja, bitte. 17:08.750 --> 17:09.690 Das dritte. 17:11.130 --> 17:12.370 Die Phasentastung. 17:14.930 --> 17:19.770 Der Grund dafür ist einfach, sowohl die Amplitude ist störanfällig, 17:20.150 --> 17:22.790 sehr stark, bei irgendwelchen Störungen kann es sich sofort verändern. 17:23.430 --> 17:25.690 Auch die Frequenz ist ziemlich störanfällig. 17:26.030 --> 17:29.110 Die Phase von dem Signal ist schlicht und ergreifend das robusteste 17:29.110 --> 17:29.850 Merkmal hier. 17:30.530 --> 17:33.630 Leider Gottes auch ist es ein Stückchen aufwendig, die jeweils zu 17:33.630 --> 17:34.450 erfassen richtig. 17:34.750 --> 17:39.590 Also, der übliche Trade-off für das beste Verfahren braucht man ein 17:39.590 --> 17:40.490 paar Bauteile mehr. 17:41.010 --> 17:41.750 Fragen hierzu? 17:46.920 --> 17:48.580 Falls nicht, können wir weitergehen. 17:49.460 --> 17:50.940 Zum HDLC-Datenrahmen. 17:52.860 --> 17:53.900 Nächste Aufgabe. 17:54.920 --> 17:57.860 Da haben wir das Flag angegeben, das aus der Vorlesung auch vom 17:57.860 --> 18:01.380 Datenrahmen bekannt ist und jeweils den Start und das Ende von dem 18:01.380 --> 18:03.340 Datenrahmen kennzeichnet. 18:04.240 --> 18:06.980 Jetzt kann es uns natürlich passieren, dass wir in den Nutzdaten, weil 18:06.980 --> 18:10.560 es uns ja nicht verboten ist, genau diese Daten zufällig übertragen 18:10.560 --> 18:11.780 wollen, genau diese Bitfolge. 18:11.860 --> 18:16.560 Wie verhindern wir dann, dass fälschlicherweise der Empfänger denkt, 18:16.600 --> 18:17.680 die Übertragung ist beendet? 18:18.500 --> 18:19.620 Wie heißt das im Mechanismus? 18:21.520 --> 18:21.920 Genau. 18:23.360 --> 18:25.900 Wir machen Bitstopfen oder Bitstuffing. 18:28.260 --> 18:29.100 Wie funktioniert es? 18:33.430 --> 18:42.730 Genau, wir fügen also als Sender nach 5 Einsen auf jeden Fall eine 18:42.730 --> 18:49.060 Null ein und übertragen dann diese Bitfolge. 18:51.140 --> 18:55.140 So, der Empfänger macht logischerweise das Gegenstück, nämlich in 18:55.140 --> 18:55.900 Aufgabe B. 18:58.880 --> 18:59.960 Was macht er jetzt hier? 19:00.580 --> 19:04.660 Wo würde er das jetzt tun? 19:04.780 --> 19:06.720 Also wir haben jetzt hier keinen Start und Ende Flag, sondern das ist 19:06.720 --> 19:08.040 einfach ein Teil innerhalb der Nutzdaten. 19:09.360 --> 19:13.320 Jetzt haben wir zum Beispiel hier mal die ersten 5 Einser, wo es für 19:13.320 --> 19:14.640 uns wahrscheinlich interessant wird. 19:15.000 --> 19:15.780 Was machen wir jetzt hier? 19:15.880 --> 19:16.920 Was macht der Empfänger jetzt hier? 19:18.580 --> 19:23.640 Er entfernt diese Null, weil die auf jeden Fall, weil es innerhalb der 19:23.640 --> 19:25.460 Nutzdaten ist, vom Sender eingefügt wurde. 19:27.040 --> 19:28.320 Soll völlig klar sein. 19:30.360 --> 19:32.860 So, wir haben hier wieder 5 Einsen. 19:33.100 --> 19:33.680 Was tut er da? 19:34.860 --> 19:36.060 Er macht wieder die Null raus. 19:36.500 --> 19:39.740 Und was natürlich jetzt als Nutzdaten rauskommt am Ende, ohne dass ich 19:39.740 --> 19:42.560 es jetzt hinschreiben möchte, ist eben die gleiche Bitfolge, ohne 19:42.560 --> 19:46.080 diese zusätzlichen Nullen, die eben nur als Bitstopfen gedient haben. 19:48.100 --> 19:49.700 Das gleiche haben wir hier wieder. 19:50.760 --> 19:52.500 Welches Problem stoßen wir jetzt hier? 19:57.450 --> 19:58.250 7 Einsen. 20:00.090 --> 20:00.710 Ganze Menge. 20:02.370 --> 20:03.490 Was denkt sich der Empfänger jetzt? 20:03.550 --> 20:06.390 Was würde er denken, wenn es 6 Stück wären und dann eine Null käme? 20:09.750 --> 20:10.150 Nämlich? 20:16.380 --> 20:18.620 Also das ist die Zeichenfolge, die er eben auf seiner Leitung 20:18.620 --> 20:18.980 empfängt. 20:19.100 --> 20:21.300 Was würde er denken, wenn es 6 Einsen wären? 20:23.940 --> 20:25.320 Dass es ein Ende-Flag ist. 20:25.720 --> 20:26.260 Ganz genau. 20:26.920 --> 20:28.080 Jetzt sind es aber 7. 20:30.260 --> 20:31.180 Kann das vorkommen? 20:33.220 --> 20:33.660 Bitte? 20:33.660 --> 20:34.100 Genau. 20:35.420 --> 20:37.000 7 Einsen können nie vorkommen. 20:38.900 --> 20:41.500 In den Nutzdaten schon mal gleich gar nicht, da würden wir auf jeden 20:41.500 --> 20:42.420 Fall eine Null einfügen. 20:43.780 --> 20:47.120 Das einzige Möglichkeit, wo wir überhaupt 6 Einsen haben, ist das Flag 20:47.120 --> 20:48.820 und 7 können wir eigentlich nie kriegen. 20:49.660 --> 20:54.060 Das heißt, hier erkennen wir auf jeden Fall einen Übertragungsfehler. 21:00.170 --> 21:02.870 Allein durch die Bitstopfen, die eigentlich dafür gar nicht zuständig 21:02.870 --> 21:03.250 sind. 21:06.030 --> 21:08.990 Welche Eigenschaft erhält denn dieses Verfahren durch diesen 21:08.990 --> 21:10.650 Bitstopfen -Mechanismus? 21:11.470 --> 21:12.090 Wie nennt man das? 21:16.420 --> 21:18.760 Ich weiß nicht, ob wir es in der Vorlesung erwähnt haben. 21:20.080 --> 21:20.840 Ich denke schon. 21:21.300 --> 21:23.340 Die Eigenschaft heißt Codetransparenz. 21:26.690 --> 21:28.870 Kommen wir ganz prima zurück zu unserem Schichtenmodell. 21:28.870 --> 21:31.290 Ich kann oben an Daten reintun, was ich möchte. 21:31.530 --> 21:33.710 Der Mechanismus, der hier drunter liegt, sorgt dafür, dass damit 21:33.710 --> 21:34.730 nichts Böses geschieht. 21:34.810 --> 21:37.630 Zum Beispiel, dass wenn ich zufällig einen Flag reintue, die 21:37.630 --> 21:41.310 Datenfolge für den Flag, die Bitfolge, dass das Protokoll 21:41.310 --> 21:42.210 durcheinander gerät. 21:42.310 --> 21:45.010 Das heißt, für die obere Schicht wird keine besondere Anforderung 21:45.010 --> 21:45.370 gestellt. 21:45.550 --> 21:48.390 Was die reintut, bekommt der Empfänger an der gleichen Schnittstelle 21:48.390 --> 21:49.070 wieder raus. 21:50.270 --> 21:50.710 Codetransparenz. 21:52.190 --> 21:55.190 Für die oberen Schichten ist, was die untere Schicht tut und wie genau 21:55.190 --> 21:57.230 sie ihre Flags aufbaut, eben transparent. 22:02.290 --> 22:04.470 Das gleiche Verfahren gibt es übrigens auch noch als 22:04.470 --> 22:04.710 Characterstuffing. 22:05.470 --> 22:08.110 Muss also nicht notwendigerweise nur mit Bitstopfen zu tun haben. 22:08.230 --> 22:10.690 Genau das gleiche kann man tatsächlich auch mit ganzen Zeichen machen. 22:11.190 --> 22:14.910 Dass man sagt, wenn man ein bestimmtes Zeichen als Ende definiert und 22:14.910 --> 22:18.250 der Empfänger möchte es in seine Nutzdaten übertragen, dann macht man 22:18.250 --> 22:21.470 es auch einfach doppelt oder fügt andere Zeichen ein. 22:21.610 --> 22:23.250 Aber darauf wollte ich jetzt nicht weiter hinaus. 22:23.670 --> 22:27.650 Wenn Sie hierzu keine Fragen mehr haben, rechnen wir ein bisschen. 22:28.590 --> 22:29.850 Fehler erkennenden Codes. 22:30.070 --> 22:33.110 CRC-Prüfsummen haben wir auch in der Vorlesung schon angerissen. 22:33.990 --> 22:35.470 Auch immer beliebte Klausuraufgaben. 22:35.590 --> 22:36.910 Ob es daran kommt, schauen wir mal. 22:36.990 --> 22:37.630 Weiß ich noch nicht. 22:38.210 --> 22:40.510 Ich bestimme Ihr zweiter Wunsch, die Klausuraufgaben vorher im 22:40.510 --> 22:41.430 Internet veröffentlichen. 22:42.530 --> 22:44.130 Können wir nicht, haben wir noch nicht. 22:44.470 --> 22:47.470 Die übertragenden Daten haben wir hier definiert und unser Prüfpolynom 22:47.470 --> 22:48.290 haben wir definiert. 22:48.730 --> 22:51.270 Interessanterweise schreckt das Prüfpolynom immer wieder Leute ab, 22:51.310 --> 22:52.550 diese Aufgabe zu rechnen. 22:52.630 --> 22:54.130 Obwohl es eigentlich ganz einfach ist. 22:54.130 --> 22:55.870 Das Paket haben wir also. 22:56.070 --> 22:59.430 Jetzt brauchen wir aus dem Prüfpolynom noch unser Prüfmuster als 22:59.430 --> 23:00.030 Bitfolge. 23:02.430 --> 23:04.630 Ihnen ist bestimmt klar, wie wir das errechnen. 23:05.190 --> 23:10.990 Wir haben also hier oben einmal x hoch 5, einmal x hoch 4, x hoch 3 23:10.990 --> 23:11.650 fehlt uns. 23:13.890 --> 23:22.650 Also haben wir 0 mal, einmal x hoch 2, x fehlt wieder und eine 1. 23:25.090 --> 23:27.770 So und jetzt nehmen wir hier einfach die Bits raus und bilden dadurch 23:27.770 --> 23:28.390 unser Muster. 23:28.930 --> 23:29.450 Verdiktiert. 23:34.340 --> 23:36.280 Also 1, 1, 0, 1. 23:37.240 --> 23:38.780 0, 1 ist hier raus unser Muster. 23:40.240 --> 23:41.240 Ganz einfach. 23:50.960 --> 23:52.880 Unser Muster hat jetzt also 6 Bits. 23:55.400 --> 23:59.100 Und was müssen wir jetzt noch machen, bevor wir die CRC-Division 23:59.100 --> 23:59.860 durchführen können? 24:01.320 --> 24:05.100 Wir tun das Paket multiplizieren und zwar mit dem höchsten Grad. 24:05.500 --> 24:07.760 Sie erinnern sich aus der Vorlesung des Prüfpolynoms. 24:08.640 --> 24:12.480 Wir multiplizieren es also mit 2 hoch 5, weil es unser höchster Grad 24:12.480 --> 24:12.780 ist. 24:14.660 --> 24:17.040 Was bedeutet das in dieser Binärschreibweise? 24:17.200 --> 24:19.480 Was für uns sehr praktisch ist, weil wir nicht viel Arbeit damit 24:19.480 --> 24:24.360 haben, wenn wir das Paket mit 2 hoch 5 multiplizieren. 24:26.800 --> 24:28.640 Ganz genau, wir machen 5 Nullen dran. 24:30.780 --> 24:32.400 Schreiben also unser Paket ab. 24:38.420 --> 24:40.380 Und machen einfach noch 5 Nullen dran. 24:47.850 --> 24:48.010 So. 24:48.930 --> 24:50.870 Und jetzt können wir durch unser Muster, das wir jetzt in der 24:50.870 --> 24:53.870 Binärfolge umgerechnet haben, durchdividieren. 24:58.660 --> 25:02.920 Das funktioniert, wie Sie auf den Vorlesungsfolien sehen, minimal 25:02.920 --> 25:04.960 anders als eine normale Polynom-Division. 25:05.100 --> 25:06.620 Wir können das ein bisschen bequemer machen. 25:06.720 --> 25:08.460 Wir machen dann einfach eine XOR-Verknüpfung. 25:08.900 --> 25:11.800 Wir machen also genau das gleiche, was wir bei einer normalen Division 25:11.800 --> 25:12.700 auch machen würden. 25:15.320 --> 25:16.820 Schreiben den Divisor hierher. 25:17.260 --> 25:18.480 Und jetzt verknüpfen wir XOR. 25:19.060 --> 25:21.600 Das heißt, wir haben hier vorne eine 0, die sollten wir auch tunlichst 25:21.600 --> 25:21.860 kriegen. 25:23.100 --> 25:24.940 Hier eine 1, hier eine 1, hier eine 1. 25:25.380 --> 25:28.700 Hier sind die zwei Werte gleich, hier eine 0 und hier eine 1. 25:29.700 --> 25:33.560 Und da das Polynom natürlich reinpasst, haben wir hinten die erste 1. 25:35.580 --> 25:37.880 So, danach holen wir von oben den nächsten Wert runter. 25:39.320 --> 25:42.220 Eine 1, wieder unser Prüfpolynom. 25:52.580 --> 25:56.200 Wieder eine 1, eine 1, eine 1, die Werte sind gleich, wieder eine 0. 25:58.420 --> 25:59.600 Ich hoffe, Sie rechnen das im Kopf mit. 26:01.420 --> 26:04.240 So, auch hier hat es wieder reingepasst, haben also die nächste 1. 26:05.040 --> 26:06.840 Jetzt holen wir wieder das nächste Zeichen runter. 26:07.160 --> 26:09.540 Und hier wird es jetzt zum ersten Mal noch ein bisschen interessant, 26:10.140 --> 26:12.680 weil es passt nämlich unser Muster hier noch nicht hinein. 26:16.400 --> 26:19.060 Das heißt, wir verhalten uns wie bei einer normalen Division auch. 26:19.120 --> 26:22.700 Es passt noch nicht, wir machen eine 0 ins Ergebnis und holen uns die 26:22.700 --> 26:23.600 nächste Ziffer runter. 26:27.440 --> 26:30.060 Also das ist nochmal eine Stelle, wo es ein bisschen anders abläuft 26:30.060 --> 26:30.900 als im Normalfall. 26:32.100 --> 26:37.140 Das heißt, hier haben wir jetzt unser Polynom, unser Divisor einfach 2 26:37.140 --> 26:38.280 nach links und nach rechts geschoben. 26:38.680 --> 26:40.660 So, haben wir auch hier wieder eine 0. 26:41.600 --> 26:43.900 Also jetzt passt er wieder rein, das merken wir uns für das Ergebnis 26:43.900 --> 26:44.500 gleich wieder. 26:45.180 --> 26:48.840 Eine 1, eine 1, eine 1 und eine 1. 26:50.300 --> 26:54.240 So, an diesem Punkt gehe ich wieder davon aus, dass Sie es vollständig 26:54.240 --> 26:54.980 verstanden haben. 26:56.880 --> 26:58.900 Oder möchten Sie das was komplett durchrechnen? 27:00.180 --> 27:01.160 Das haben wir hier. 27:02.020 --> 27:04.120 Die gleiche Rechnung einfach bis zum Ende durchgezogen. 27:11.190 --> 27:14.350 Wenn es nicht gefordert ist, nein, denn da kommen wir jetzt dazu. 27:15.370 --> 27:16.470 Ich erwähne es gleich. 27:17.250 --> 27:20.870 Wir rechnen es also durch bis zum Schluss und kriegen dann einen Rest 27:20.870 --> 27:21.310 raus. 27:22.250 --> 27:24.990 Wenn wir die letzte Ziffer von oben runter geholt haben und 27:24.990 --> 27:27.670 ausprobiert haben, kommen wir auf einen Rest. 27:28.970 --> 27:31.910 So, und unten steht es schon, was übertragen wir jetzt als Bitfolge. 27:32.070 --> 27:34.370 Warum haben wir vorhin unser Paket nach links geschoben? 27:34.490 --> 27:38.510 Damit wir Platz haben, um den Rest drauf zu addieren. 27:39.310 --> 27:40.310 Das sieht dann so aus. 27:40.610 --> 27:43.510 Da waren vorher die 5 Nullen, da ist jetzt unser Rest drauf addiert. 27:43.510 --> 27:46.070 Und das hier ist dann die Bitfolge, die wir natürlich jetzt 27:46.070 --> 27:46.630 übertragen. 27:47.790 --> 27:52.590 Und das Interessante ist tatsächlich, das Ergebnis interessiert uns 27:52.590 --> 27:53.470 eigentlich gar nicht. 27:57.980 --> 28:00.600 Das heißt, wenn es eine Klausuraufgabe ist und wir haben nicht dran 28:00.600 --> 28:04.220 geschrieben, schreiben Sie das Ergebnis der Polynom-Division bitte 28:04.220 --> 28:04.700 auch hin. 28:05.600 --> 28:08.860 Was wir natürlich tun würden, wenn wir der Meinung sind, Sie haben zu 28:08.860 --> 28:09.240 viel Zeit. 28:09.520 --> 28:10.580 Dann können wir das weglassen. 28:10.700 --> 28:13.180 Sie können die Division einfach durchführen und brauchen das Ergebnis 28:13.180 --> 28:13.840 nicht berechnen. 28:13.900 --> 28:15.520 Sie können einfach nur noch den Rest suchen. 28:18.200 --> 28:18.680 Klar? 28:19.740 --> 28:21.140 Wir brauchen es nämlich nicht. 28:24.920 --> 28:27.620 Damit wir das ein bisschen einspielen, war es natürlich auf dem 28:27.620 --> 28:31.320 Übungsblatt, bitte das Ganze mit einem Fehlerfall vorzuführen und ohne 28:31.320 --> 28:32.060 einen Fehlerfall. 28:32.900 --> 28:34.180 Das sieht ja dann so aus. 28:34.280 --> 28:39.040 Der Empfänger erhält jetzt diese Bitfolge, wo wir vorhin den Rest 28:39.040 --> 28:42.200 drauf addiert haben, und teilt das genau wieder durch das gleiche 28:42.200 --> 28:45.460 Prüfpolynom, über das Sie sich natürlich einig sind, weil Sie das 28:45.460 --> 28:46.620 gleiche Verfahren verwenden. 28:48.720 --> 28:51.680 Wir haben natürlich vorhin den Rest drauf addiert, damit der Empfänger 28:51.680 --> 28:55.100 jetzt keinen Rest rauskriegt, wenn die Übertragung erfolgreich war. 28:56.380 --> 28:58.740 Das tut er hier also nicht, also geht er davon aus, dass die Daten 28:58.740 --> 28:59.880 sicher übertragen wurden. 29:01.080 --> 29:03.980 Wenn Sie in der Klausur jetzt hinschreiben, ja, die Daten waren also 29:03.980 --> 29:06.800 unverfälscht beim Empfänger angekommen, dann ist das streng genommen 29:06.800 --> 29:07.860 natürlich nicht richtig. 29:09.220 --> 29:13.180 In der Vorlesung haben wir eine ganze Latte an Angaben, welche Fehler 29:13.180 --> 29:15.200 man mit dem Verfahren jetzt alles erkennen kann. 29:17.140 --> 29:19.840 Das heißt mit der hohen Wahrscheinlichkeit, also auf jeden Fall 29:19.840 --> 29:23.620 mathematisch ist keiner dieser Fehler dann vorhanden, und mit einer 29:23.620 --> 29:27.220 hohen Wahrscheinlichkeit ist die Datenfolge dann natürlich auch 29:27.220 --> 29:28.320 unverfälscht angekommen. 29:29.880 --> 29:32.520 Ein Problem hätten wir natürlich noch, wenn wir jetzt ein Bit kippen, 29:33.040 --> 29:34.600 an diesem Beispiel einfach mal das 11. 29:34.740 --> 29:39.020 Bit, dann kriegen wir am Ende den Rest raus, haben also auf jeden Fall 29:39.020 --> 29:40.300 einen Übertragungsfehler erkannt. 29:40.640 --> 29:42.920 Und auch hier interessiert uns das Ergebnis eigentlich nicht. 29:48.270 --> 29:48.730 Alles klar? 29:54.460 --> 29:55.420 Sollte klar sein. 29:57.540 --> 29:57.900 Ja, bitte. 29:59.360 --> 30:00.020 Ein bisschen lauter. 30:07.200 --> 30:07.800 Was erstellen? 30:15.590 --> 30:18.170 Die Frage ist gerade, ob man natürlich auch die Fehler rekonstruieren 30:18.170 --> 30:18.470 kann. 30:19.970 --> 30:20.410 Nein. 30:22.490 --> 30:25.230 Also wir kriegen eine falsche Prüfsumme raus und müssen uns dann um 30:25.230 --> 30:26.810 eine neue Übertragung der Daten kümmern. 30:27.930 --> 30:29.990 Also wir haben nicht eine Matrix, wie z.B. 30:30.130 --> 30:34.210 wenn wir Quer- und Längsparität gleichzeitig machen, dass wir sagen 30:34.210 --> 30:36.050 können, der Fehler ist genau an einer Stelle passiert. 30:44.000 --> 30:44.440 Okay. 30:45.820 --> 30:46.040 Ja. 31:06.740 --> 31:09.460 Also geht auf die gleiche Frage hinaus, ob man es dann doch 31:09.460 --> 31:10.240 rekonstruieren kann. 31:10.240 --> 31:10.340 Nein. 31:26.510 --> 31:28.870 Also möchte ich mich trotzdem nicht darauf festlegen, dass wir das 31:28.870 --> 31:30.070 machen können, allein vom Rest. 31:32.430 --> 31:35.090 Ja, wenn ich den in einen anderen Fall gebe und mehr Fehler einbaue. 31:42.930 --> 31:44.630 Also in dem Fall kannst du es natürlich tun. 31:44.890 --> 31:47.450 Aber die Mathematik dahinter ist ein Stückchen komplexer. 31:47.550 --> 31:49.610 Ob es jetzt in jedem Fall funktioniert, dass ich jeden Einzelbit 31:49.610 --> 31:51.150 Fehler korrigieren kann, weiß ich nicht. 31:52.150 --> 31:52.490 Ja. 32:02.110 --> 32:04.010 Also klar, in dem Fall können wir uns darüber unterhalten. 32:04.010 --> 32:06.490 Aber wir könnten ein anderes Bit kippen lassen, dann würde es mit 32:06.490 --> 32:07.810 hoher Wahrscheinlichkeit nicht mehr funktionieren. 32:45.000 --> 32:46.980 Also wir tun es auf jeden Fall an dieser Stelle nicht. 32:47.200 --> 32:49.420 Also wir machen hier jetzt erstmal nur Fehlererkennung und keine 32:49.420 --> 32:51.140 Fehlerkorrektur mit dem CRC-Verfahren. 32:57.100 --> 32:58.620 Dann schauen wir uns weiterhin an. 32:58.880 --> 33:01.080 Da kommen jetzt eben ein paar Rechenaufgaben, die ein bisschen 33:01.080 --> 33:03.840 komplizierter waren, ein bisschen größere Zahlen hatten. 33:04.480 --> 33:07.680 Weil es in der einen Vorlesung so schön war, die Übertragungskapazität 33:07.680 --> 33:10.200 auf so einer Leitung, wollten wir das Ganze mal noch umgekehrt wissen. 33:10.560 --> 33:13.140 Wie lang so eine Leitung jetzt in diesem Fall zum Beispiel ist. 33:14.040 --> 33:15.900 Der Aufbau war klar vorgegeben. 33:16.200 --> 33:17.920 Wir haben also eine Leitung von A nach B. 33:19.320 --> 33:21.120 Die Übertragungsgeschwindigkeit ist angegeben. 33:21.220 --> 33:23.500 Ein paar andere Werte waren noch angegeben, wie zum Beispiel die 33:23.500 --> 33:24.720 Ausbreitungsgeschwindigkeit. 33:25.360 --> 33:32.760 Und zu jedem Zeitpunkt befinden sich jetzt 15,625 Gigabyte auf dieser 33:32.760 --> 33:33.200 Leitung. 33:34.320 --> 33:37.340 Mit allen Zahlen hier jeweils 10er Potenzen und keine 1024. 33:38.780 --> 33:42.540 Wie lang diese Leitung jetzt dann tatsächlich eigentlich ist. 33:45.420 --> 33:48.620 Auch hier zurück zu früherer Schulmathematik. 33:49.000 --> 33:52.760 Ganz simple Formeln, die Sie in der Klausur nicht unbedingt 33:52.760 --> 33:53.940 ausführlich entwickeln müssen. 33:54.060 --> 33:55.460 Das ist das Schöne an einer Informatikvorlesung. 33:56.540 --> 33:58.020 Wir machen es jetzt mal trotzdem ein bisschen. 33:58.180 --> 34:01.140 Sie können auch auf verschiedenen Wegen das natürlich rauskriegen. 34:01.220 --> 34:04.400 Sie können zuerst die Länge von dem Bit ausrechnen physikalisch und 34:04.400 --> 34:05.640 dann auf die Leitungslänge kommen. 34:06.660 --> 34:08.540 Ich gebe jetzt mal folgenden Weg vor. 34:08.840 --> 34:10.640 Die Datenrate, die wir natürlich haben. 34:11.160 --> 34:14.400 Eine Rate ist natürlich eine gewisse Datenmenge durch eine Zeit. 34:16.940 --> 34:19.700 Umgekehrt haben wir natürlich die Zeit, auf die ich gerade hinaus 34:19.700 --> 34:19.940 will. 34:23.410 --> 34:25.450 Sind dann natürlich die Daten durch die Rate. 34:27.130 --> 34:31.810 Hier haben wir jetzt als Datenmenge auf der Leitung 15,625 Gigabyte. 34:36.290 --> 34:37.160 Und haben als Übertragungsrate. 34:38.040 --> 34:40.400 Ich rechne schon mal ein bisschen um von Terabit. 34:40.920 --> 34:48.100 2.2500 Gigabit pro Sekunde. 34:48.380 --> 34:49.660 Und das ist die einzige Stelle. 34:49.800 --> 34:52.220 Passen Sie im Himmels Willen in der Klausur immer auf, haben wir Bit 34:52.220 --> 34:52.740 oder Byte. 34:53.620 --> 34:54.800 Ich wäre fast selber reingefallen. 34:54.920 --> 34:56.140 Ich falle auch oft selber rein. 34:56.220 --> 34:57.840 In der Klausur fallen viele Leute rein. 34:57.940 --> 34:59.040 Schauen Sie sich das genau an. 34:59.780 --> 35:01.720 Das können wir nämlich jetzt direkt noch nicht durchkürzen. 35:09.440 --> 35:13.600 So, das Ganze haben wir nämlich dann unten natürlich mal 8. 35:19.760 --> 35:21.260 Durch 8, Entschuldigung. 35:21.840 --> 35:23.780 Wie ich schon sage, passen Sie da im Himmels Willen auf. 35:29.650 --> 35:34.610 Ich komme auf eine Zeit von 0,05 Sekunden, die benötigt wird, um bei 35:34.610 --> 35:38.210 dieser Übertragungsrate die angegebene Datenmenge zu senden. 35:42.400 --> 35:46.460 So, das ist jetzt natürlich die Zeit, die dann auch vom Empfänger zum 35:46.460 --> 35:49.100 Sender vergehen muss, damit sich diese Daten stets auf der Leitung 35:49.100 --> 35:49.560 befinden. 35:50.720 --> 35:52.820 Das heißt, zurück zur Physik von früher. 35:54.000 --> 35:55.460 Geschwindigkeit ist Weg durch Zeit. 35:56.380 --> 35:58.220 Also ist der Weg Geschwindigkeit mal Zeit. 35:59.040 --> 36:04.940 Haben wir also die angegebenen 200.000 Kilometer pro Sekunde, mal die 36:04.940 --> 36:06.920 0,05 Sekunden von hier hinten. 36:09.180 --> 36:14.080 Komme ich auf eine Übertragungsleitung von 10.000 Kilometern. 36:16.320 --> 36:17.460 Hat jemand was anderes? 36:17.620 --> 36:17.720 Ja? 36:27.190 --> 36:29.030 Du willst auf relativistische Effekte hinaus. 36:30.130 --> 36:30.670 Nochmal was? 36:31.430 --> 36:31.870 Relativ? 36:32.750 --> 36:34.090 Ein bisschen lauter nur. 36:37.990 --> 36:40.390 Würdest du dir wünschen, dass du das in der Klausur tun musst? 36:50.170 --> 36:51.510 Also wenn, dann nur als Zusatzaufgabe. 36:51.510 --> 36:54.250 Nee, das beachten wir hier um Gottes Willen nicht. 37:04.510 --> 37:06.990 Alles überlassen wir den mehr Theoretikern. 37:08.470 --> 37:09.930 Wir machen uns ja hier in der Kommunikation und 37:09.930 --> 37:11.890 Datenhaltungsverwaltung eher so ein bisschen die Hände schmutzig und 37:11.890 --> 37:14.230 kümmern uns tatsächlich um Protokolle und effektive Timer. 37:15.230 --> 37:17.290 Das schieben wir tatsächlich in der Theorie irgendwelche 37:17.290 --> 37:18.410 relativistischen Effekte. 37:19.190 --> 37:23.250 Das Interessante an der Aufgabe ist noch, solche Leitungen gibt es 10 37:23.250 --> 37:24.070 .000 Kilometer. 37:24.690 --> 37:27.470 Praktisch eine Transatlantikleitung, reicht glaube ich nicht ganz von 37:27.470 --> 37:28.550 Frankfurt nach New York. 37:29.470 --> 37:32.770 Die Übertragungsrate an sich, Terabit-Bereich, ist auch realistisch. 37:34.010 --> 37:37.830 Das heißt, auch der Wert der Daten, die gleichzeitig auf der Leitung 37:37.830 --> 37:41.950 sind, 15 Gigabyte, ist ebenfalls im Bereich des Möglichen. 37:42.510 --> 37:45.450 Das heißt, wir haben also auf so einer Lichtleitphase von Frankfurt 37:45.450 --> 37:50.530 nach New York durchaus Datenmengen in diesem Bereich, die beim Router 37:50.530 --> 37:53.510 in Frankfurt schon gesendet wurden und beim Router in New York noch 37:53.510 --> 37:55.890 nicht angekommen sind, sondern einfach nur auf der Leitung sind. 37:56.810 --> 37:57.550 Interessante Sache. 37:58.610 --> 38:01.190 Könnte man anknüpfen an die Sache, die Frau Zitterbart vorhin in der 38:01.190 --> 38:03.990 Vorlesung erwähnt hat, dass Sie gar nicht viel Zeit haben im Router, 38:04.190 --> 38:06.530 die Entscheidung zu treffen für die Weiterleitung. 38:06.990 --> 38:09.190 Ansonsten brauchen Sie nämlich großzügig Pufferplatz. 38:10.030 --> 38:12.450 Wenn Sie jetzt sagen, Ihr Router hat ganz kurz Schluck auf, weil er 38:12.450 --> 38:15.310 eine neue Routing-Tabelle füllt und in dieser Zeit keine Weiterleitung 38:15.310 --> 38:18.630 machen kann, dann dauert es nur eine kurze Zeit und Ihnen laufen ganz 38:18.630 --> 38:22.150 gehörige Datenmengen ein, die Sie dann entweder puffern müssen oder 38:22.150 --> 38:22.970 die verloren gehen. 38:26.510 --> 38:27.330 Fragen hierzu? 38:30.170 --> 38:32.050 Wenn nicht, gehen wir gleich zur Rechenaufgabe. 38:33.470 --> 38:34.350 Zu Sequenznummern. 38:34.410 --> 38:36.910 Im Wesentlichen sollten Sie die eine Formel aus der Vorlesung 38:36.910 --> 38:39.010 anwenden, die nötigen Daten waren ja gegeben. 38:39.570 --> 38:40.790 Die Leitung ist ja auch gegeben. 38:42.570 --> 38:47.270 In der Vorlesung hatten wir als Bits für Frequenznummern eine untere 38:47.270 --> 38:47.910 Schranke auszurechnen. 38:52.660 --> 38:55.060 Das haben wir so gemacht, wenn wir die Bits gesucht haben, haben wir 38:55.060 --> 38:58.260 natürlich 2 hoch N und es musste größer gleich sein. 38:59.740 --> 39:09.820 2 mal die maximale Paketlebenszeit plus die Zeit, in der der Sender 39:09.820 --> 39:13.780 Daten gepuffert hat für eine Paketwiederholung, plus natürlich die 39:13.780 --> 39:19.360 Antwortzeit des Empfängers, bevor der Empfänger sie bestätigt hat und 39:21.300 --> 39:22.620 das Ganze mal die Datenrate. 39:22.740 --> 39:26.640 Die Datenrate in diesem Fall, abhängig davon möchten Sie Bytes in den 39:26.640 --> 39:28.460 Sequenznummern haben oder Pakete. 39:28.460 --> 39:30.180 Möglich ist natürlich beides. 39:30.260 --> 39:34.280 Wir haben vorhin in der Vorlesung gesehen von Frau Zitterbahn, bei TCP 39:34.280 --> 39:35.920 haben wir zum Beispiel eine Byte-Angabe. 39:36.560 --> 39:40.240 In dieser Aufgabe wollte ich auf die Pakete hinaus, das heißt die 39:40.240 --> 39:41.440 Datenrate in Paketen. 39:44.780 --> 39:47.280 Deswegen rechnen wir das natürlich jetzt zuerst mal um, was wir auf 39:47.280 --> 39:49.500 dieser Leitung tatsächlich für eine Paketrate haben. 39:53.360 --> 39:57.320 Wir möchten also R als Pakete pro Sekunde. 40:00.870 --> 40:11.790 Wir haben die 2,5 Terabit pro Sekunde und wir haben gesagt, 40:16.760 --> 40:19.600 pro Paket haben wir ein Kilobyte. 40:19.600 --> 40:23.780 Und an dieser Stelle habe ich Sie mal gebeten, nicht auf Paketheader 40:23.780 --> 40:24.660 oder ähnliches zu achten. 40:24.780 --> 40:26.560 Einfach ein Paket trägt jetzt mal ein Kilobyte. 40:26.600 --> 40:29.320 Wir schicken ein Kilobyte in jedem Paket mit. 40:31.820 --> 40:35.280 Und da kommen wir dann, wenn wir das auch wieder sauber ausrechnen, 40:36.220 --> 40:41.400 meiner Meinung nach auf eine ganz schöne Menge an Paketen pro Sekunde, 40:43.240 --> 40:44.400 nämlich diese Zahl. 40:45.800 --> 40:48.500 Also 312,5 Millionen Pakete pro Sekunde. 40:49.960 --> 40:52.980 Auch hier wieder achten Sie auf die Bits und auf die Bytes. 40:54.640 --> 40:58.900 Bei diesen Sachen können Sie sich für die Klausur auch gleich merken, 40:58.980 --> 41:01.860 wenn Sie irgendeine Datenrate gefordert haben und die sollen Sie 41:01.860 --> 41:05.800 angeben und wir geben Ihnen die Einheit nicht vor, dann brauchen Sie 41:05.800 --> 41:08.320 im Gotteswillen nicht noch einen Rechenschritt darauf verwenden, das 41:08.320 --> 41:11.120 in schöne Megabit pro Sekunde umzurechnen. 41:11.260 --> 41:13.760 Das heißt, eine Datenrate ist eine Datenmenge durch eine Zeit. 41:14.880 --> 41:20.080 Wenn Sie das angeben in klingonischen Hieroglyphen pro Woche, ist das 41:20.080 --> 41:20.760 eine Datenrate. 41:22.360 --> 41:24.840 Hätten wir also nichts dagegen zu sagen, wenn wir Ihnen nicht 41:24.840 --> 41:26.820 vorgegeben haben, in welcher Rate wir es haben möchten. 41:28.180 --> 41:30.400 Wenn wir Sie bei der Korrektur dabei erwischen, dass Sie es 41:30.400 --> 41:33.240 absichtlich in klingonische Hieroglyphen pro Woche umrechnen, um uns 41:33.240 --> 41:35.620 Arbeit zu machen, dann lächeln wir darüber natürlich herzlich. 41:35.780 --> 41:37.860 Sorgen aber im Gegensatz dafür, dass natürlich auch Sie 41:37.860 --> 41:38.940 Unannehmlichkeiten haben. 41:40.960 --> 41:41.760 Nee, Spaß beiseite. 41:41.920 --> 41:44.160 Also sprich, wenn Sie in irgendeiner Datenrate enden und das ist jetzt 41:44.160 --> 41:46.320 Kilobyte pro Stunde, lassen Sie es so. 41:46.960 --> 41:49.220 Probieren Sie nicht, da schöne Megabit draus zu machen, außer Sie 41:49.220 --> 41:50.840 brauchen es natürlich für eine Folgeaufgabe. 41:52.280 --> 41:56.820 In diesem Fall haben wir 312,5 Millionen Pakete pro Sekunde, können es 41:56.820 --> 42:01.840 also alles, die ganzen Werte hier unten einfügen. 42:04.340 --> 42:11.820 Haben also hier 0,1 Sekunden, eben zweimal die Laufzeit aus der 42:11.820 --> 42:13.120 Aufgabe A. 42:14.000 --> 42:18.860 Haben hier 0,5 Sekunden, hier 0,5 Sekunden und hier die Paketrate von 42:18.860 --> 42:19.300 hier oben. 42:20.460 --> 42:28.300 Dann kam ich auf eine Ungleichung mit folgenden Ergebnis. 42:44.160 --> 42:46.760 Die Tatsache, dass Sie Gleichungen, die Sie verwenden, nicht wirklich 42:46.760 --> 42:49.540 sauber entwickeln müssen, wie es in irgendwelchen früheren, als wir 42:49.540 --> 42:53.300 die Hochschulreife noch erworben haben, Klausuren der Fall war, sagt 42:53.300 --> 42:54.780 mir, dass wir allzu schlampig sein dürfen. 42:54.940 --> 42:57.300 Also probieren Sie zumindest Einheiten sauber mitzuziehen. 42:57.860 --> 42:59.400 Ansonsten sind es ganz klar Rechenfehler. 43:01.680 --> 43:05.540 Sprich, schreiben Sie nicht irgendeine Skalareinheit hin ohne Einheit 43:05.540 --> 43:07.940 und am Ende beim Ergebnis einfach noch die Einheit dazu, sondern 43:07.940 --> 43:09.400 ziehen Sie wenigstens die sauber mit. 43:12.140 --> 43:14.280 So, wann ist das jetzt der Fall? 43:14.400 --> 43:15.540 Die Mathematik da dahinter. 43:28.990 --> 43:30.510 Das stimmt ganz genau. 43:38.560 --> 43:41.460 Das ist ganz genau richtig, da müssen wir uns auf jeden Fall vorher 43:41.460 --> 43:41.940 festlegen. 43:42.100 --> 43:44.940 Wir möchten jetzt die Pakete nummerieren, brauchen also, wenn wir es 43:44.940 --> 43:48.020 mit einer Binärzahl machen wollen, eine gewisse Anzahl Bits. 43:48.020 --> 43:49.660 Wie groß ist die? 43:50.580 --> 43:58.710 Ich sage Ihnen mal ganz kurz, 2 hoch 28 sind so knapp 270 Millionen. 44:03.210 --> 44:08.310 2 hoch 29 sind dann natürlich das Doppelte. 44:12.830 --> 44:14.350 So, wie viel Bit brauchen wir jetzt? 44:21.560 --> 44:24.140 Wir brauchen also mindestens 29 Bit. 44:25.020 --> 44:27.240 Das Ganze können wir auch noch mathematisch machen, wenn wir 44:27.240 --> 44:30.560 Logarithmus auf beiden Seiten nehmen, in der Ungleichung jeweils das N 44:30.560 --> 44:31.080 vor 10. 44:31.580 --> 44:33.160 Wollte ich Sie jetzt auch noch mit belästigen. 44:35.180 --> 44:37.980 Bei der Aufgabe sollten Sie sich fragen, was mache ich, wenn so etwas 44:37.980 --> 44:38.900 in der Klausur drankommt. 44:41.040 --> 44:44.380 Wir wären vermutlich höflich und würden natürlich die Größen und die 44:44.380 --> 44:46.820 Zahlen weitaus schöner, einfacher und kleiner machen. 44:47.460 --> 44:49.940 Das machen wir immer davon abhängig, wie höflich Sie als Publikum 44:49.940 --> 44:50.140 waren. 44:50.140 --> 44:56.320 Insofern Spaß beiseite. 44:56.740 --> 44:59.560 Die ganze Sache wird natürlich so nicht geschehen, weil wir das ohne 44:59.560 --> 45:01.000 Taschenrechner wirklich nicht fordern. 45:01.280 --> 45:04.700 Aber in kleineren Versionen möglicherweise. 45:06.480 --> 45:08.600 Wobei lernen Sie zum Himmels Willen nicht nur solche Dinge. 45:08.980 --> 45:10.400 Haben Sie noch Fragen hierzu? 45:14.220 --> 45:17.420 Wenn nicht, gehen wir eins weiter und kümmern uns noch um ein 45:17.420 --> 45:19.220 Wegzeitdiagramm beim Sliding Window. 45:20.540 --> 45:21.880 Wir sind bald durch. 45:22.020 --> 45:23.960 Die nächste Aufgabe ist dann nicht mehr so kompliziert. 45:25.520 --> 45:28.740 Bei der würde ich Sie noch bitten, ein bisschen aufmerksam zu sein, 45:28.820 --> 45:30.160 weil die nochmal interessant wird. 45:34.320 --> 45:37.860 Ich habe es probiert, das Ganze so missverständnisfrei wie möglich zu 45:37.860 --> 45:38.460 formulieren. 45:38.720 --> 45:41.960 Wir haben gesagt, wir haben einen Kredit von 3 und maximal 5 45:41.960 --> 45:42.220 Sequenznummern. 45:42.920 --> 45:45.980 Normalerweise wird es auch angegeben als maximale Sequenznummer 5. 45:46.200 --> 45:47.080 Das fand ich nicht so gut. 45:47.080 --> 45:49.500 Weil wenn wir von 0 bis 5 zählen, haben wir eigentlich wieder 6. 45:50.360 --> 45:52.840 Also ich habe gesagt, 5 maximale Sequenznummern haben wir. 45:53.420 --> 45:55.960 Und ich habe ein Beispiel gesucht, an dem das Ganze dann durcheinander 45:55.960 --> 45:56.420 gerät. 45:56.760 --> 45:59.220 Wenn man es sich ein bisschen durchgedacht hat, ein paar Fehlerfälle 45:59.220 --> 46:02.680 ausgerüttelt hat, konnte man meiner Meinung nach drauf kommen. 46:02.740 --> 46:06.440 In der Vorlesung haben wir eine Notation gehabt, die habe ich Ihnen 46:06.440 --> 46:09.040 hier unten wieder aufgeschrieben, damit man es mal durchexerzieren 46:09.040 --> 46:09.300 könne. 46:10.480 --> 46:15.120 Wir haben unser Sliding Window angegeben als umlaufende Uhr. 46:16.340 --> 46:20.100 Klar, man kann es natürlich auch angeben als Sliding Window 46:20.100 --> 46:21.040 Horizontal. 46:22.320 --> 46:27.400 Wir haben mal hier die Sequenznummer 0, 1, 2, 3, 4. 46:28.020 --> 46:31.440 Und die 5, wenn wir maximal 5 Sequenznummern haben, war Ihnen auch 46:31.440 --> 46:33.360 klar, entspricht natürlich wieder der 0. 46:35.900 --> 46:36.340 So. 46:38.360 --> 46:39.920 Und der Sender steht am Anfang. 46:42.420 --> 46:46.500 Sagen wir mal, da das S die Nummer ist der zuletzt gesendeten 46:46.500 --> 46:49.420 Dateneinheit und er jetzt mit dem Senden beginnen möchte, steht er 46:49.420 --> 46:52.260 jetzt mal auf 4, weil er wieder bei der 0 anfangen wird. 46:53.340 --> 46:56.780 Und sein Kredit ist 3, das heißt er darf bis zur Sequenznummer 2 46:56.780 --> 46:57.140 senden. 46:57.260 --> 47:00.220 Er darf also maximal 3 unbestätigte Datenpakete übertragen. 47:03.810 --> 47:05.750 Das tut er jetzt einfach auch mal. 47:06.110 --> 47:08.610 Da er auf nichts warten muss, kann er die auch der Reihe nach los 47:08.610 --> 47:09.150 übertragen. 47:17.440 --> 47:21.520 So, und die Datenpakete tragen dann natürlich als Data die 47:21.520 --> 47:26.220 Sequenznummer jeweils, hier die 0, hier die 1 und dieses hier 47:26.220 --> 47:29.500 natürlich entsprechend die Sequenznummer 2. 47:30.700 --> 47:33.920 So, wie sieht das dann aus beim Sender? 47:35.680 --> 47:38.340 Was hat der Sender jetzt für einen Eindruck vom Sliding Window? 47:39.000 --> 47:39.760 An dieser Stelle. 47:49.060 --> 47:50.520 So, bis wohin hat er gesendet? 47:50.600 --> 47:52.340 Was war die zuletzt gesendete Dateneinheit? 47:53.660 --> 47:57.100 Die 2, sein Kredit ging auch nur bis zur 2, solange er noch nichts vom 47:57.100 --> 47:59.760 Empfänger gehört hat, das heißt beim Sender haben wir diesen Fall. 48:00.860 --> 48:02.820 Er hat also einfach sein Kredit jetzt ausgeschöpft. 48:06.290 --> 48:09.110 So, gehen wir mal auf Empfängerseite, und zwar auf Empfängerseite beim 48:09.110 --> 48:10.930 Anbeginn dieses Beispiels. 48:12.290 --> 48:14.810 Der Empfänger hat natürlich das gleiche umgekehrt. 48:16.430 --> 48:19.430 Er erwartet gewisse Datenpakete zu gewissen Zeiten. 48:23.580 --> 48:28.200 R ist also bei ihm die nächste erwartete Sequenznummer, da erwartet er 48:28.200 --> 48:28.880 natürlich die 0. 48:30.140 --> 48:35.380 Und auch er hat natürlich einen Kredit, er lässt sich maximal 3 48:35.380 --> 48:38.540 Datenpakete vom Empfänger schicken ohne Quittung. 48:41.200 --> 48:43.540 So, wie sieht das Ganze aus, nachdem wir es jetzt... 48:45.040 --> 48:46.980 Ja, wir kriegen viele Pfeile in das Diagramm. 48:47.940 --> 48:50.560 Das war jetzt der Punkt, bevor irgendwelche Daten übertragen wurden. 48:51.980 --> 48:53.880 So, jetzt sind die 3 Daten angekommen. 48:55.280 --> 48:56.600 Dann sieht das Ganze so aus. 48:59.320 --> 49:00.680 Was wird wohl passiert sein? 49:02.440 --> 49:06.300 Den Kredit hat er noch nicht weiter geschoben, das heißt der Kredit 49:06.300 --> 49:07.320 steht immer noch bei 2. 49:08.540 --> 49:11.540 Allerdings hat er natürlich jetzt die 2 auch empfangen, das heißt sein 49:11.540 --> 49:15.520 zuletzt empfangenes Datenpaket R hat er natürlich jetzt auch dahin 49:15.520 --> 49:16.960 weiter geschoben. 49:19.680 --> 49:20.080 Ja... 49:26.550 --> 49:27.910 Das dachte ich steht da unten. 49:28.770 --> 49:29.170 Ja, 49:34.120 --> 49:35.620 da wollte ich jetzt gerade weiter hinaus. 49:41.660 --> 49:44.260 Machen wir das R mal hier weg, ich wollte nämlich gleich das nächste 49:44.260 --> 49:45.020 zeichnen, das stimmt. 49:47.100 --> 49:50.820 So, jetzt wird er natürlich, kommen wir gleich dazu, die Daten 49:50.820 --> 49:51.400 bestätigen. 49:52.180 --> 49:54.200 Weil sein Kredit voll ist, wird er sowieso tun. 49:54.200 --> 50:05.050 So, das heißt er schickt jetzt an dieser Stelle ein Acknowledgement. 50:07.250 --> 50:12.230 In das Acknowledgement schreibt er, dass er als nächstes ganz genau 50:12.230 --> 50:13.310 die 3 erwartet. 50:14.030 --> 50:17.950 Bestätigt also implizit die davor liegenden, nämlich 0, 1 und 2. 50:20.130 --> 50:21.670 Dann haben wir diesen Fall. 50:24.610 --> 50:26.590 Dann müssen wir es aber gleich ganz weiter schieben. 50:31.150 --> 50:36.470 So, das heißt er erwartet jetzt als nächstes die 3 und schiebt 50:36.470 --> 50:39.470 natürlich auch den Kredit dann weiter, nämlich wieder hoch bis zur 0. 50:40.290 --> 50:40.570 Klar? 50:42.650 --> 50:45.210 Er hat dem Empfänger diese Daten jetzt bestätigt, er hat sie auch 50:45.210 --> 50:48.130 verarbeitet empfangen, schiebt also seinen Empfangspuffer wieder 50:48.130 --> 50:48.490 weiter. 50:50.250 --> 50:52.730 Das heißt hier haben wir bei der 3 und hier haben wir natürlich bei 50:52.730 --> 50:53.070 der 0. 50:53.930 --> 50:56.270 So, und jetzt gehen wir mal davon aus, und das ist genau der 50:56.270 --> 50:59.650 Fehlerfall, auf den wir hier hinaus wollen, dass dieses Eck hier 50:59.650 --> 51:03.250 aufgrund von irgendwelchen Laufzeitschwankungen verzögert ist. 51:04.190 --> 51:09.950 Und zwar so lang verzögert, bis beim Empfänger irgendwann er 51:09.950 --> 51:12.310 ungeduldig wird und sein Timeout zuschlägt. 51:16.460 --> 51:19.340 Weil er eben noch nichts vom Empfänger gehört hat. 51:19.460 --> 51:20.640 Das Eck ist noch nicht angekommen. 51:23.220 --> 51:26.700 Das heißt er geht natürlich dann hin, so ungeduldig wie er ist, und 51:26.700 --> 51:28.200 schickt genau die gleichen Daten nochmal. 51:35.300 --> 51:38.580 Er schickt alle 3 natürlich nochmal, wobei die letzten 2 für uns in 51:38.580 --> 51:41.160 diesem Beispiel mal gar nicht interessant sind. 51:46.110 --> 51:48.390 So, aber ohne dass ich jetzt einen Pfeil einzeichnen würde in dem 51:48.390 --> 51:50.090 Diagramm, weil es dann noch umständlicher wird. 51:50.570 --> 51:53.150 Es ist klar, das ist jetzt das gleiche Datenpaket, wie ganz oben 51:53.150 --> 51:54.290 zuallererst gesendet wurde. 51:54.510 --> 51:55.470 Also eine Wiederholung. 52:02.890 --> 52:03.530 So, 52:07.310 --> 52:09.430 jetzt trägt das Datenpaket die 0. 52:10.650 --> 52:13.170 Entspricht also auch gleich der Sendesequenznummer des 5. 52:13.290 --> 52:16.070 Paketes, mal via Modulo rechnen. 52:17.250 --> 52:27.960 Das heißt der Empfänger akzeptiert das jetzt ganz glücklich als DTS 5, 52:29.080 --> 52:30.760 worauf ich ja schon in der Aufgabe hinwollte. 52:33.900 --> 52:36.500 Das ist nicht gesagt, er braucht es nicht notwendigerweise in der 52:36.500 --> 52:37.300 Reihenfolge erwarten. 52:37.500 --> 52:39.940 Er kann ja davon ausgehen, dass zum Beispiel die 3 und die 4 verloren 52:39.940 --> 52:40.260 gingen. 52:42.960 --> 52:49.060 So, jetzt trifft aber schlussendlich die Bestätigung ein beim Sender. 52:50.920 --> 52:54.420 Und der Sender weiß natürlich jetzt nicht genau, was beim Empfänger 52:54.420 --> 52:54.840 geschehen ist. 52:54.940 --> 52:58.060 Er weiß nur, er bestätigt jetzt noch von vorhin den korrekten Empfang 52:58.060 --> 52:59.140 der ersten 3 Pakete. 52:59.140 --> 53:02.060 Schickt also jetzt auf jeden Fall die nächsten. 53:08.780 --> 53:12.600 So, das wäre jetzt dann hier das Data S gleich 3. 53:14.460 --> 53:16.840 Und das Data S gleich 4. 53:18.080 --> 53:21.780 Und dann das, was er als S gleich 5 ansieht. 53:22.860 --> 53:25.620 So, und das sind jetzt genau die zwei, die hier noch fehlen. 53:30.150 --> 53:33.190 Das heißt, er wird jetzt glücklicherweise akzeptieren als seine 53:33.190 --> 53:35.610 vermissten 3 und 4. 53:36.190 --> 53:37.410 Und akzeptiert 53:42.050 --> 53:54.510 auf den Fall, auf den ich hinaus will, dass einfach dieses Paket hier 53:54.510 --> 54:01.130 unten jetzt als Tube erkannt wird und weggeworfen wird. 54:01.430 --> 54:03.770 Und wenn das Protokoll jetzt so weiterläuft, haben wir ein kaputtes 54:03.770 --> 54:06.190 Datenpaket im Datenstrom, ohne dass wir das erkannt haben. 54:09.610 --> 54:11.130 Solche Fälle können dann auftreten. 54:11.130 --> 54:12.410 Was haben wir natürlich jetzt hier gemacht? 54:12.490 --> 54:14.970 Wir haben natürlich die Sequenznummer und das Kreditfenster so 54:14.970 --> 54:16.650 gewählt, dass dieser Fall auftreten kann. 54:17.230 --> 54:19.390 Wir hätten also hier offensichtlich ein Problem erzeugt dadurch. 54:27.390 --> 54:29.910 Spielen Sie es nochmal durch, wenn Sie es... 54:31.390 --> 54:32.030 Ja, bitte. 54:47.330 --> 54:48.350 Ja, tun Sie nicht. 54:48.590 --> 54:50.630 Wir haben im Medium an sich keine Umordnung. 54:55.090 --> 54:55.490 Also... 55:02.760 --> 55:05.640 Ja, da würde ich eher... ich schiebe es auf die Aufgabenstellung. 55:06.360 --> 55:10.300 Das Medium an sich tut das Paket in der Reihenfolge nicht verändern. 55:10.660 --> 55:14.340 Aber okay, es war nicht ausgeschlossen, dass der Empfänger diesen Fall 55:14.340 --> 55:15.960 behandeln muss. 55:16.320 --> 55:18.520 Also, dass es für ihn möglich ist, stimmt, ja. 55:25.710 --> 55:26.730 Noch Fragen dazu? 55:35.460 --> 55:37.400 Wenn Ihnen noch welche einfallen, können wir nochmal dahin 55:37.400 --> 55:37.920 zurückgehen. 55:38.520 --> 55:40.080 Ansonsten die D-Aufgabe. 55:41.000 --> 55:43.140 Was für einen Nachteil hätte es denn jetzt, wenn wir das Sliding 55:43.140 --> 55:46.600 Window gleichzeitig zur Flusskontrolle verwenden, wenn also praktisch 55:46.600 --> 55:50.180 der Sender sehr viele Pakete an den Empfänger schickt und der 55:50.180 --> 55:55.000 Empfänger jetzt sagt, ja, ich bin jetzt hier aber voll und warte jetzt 55:55.000 --> 55:58.040 hier eine gewisse Zeit lang einfach, bis ich mein Acknowledgement 55:58.040 --> 55:58.360 schicke. 56:00.000 --> 56:01.320 Ganz einfaches Problem. 56:05.040 --> 56:06.160 Warum hilft uns das nicht? 56:06.300 --> 56:06.400 Ja. 56:09.160 --> 56:11.540 Dann haben wir das Problem, dass er natürlich ein Timeout kriegt und 56:11.540 --> 56:13.040 er würde die Daten natürlich nochmal schicken. 56:13.660 --> 56:15.840 Also sprich, wenn man das nicht sorgfältig aufeinander abstimmen 56:15.840 --> 56:17.500 würde, würde das auf jeden Fall nicht funktionieren. 56:23.250 --> 56:25.730 So, dann machen wir einen Sprung und würden noch zu lokalen Netzen 56:25.730 --> 56:26.030 gehen. 56:26.310 --> 56:30.010 Kleiner Unterschied, ein paar Merkmale von Ethernet und Token Ring, 56:30.090 --> 56:31.330 die Beispiele aus der Vorlesung. 56:32.630 --> 56:35.430 Wie können wir denn bei Datenpaketen, zum Beispiel in dem Ethernet, 56:37.210 --> 56:40.230 wenn wir das Ganze zum Beispiel mal als Buß haben, wobei es ja 56:40.230 --> 56:43.090 heutzutage meistens kein Buß mehr ist, interessanterweise immer noch 56:43.090 --> 56:44.850 in der Vorlesung so oft so schön aufgemalt. 56:46.590 --> 56:50.010 Wenn wir jetzt hier Daten schicken, wie könnte die Quittung von 56:50.010 --> 56:51.030 solchen Daten geschehen? 56:53.150 --> 56:56.790 Wenn ich hier von A nach B schicke, wie wir die Quittung erfolgen 56:56.790 --> 56:57.110 müssen? 56:59.210 --> 57:02.110 Genau, muss B natürlich eine Quittung zu A schicken. 57:02.970 --> 57:05.250 Also auf jeden Fall wollten wir darauf hinaus eben als 57:05.250 --> 57:06.290 Extradatenpaket. 57:10.090 --> 57:13.090 Wenn wir bei Ethernet darauf hinaus wollten als Extradatenpaket, 57:13.190 --> 57:15.150 können Sie sich bei Token Ring gleich vorstellen, auf was wir 57:15.150 --> 57:15.850 hinauswollten. 57:16.830 --> 57:22.370 Wenn wir einen Token Ring haben, schickt es von A nach B eine gewisse 57:22.370 --> 57:23.050 Menge Daten. 57:23.510 --> 57:24.850 Wie kann die Quittung hier erfolgen? 57:31.430 --> 57:35.770 Genau, also er kann auf jeden Fall das on the fly erledigen, weil er 57:35.770 --> 57:38.690 bei den Daten hinten anhängen kann, dass er die Daten erfolgreich 57:38.690 --> 57:39.330 kopiert hat. 57:41.270 --> 57:41.990 Allen klar. 57:46.230 --> 57:49.550 Welches der beiden Netze wäre denn prinzipiell für den Realzeitbetrieb 57:49.550 --> 57:50.150 geeignet? 57:55.260 --> 57:56.560 Was macht uns denn Sorgen? 57:56.740 --> 58:00.660 Beim Realzeitbetrieb haben wir die Anforderungen, wir müssen in 58:00.660 --> 58:05.020 garantierten Zeiten, mögen sie auch noch so groß sein, aber wir 58:05.020 --> 58:07.620 brauchen Garantien, wann wir Daten übertragen haben können. 58:08.120 --> 58:09.520 Haben wir die Möglichkeit beim Ethernet? 58:13.720 --> 58:16.880 Was kann uns passieren, wenn wir Daten ans Ethernet loswerden wollen? 58:17.000 --> 58:18.360 Was für ein Zugangsverfahren haben wir? 58:29.160 --> 58:33.100 Gut, aber selbst in dem Fall könnten wir ja sagen, was passiert dann 58:33.100 --> 58:35.300 nach einer Kollision, wenn der Timer zuschlägt? 58:37.840 --> 58:38.240 Genau. 58:39.140 --> 58:39.700 Probieren wir es nochmal. 58:58.760 --> 59:04.300 Wir haben aufgrund dieser Möglichkeit, dass endlose Kollisionen 59:04.300 --> 59:05.240 möglich sind, ist Ihnen klar. 59:05.400 --> 59:08.880 Wir haben CSMA CD als Zugangsverfahren, wir senden drauf los, schauen 59:08.880 --> 59:10.440 ob eine Kollision stattgefunden hat. 59:10.520 --> 59:12.420 Wenn nicht, probieren wir es nochmal nach gewissen Zeiten. 59:13.720 --> 59:16.160 Wir haben aber das Problem, dass es endlos passieren kann. 59:16.280 --> 59:18.280 Das heißt, es kann mir passieren, dass ich mein Datenpaket überhaupt 59:18.280 --> 59:19.140 nicht loskriege. 59:19.580 --> 59:22.160 Natürlich muss da ein gehöriges Stück Zufall eine Rolle spielen, aber 59:22.160 --> 59:22.920 es kann geschehen. 59:23.820 --> 59:26.340 Ich habe also keine Garantien möglich für den Echtzeitbetrieb. 59:28.260 --> 59:29.600 Was haben wir bei Token Ring? 59:37.750 --> 59:43.150 Bei Token Ring ist das im Gegensatz dazu, ist hier ein Realzeitbetrieb 59:43.150 --> 59:43.910 für uns möglich. 59:45.150 --> 59:53.390 Und zwar, aufgrund des umlaufenden Senderechtes, können wir hier fast 59:53.390 --> 59:56.230 sogar ausrechnen, wollen wir jetzt hier nicht tun, aber wir könnten 59:56.230 --> 59:58.810 sogar ausrechnen, wie lange es im schlimmsten Fall dauern kann, bis 59:58.810 --> 59:59.830 ich Daten übertragen kann. 59:59.830 --> 01:00:04.030 Und das ist genau die Forderung, die wir fordern beim Realzeitbetrieb. 01:00:04.650 --> 01:00:14.630 Wir könnten also die Anzahl Sender nehmen, die Tokenumlaufzeit und die 01:00:14.630 --> 01:00:19.630 Sendezeit von den Sendern und könnten praktisch ausrechnen, wie lange 01:00:19.630 --> 01:00:21.770 wir eigentlich bräuchten, bevor wir an der Reihe sind. 01:00:21.950 --> 01:00:23.910 Möchte ich jetzt hier nicht tun, muss Ihnen nur klar sein. 01:00:25.150 --> 01:00:28.570 Selbst wenn ich der Letzte an der Reihe bin, ich habe gerade gesendet, 01:00:28.630 --> 01:00:31.150 kann ich sagen, es gibt eine obere Schranke, wann ich wieder dürfte. 01:00:31.150 --> 01:00:36.970 Das ist der entscheidende Unterschied vom Tokenring zum Ethernet. 01:00:37.690 --> 01:00:40.550 Worin liegt der grundlegende Unterschied der beiden Typen beim 01:00:40.550 --> 01:00:41.590 Anschluss an das Medium? 01:00:45.680 --> 01:00:47.140 Wie sind wir beim Ethernet angeschlossen? 01:00:47.560 --> 01:00:50.480 Und zwar egal, ob wir einen Stern haben oder einen Bus. 01:00:55.210 --> 01:00:58.390 Der richtige Ausdruck heißt passiv, also wir lauschen nur, wir hängen 01:00:58.390 --> 01:01:00.590 uns einfach hin und bekommen dann die Datenpakete mit. 01:01:01.070 --> 01:01:03.310 Wir splitten aber den Ring oder den Bus nicht auf. 01:01:04.850 --> 01:01:06.770 So, wie sind wir beim Tokenring angeschlossen? 01:01:08.390 --> 01:01:14.090 Wenn das eine passiv ist, haben wir hier einen aktiven Anschluss. 01:01:14.610 --> 01:01:17.250 Das heißt streng genommen, weil wir ja die Daten vom Ring nehmen 01:01:17.250 --> 01:01:21.190 müssen, nehmen können müssen und verändern können müssen, haben wir 01:01:21.190 --> 01:01:22.130 hier so eine Art Schalter. 01:01:23.830 --> 01:01:31.720 Das heißt, wenn ich meinen Teilnehmer anschließen möchte, dann würde 01:01:31.720 --> 01:01:37.300 er den Schalter praktisch öffnen und sich aktiv in den Ring einhängen. 01:01:37.400 --> 01:01:39.840 Die Chefin hat es erzählt, wir wollten mal noch schauen, ob wir noch 01:01:39.840 --> 01:01:40.720 solche Hardware haben. 01:01:40.840 --> 01:01:44.120 Frühere Tokenring-Anschlüsse hatten dann tatsächlich so eine ganze 01:01:44.120 --> 01:01:45.100 Batterie Relais drin. 01:01:45.160 --> 01:01:46.840 Wenn man es eingeschickt hat, hat es dann schön geklickert. 01:01:47.280 --> 01:01:50.340 Ich nehme eigentlich an, dass Spätere das so gemacht haben, weiß es 01:01:50.340 --> 01:01:52.960 nicht genau, dass man sich angeschlossen hat und sie haben den Ring 01:01:52.960 --> 01:01:55.900 dann getrennt und jeweils angeschlossen, wenn halt gerade keine Daten 01:01:55.900 --> 01:01:58.340 flossen, also dass es dann auch problemlos funktioniert hat. 01:01:59.120 --> 01:02:01.580 Wenn nicht, kann Ihnen natürlich passieren, was in diesem Comic 01:02:01.580 --> 01:02:02.340 dargestellt ist. 01:02:02.340 --> 01:02:04.100 Ich danke für Ihre Aufmerksamkeit. 01:02:04.200 --> 01:02:05.820 Ich wünsche ein gutes Mittagessen. 01:02:06.480 --> 01:02:08.280 Die nächste Übung ist erst in zwei Wochen. 01:02:09.640 --> 01:02:11.880 Dafür müssen wir leider nächste Woche Freitag so ein bisschen länger 01:02:11.880 --> 01:02:12.520 Vorlesungen machen. 01:02:12.620 --> 01:02:14.120 Frau Zitterbart hat es schon angekündigt. 01:02:14.780 --> 01:02:15.200 Bis dann.