Mehrere Programme, nur ein Port?
-
Zeus schrieb:
Wo wird im IP-Header der Port addressiert?
gar nicht, wer behauptet sowas?
-
mezzo mix schrieb:
einmal wikipedia osi gelesen und schon experte. das sind mir die liebsten.
Könntest du bitte mit diesem Scheiss aufhören? Ich habe schon mehrere Prüfungen zum OSI Modell gehabt und auch schon an verschiedenen Stellen damit gearbeitet. Hör endlich auf andere zu beleidigen, nur weil sie nicht deiner Meinung sind!
Und was soll das jetzt überhaupt mit dem End-To-End? Hast du mal gelesen, um was es hier ging? Es ging um verdammte Ports! Und die befinden sich im TCP oder UDP Header oder bestreitest du dies? Es scheint nämlich fast so, deswegen kommt auch die Aussage von Zeus. Es scheint als würdest du behaupten, dass die Ports im IP Header gespeichert sind, was absoluter Unsinn ist.
Grüssli
-
Vom dem ganzen Dialog versteh ich deiner Seits nur dass der IP-Layer dein Postbote ist, daher hab ich mal nachgefragt :o Weil eine Anfrage an ein Webserver reicht eben nicht aus die IP-Addresse, man muss noch Server als Prozess erreichen, der eben auf dem Port 80 sitzt. Daher würde eine End-zu-End Verbindung durch den berühmten 4er-Tupel[lokal Ip, lokal port, remote ip, remote port] beschrieben.
-
Wenn dann bald klar ist, wer das OSI-Modell beherrscht und wer nicht, können wir ja wieder mit TCP/IP fortfahren, das schert sich nämlich recht wenig um OSI.
-
Dravere schrieb:
Und TCP, bzw. UDP, ist für die Übermittlung von diesen Ports zuständig.
ist das von dir, oder nicht?
ich sage: der service der übermittlung wird durch IP erbracht. nicht mehr und nicht weniger.
en.wikipedia sagt:
The Network Layer provides the functional and procedural means of transferring variable length data sequences from a source to a destination via one or more networks
hab ich extra für dich nachgeschaut. 'variable length data' beinhaltet auch deine ports.
welcher teil davon ist für dich nicht verständlich? das meine ich mit end 2 end.dass die ports im tcp/udp header stehen ist unbestritten, dass tcp/udp diese portinformationen benötigt ist auch unbestritten. dass tcp/udp diese übermittelt ist wiederum kokolores.
ich werde dein beispiel einfach mal analog auf schicht 3 anwenden:
Dravere würde sagen schrieb:
Und IP, ist für die Übermittlung von diesen IP-Addressen zuständig.
ich würde darauf antworten:
dass die IP-addresse im IP-header stehen ist unbestritten, dass IP diese IP-informationen benötigt ist auch unbestritten. dass IP diese übermittelt ist wiederum kokolores.und jetzt die frage: klingelt bei dir irgendwas?
da du ja gerne prüfungen zum thema ablegst kommt jetzt die bonusfrage:
wer oder was übermittelt diese IP-addressen?Dravere schrieb:
Ich habe schon mehrere Prüfungen zum OSI Modell gehabt und auch schon an verschiedenen Stellen damit gearbeitet.
ein problem von modellen ist, dass sie in der praxis oft ihre gültigkeit verlieren. dein osi modell endet von deinem dsl modem aus vielleicht nach 500 metern. deine praktischen erfahrungen wahrscheinlich schon früher.
das verhält sich etwa so wie geschlechtsverkehr haben zu pornofilm kucken. du scheinst gerade zu onanieren…auch auf die gefahr hin, dass du das jetzt wieder als üble beleidigung interpretierst - das ist es nicht. ich will nur, dass du es verstehst.
-
Zeus schrieb:
Vom dem ganzen Dialog versteh ich deiner Seits nur dass der IP-Layer dein Postbote ist, daher hab ich mal nachgefragt :o Weil eine Anfrage an ein Webserver reicht eben nicht aus die IP-Addresse, man muss noch Server als Prozess erreichen, der eben auf dem Port 80 sitzt. Daher würde eine End-zu-End Verbindung durch den berühmten 4er-Tupel[lokal Ip, lokal port, remote ip, remote port] beschrieben.
in der tat komme ich eher aus der basisnetz/rücktransport-welt (scheiß wörter, backbone/backhaul klingt vielleicht besser). bezüglich end 2 end sieht man das alles ein bisschen anders, als der applikationsprogrammierer.
-
Fangt doch erstmal an zu streiten, wieviel Schichten das TCP/IP Modell hat
-
volkard schrieb:
Wenn dann bald klar ist, wer das OSI-Modell beherrscht und wer nicht, können wir ja wieder mit TCP/IP fortfahren, das schert sich nämlich recht wenig um OSI.
-
Mal ein kleine Zusammenfassung:
- Eine TCP-Verbindung besteht immer aus dem Tupel (Quell-IP, Quell-Port, Ziel-IP, Ziel-Port) - so kann das Betriebsystem dem Ganzen einen Socket zuordnen
- Ports werden nicht ausgehandelt (nicht verwechseln mit dem neuen Socket der mittels accept erstellt wird)
- Den Quellport kann man entweder selbst festlegen oder das Betriebssystem nimmt einen freien Port
- Ja, IP _kann_ einen Port in den Nutzerdaten transportieren (Ausnahme ICMP z.B.) - ist aber für IP irrelevant da es keine Ports kennt - kennen tut den nur die Schicht darüber - TCP oder UDP (und da sind sich doch auch sicherlich am Ende alle einig darüber)Also der Browser könnte also auch von Port 80 zu Port 80 eine Verbindung aufbauen. Die übliche Praxis ist aber den Quellport vom Betriebssystem aussuchen zu lassen.
-
Oliver schrieb:
- Ja, IP _kann_ einen Port in den Nutzerdaten transportieren (Ausnahme ICMP z.B.) - ist aber für IP irrelevant da es keine Ports kennt - kennen tut den nur die Schicht darüber - TCP oder UDP (und da sind sich doch auch sicherlich am Ende alle einig darüber)
IP kennen das Konzept eines Portes nicht, daher kann ICMP keine Ports nutzen! Nutzdaten werden wie in alle Schichten eingekapselt.
-
Zeus schrieb:
Oliver schrieb:
- Ja, IP _kann_ einen Port in den Nutzerdaten transportieren (Ausnahme ICMP z.B.) - ist aber für IP irrelevant da es keine Ports kennt - kennen tut den nur die Schicht darüber - TCP oder UDP (und da sind sich doch auch sicherlich am Ende alle einig darüber)
IP kennen das Konzept eines Portes nicht, daher kann ICMP keine Ports nutzen! Nutzdaten werden wie in alle Schichten eingekapselt.
Und genau das habe ich auch geschrieben...
-
Handshake = Aushandeln
Bind Listen wird auf Schnittstelle und Port 80 gebunden. (Socket)
Accept weiß dieser Anfrage einen neuen Socket auf dem Server zu. Port 80 geht wieder auf Listen und ist frei.
Kommunikation erfolgt über den neuen Socket zw. Server und Client.
Was ein Socket ist seht ihr über google.
-
Unix-Tom schrieb:
Was ein Socket ist seht ihr über google.
Ja, ich hab's versucht.
http://images.google.de/images?um=1&hl=de&safe=off&tbs=isch:1&q=socket+uml&sa=N&start=0&ndsp=18
Das Bringt zwar nichts für Sockets, zeigt aber eindrucksvoll, welche Pest mit UML über die Informatik kam.
-
Ein neuer Socket muss nicht unbedingt einen neuen Port haben. Wiki über Sockets:
D.h. dass ein mit einem Client-Socket verbundener ("connected") Server-Socket genau die gleiche IP-Adresse und Port-Nummer trägt wie der lauschende ("listen") Server-Socket. Die Unterscheidung von gleichzeitigen Client Verbindungen zum selben Server erfolgt daher durch das Paar von Server-Socket und Client-Socket.
-
Gucken wir doch eine Anfrage im Wireshark an!
Anfrage GET /forum/ auf www.c-plusplus.net
+ TCP Src Port: 3710 Dest Port: 80
+ IP Src Ip: 192.168.2.11 Dest Ip: 87.106.19.147
+ Ethernet ist unnötig<TCP-Handshake>
Antwort 200 OK
+ TCP Src Port: 80 Dest Port: 3710
+ IP Src Ip: 87.106.19.147 Destb Ip: 192.168.2.11
+ Ethernet ist unnötigAlso ich seh nix vom neuem Socket :o
-
Habe ich auch nicht behauptet. Es war eine Antwort für Fragesteller der scheinbar von OSI etc. keine Anung hat und auch mit Handshakes etc. nicht anfangen kann.
-
Zeus schrieb:
Also ich seh nix vom neuem Socket :o
Kannst du ja auch nicht - den neuen Socket gibt es ja auf der Serverseite.
--
Achso und nochmal: Socket != Port
-
@mezzo mix,
Mir ging es einzig und alleine und das schon immer um die Zuständigkeit. IP kennt nichts von Ports. Es transportiert einfach alles von der oberen Schicht. Und so wie die Zuständigkeit liegt, so definiere ich auch wer die Übermittlung durchführt. Denn deine Definition bringt einen feuchten Dreck, da daraus nicht ersichtlich wird, wer eigentlich zuständig ist für die Ports. Was IP wirklich transportiert ist das Paket vom Transportation Layer. Was auch immer das ist. Es transportiert die Ports nur indirekt und ist für diese nicht zuständig.Wenn du endlich mal deine belehrende Art und Obermacker getue ablegst, dann würdest du endlich mal erkennen, dass es hier nur um eine Definitionsfrage geht. Es geht gar nicht um Wissen. Aber es ist natürlich in einer Diskussion einfacher, statt vernünftig zu diskutieren und sich mit den Gegenargumenten auseinanderzusetzen, dem anderen Unwissenheit vorzuwerfen.
Kurz zusammengefasst:
Du sagst, weil IP das Transportation Layer Paket transportiert, transportiert bei TCP IP die Ports.
Ich sage, weil TCP die Ports in seinem Header hat, transportiert TCP die Ports und IP nur indirekt.Aber ich habe inzwischen genug. Bleib bei deiner Definition und sei nicht überrascht, wenn bei deiner Erklärung dann jemand das Gefühl hat, dass die Ports in IP übermittelt werden und somit in dessen Header stehen ...
Grüssli
-
Dravere schrieb:
Aber es ist natürlich in einer Diskussion einfacher, statt vernünftig zu diskutieren und sich mit den Gegenargumenten auseinanderzusetzen, dem anderen Unwissenheit vorzuwerfen.
du machst es einem auch einfach.
ich habe meine argumente mehrfach erläutert. dir halbwissen zu unterstellen war lediglich eine zugabe.Dravere schrieb:
Du sagst, weil IP das Transportation Layer Paket transportiert, transportiert bei TCP IP die Ports.
das würde ich nie behaupten.
ich nehme diesmal die deutsche wikipedia, ist vielleicht besser verständich:Das Protokoll TCP zum Beispiel befindet sich ausschließlich in den Nutzdaten des IP-Pakets – eine Schicht weiter oben im OSI-Modell.
auf diese weise kann man jedes deiner posts auseinander nehmen. fingerübungen dieser art sind keine herausforderung.
tcp/ip paket hätte ich durchgehen lassen. zur erläuterung: segmente ist das wort, welches du suchst. (doch nicht so osi fest? in der prüfung gibt's dafür punktabzug)nebenbei finde ich folgendes perönlich:
Dravere schrieb:
Du bist unhöflich, dass du hier dein Halbwissen verbreitest und dann auch noch stumpf auf Richtigkeit beharrst! Wie kann man nur! Schäm dich! Verkriech dich in die letzte Ecke! Du darfst hier nie mehr etwas sagen! Hust! Weg! Pfui!
ich habe nicht in dieser art diskutiert.
aber red' hier nur weiter, wie der blinde von der farbe...
nichts für ungut, mm