Klausurvorbereitung

Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.

Klausurvorbereitung
Kann mir jemand Folie 117 von Transportschicht erklären?

Ist ein Paket hier gleichbedeutend mit Segment? Sind das auf Empfängerseite dann auch Segmente? Kann ja irgendwie nicht sein, weil die 15 bzw. 11 Byte groß sind und allein der TCP Header braucht ja schon 20 Byte.

Ich werd daraus irgendwie nicht ganz schlau.


Also ich hab mir das so erklärt (soweit ich mich erinnern kann, Prof. German in der Vorlesung auch), dass das eher ein qualitatives Beispiel für die Fenster, als ein quantitatives ist.
Sonst wären die Pakete (Segmente) wirklich zu klein.


Dann häng ich gleich noch eine Frage dran:

Wie darf ich die Antwort auf die Zusatzfrage (Seite 2, http://www7.informatik.uni-erlangen.de/~eckert/teaching/rechnerkommunikation-ss10/klausur/k-2008-09---a2.lsg.pdf) verstehen?
Die passt hier doch nicht wirklich hin, da das Advertized Window immer noch größer als MSS ist, oder?


Es ist doch gar kein MSS angegeben! Damit kannst du doch nicht sagen dass Advertized Window immer größer als MSS => Antwort: B muss erst MSS checken stimmt doch.


Laut Angabe soll man ja davon ausgehen, dass A immer nur 500 Byte sendet.
Der Defaultwert bei TCP ist 536 Byte und auch das würde noch reinpassen.

Zumal die Sondensegmente ja erst (laut Folien) nach AdvertizedWindow = 0 gesendet werden, was hier ja offensichtlich nicht zutrifft.


eine Frage zur Klausur SS 2007, Aufgabe 5. Da gehts um RTS /CTS austausch gemäß IEEE 802.11

Beide Stationen soll gleichzeitig senden, dh nach DIFS senden beide Seiten ihren RTS. Aber was passiert dann? Warten beide Seiten auf das CTS und gehen nach dem Timeout in den Backoff? Oder gehen die Sender sofort in den Backoff nachdem die RTS Kollision erkannt wurde? Werde aus dem Skript leider nicht schlau…


Ich habe im Script gefunden, dass RTS mittels Basic Access ausgetauscht wird.

D.h. wenn beide exakt gleichzeitig senden: beide warten ein DIFS, gehen in transmission, warten auf CTS (sollte nie kommen). Timeout => backoff, DIFS & counting down => irgend einer ist früher fertig und sendet erneut RTS, bekommt’s dieses mal bestätigt (CTS) und darf dann seine eigentlichen Daten senden.


Hab eine Verständnisfrage zu einer Theorieaufgabe der März-Klausur 08.

Frage: “i) (2 Punkte) Welches echtzeitfähige Medienzugriffsverfahren kennen Sie? Begründen Sie Ihre Antwort.”

In den Folien hab ich nur zum TokenRing das Stichwort “echtzeitfähig” gelesen, kann mir aber gar nicht erklären wieso das in Echtzeit funktionieren sollte. Immerhin werden beim Tokenring einige Knoten des Rings vom Senden blockiert, bis das freie Token letztendlich bei Ihnen angekommen is, das widerspricht dem was ich als echtzeitfähig definieren würde.
Drum meine Frage, was genau echtzeitfähigkeit beim Medienzugriff zu bedeuten hat, und ob der Tokenring wirklich das einzige Verfahren ist das echtzeitfähig ist. Wär nett wenn mir dazu wer was sagen könnte, thx.


Bei Token Ring darf ein einzelner Teilnehmer nicht beliebig lange senden, sondern muss den Token nach einer Zeit X wieder weitergeben. Deshalb lässt sich eine maximale Schranke festlegen, die ein Knoten warten muss bis er die Sendeerlaubnis (wieder) erhält.
Bei Y Teilnehmern am Bus entspricht die dann (Y-1) * X bis der Token im schlechtesten Fall (alle anderen senden die maximal erlaubte Zeit) wieder bei ihm angekommen ist. So kann eine sichere Garantie für die maximale Zeit gegeben werden, bis die Nachricht erfolgreich übermittelt wird → Echtzeitfähig.

Bei anderen Medienzugriffsverfahren, wie ALOHA oder CSMA lässt sich eine solche Schranke nicht festlegen da ein potentieller Sender, wenn auch äußerst unwahrscheinlich, durch Kollisionen mit anderen Teilnehmern beliebig lang an der erfolgreichen Nachrichtenübermittlung gehindert werden könnte. Damit sind diese Verfahren nicht Echtzeitfähig.

Klar soweit? :slight_smile:


ja das klärt so einiges, danke dir :slight_smile:


Hätte da noch ne Frage zur TCP-FlowControl:

Und zwar is mir nich ganz klar was passiert falls EffectiveWindow und/oder AdvertizedWindow zu klein geworden sind. Ich hab mir Aufgabe 2) der September 08 Klausur angeschaut, und auch die Musterlösung studiert. Hier tritt letzendlich die Situation ein, dass das Effective-Window = 0 ist mit gleichzeitigem AdvertizedWindow = 1000.
Als Erklärung der Zusatzfrage steht ja in der Musterlösung, dass der Sender nun Sondensegmente von 1 Byte verschicken wird um ein Ack mit größerem AdvWindow zu provozieren, und der Empfänger wird nun darauf warten bis er ein AdvWindow >= MSS bekannt geben kann.
Die Sendersituation hab ich eigentlich verstanden, nur verwirrt mich das was im Skript (Transportschicht auf Folie 144) steht.

Also wann genau werden jetzt Sondensegmente geschickt? Bei EffectiveWindow = 0 oder bei AdvertizedWindow = 0, oder bei beidem?

Und was den Empfänger angeht möcht ich auch nochmal aMw’s Frage aufgreifen:

In dem Szenario ist mir klar, dass der Empfänger warten muss, da der Sender erstmal nix mehr an Daten schicken kann mit EffectiveW = 0, aber das warten hat hier doch nix mit der MSS zu tun oder? Schließlich hat er ja noch ein AdvertizedWindow = 1000 > MSS ~ 500.
In diesem Zusammenhang möcht ich auch nochmal fragen auf welches der Fenster die MSS direkten Einfluss hat, nur um das nochmal klarzustellen.

Bitte um Hilfe, ich seh vor lauter Windows den Wald nich mehr befürcht ich^^. Und danke im Vorraus.


Wie ich OBEN schon geschrieben habe, sehe ich NIRGENDS auf dem Aufgabenblatt was von MSS = 500 (oder kann ich jetzt schon nicht mehr lesen?)!
D.h. man kann nur eine allgemeine Aussage machen!

Also kann man NUR diesen Teil hier hinschreiben: check AdvertizedWindow = 1000 > MSS
MSS = ? => Fallunterscheidung (wenn größer, dann… wenn kleiner-gleich, dann…)


Die Teilfrage wurde doch längst rausgelöscht aus den beispielfragen. Die hatten damals offensichtlich zuerst eine Falsche lösung, und hatten da für das Advertised Window am schluss auch 0, und in folge dessen passt da logischerweise auch die Frage nichtmehr dazu.
Aber in dem Fall würde halt nach einer Zeit das verlorene Paket neu gesendet werden und danach geht wieder alles normal weiter.


Haette auch noch eine Frage zu TCP FlowControl:

Auf Folie 145 im Kapitel 3 blockiert der Sender. So wie es aussieht, weil das EffectiveWindow kleiner als MSS ist. Dass der Sender da blockiert steht aber nirgends und so weit ich gelesen habe, kuemmert sich Nagle um die Verhinderung des SillyWindowSyndroms auf Senderseite… kann mir da jemand bitte weiterhelfen und mir das erklaeren?


Nur um sicherzugehen:

Wenn in einer Aufgabenstellung die Rede von KB ist, dann ist Kilobyte gemeint also 8 * 10^3 bit. Richtig so?


Würde ich genauso sehen.


Das korrekte SI-Präfix schreibt man mit kleinem k!


Ja, das ist wohl richtig. Gängig sind für Kilobyte allerdings KB, kB und kb. Formal richtig wäre aber eigentlich nur kB.


Wir haben in den Übungen immer mit 1024 gerechnet. Das kleine b war dabei für Bit reserviert.