Frage zu TCP/IP

[Monty Burns]

Tach zusammen

hab mich letztens ein wenig mit TCP/IP beschäftigt und da ist bei mir die frage aufgekommen, warum man nich mehr als nur eine ip adresse als empfänger eintragen kann

das würde z.b. bei video-streaming (online-fernsehen) was bringen
ich seh aber auch verwendung beim file sharing
dadruch würden die server leitungen um einiges entlastet werden
das internet wär natürlich noch in gleichem maße belastet, aber sicherlich nciht stärker als zuvor

wo ist mein denkfehler?
sowas müsste sich doch leicht verwirklichen lassen(natürlich nicht von mir persönlich, aber von den standardisierungsgremien)

Monty Burns

[Philipp Hasenfratz]

Halihallo Monty

hab mich letztens ein wenig mit TCP/IP beschäftigt und da ist bei mir die frage aufgekommen, warum man nich mehr als nur eine ip adresse als empfänger eintragen kann

das würde z.b. bei video-streaming (online-fernsehen) was bringen
ich seh aber auch verwendung beim file sharing
dadruch würden die server leitungen um einiges entlastet werden
das internet wär natürlich noch in gleichem maße belastet, aber sicherlich nciht stärker als zuvor

wo ist mein denkfehler?
sowas müsste sich doch leicht verwirklichen lassen(natürlich nicht von mir persönlich, aber von den standardisierungsgremien)

TCP ist darauf ausgelegt, dass es _immer_ einen und nur einen Empfänger und Sender gibt. Die Kommunikation ist "Event-orientiert", d. h. es gibt einen Request und eine Response darauf.
Deine Idee würde sich eigentlich gar nicht unterscheiden, denn jeder Client müsste gleichermassen eine Nachricht an den Server senden, nur der Sender würde alle "gleichartigen" Requests zusammenfassen und an eine Liste mit Empfängern versenden. Hierdurch entstehen zwei Probleme: a) welches Kriterium unterscheidet bzw. identifiziert "gleichartige" Requests und b) die Packete wandern nicht gleich von Server zu Client, sondern über viele Routings, spätestens da müsste man die Response sowieso wieder splitten und man hat wieder "standard TCP".

zu a):
Nehmen wir HTTP als Beispiel. Auf ein Request folgt eine Response. Beide jedoch erfolgen über mehrere Datenpackete, welche über TCP übertragen werden. Diese Packete hängen zwar zusammen, jedoch gibt es keine Syntax, welche beschreiben könnte, dass Client A einen _gleichartigen_ Request wie Client B sendet. TCP ist zu "Grundlegend" (low-level-basiert), um eine "globale" Syntax bereitzustellen, mehrere Requests als "gleich" zu klassifizieren. Im Beispiel HTTP ginge das auch nur bedingt, jeder Client sendet Clientspezifische Informationen, welche durch einen Server ausgewertet werden können und so "unterschiedliche" Resultate zurücksendet. Erst wenn mehrere Requests als "gleich" klassifiziert werden können würde dein Vorschlag Sinn machen, aber der Aufwand ist zu gross und die wahrscheinlichkeit, dass dieser Fall eintritt (äquivalenter Request) zu klein (bzw. es macht keinen Sinn dies umzusetzen, wenn man nicht davon ausgehen kann, dass das Verfahren in 100% aller Fälle funktioniert).

zu b):
Die einzige Last, welche vermindert werden könnte, ist die Antwort des Servers. Das Netz wird nicht weniger belastet.

noch was:
TCP darf und kann nicht mit Spezialfällen arbeiten, wo dies ginge. Es muss 100% gleich funktionieren und zwar für jeden nur denkbaren "Fall".

Viele Grüsse

Philipp

[Daniel Thoma]

Hallo Monty,

Es gibt tatsächlich so etwas. Schimpft sich Multicasting.
Allerdings ist es nicht einfach. Die Router müssen das unterstüzen und es ist gar nicht so einfach, herauszufinden wo überall Empfänger eines solchen Multicaststreams sind. Man kann die Daten ja nicht einfach auf verdacht überall hin schicken.
In der ix war vor einiger Zeit auch mal ein guter Artikel zu dem Thema.

Grüße

Daniel

[Monty Burns]

danke für die antworten

vieleicht war es falsch das ganze mit tcp/ip in verbindung zu bringen
aber sinnvoll wär das ganze schon
und mann könnte wohl auch das netz entlasten
nehemn wir an ein deutscher fernsehsender "streamt" etwas mit diesem protokoll
100 menschen in den usa sehen sich die sendung an
dann müsste die überquerung des atlantik nur einmal gemeistert werden
und das sind soweit ich weiss auch die engstellen im netz
in den usa verteilt dann ein router das ganze

man könnte das ganze auch wieder mit tcp/ip in verbindung bringen indem die anfrage auch gebündelt wird
ein rechner in den usa führt eine lsite der "zuschauer" und übernimmt für dies stellvertretend den request

Monty Burns

[Sven Rautenberg]

Moin!

vieleicht war es falsch das ganze mit tcp/ip in verbindung zu bringen

Nein, ganz und gar nicht!

aber sinnvoll wär das ganze schon

Auf jeden Fall. Weil dann jeder Heinz zuhause sein Webradio machen könnte, und für den 64K-Stream wirklich nur eine ISDN-Leitung benötigen würde (naja, nicht ganz, etwas Puffer sollte schon da sein - aber das Prinzip stimmt).

und mann könnte wohl auch das netz entlasten

Naja, das nun wieder nicht unbedingt.

nehemn wir an ein deutscher fernsehsender "streamt" etwas mit diesem protokoll
100 menschen in den usa sehen sich die sendung an
dann müsste die überquerung des atlantik nur einmal gemeistert werden
und das sind soweit ich weiss auch die engstellen im netz

Korrekt. Und das nennt sich eben Multicasting und ist ein für TCP/IP bereits definiertes Verfahren. Leider ist es über das Experimentierstadium noch nicht hinaus gekommen, denn das Problem sind die großen und kleinen Netzwerkfirmen, aus denen das Internet besteht: Die können sich scheinbar immer noch nicht auf ein vernünftiges Abrechnungsmodell einigen. Multicast-Traffic ist sicherlich anders zu bewerten, als Unicast-Traffic, denn davon haben ja möglicherweise mehr Leute etwas. Ein Datenpaket ist also wertvoller. Nur kann man aufgrund der baumartigen Verteilungsstruktur von Multicast-Traffic leider nicht messen, wieviele Nutzer dahinterhängen. Und dann läßt man es doch lieber und kassiert pro User den Traffic ab, anstatt mit Multicast die User zu beglücken. Außerdem besteht in gewissen Erdteilen wie z.B. Europa derzeit ohnehin ein Überangebot an Kapazitäten, die man erst einmal ausgelastet wissen möchte, bevor man sich Sparmethoden überlegt.

In Unternehmensnetzwerken, die komplett unter einer Verwaltung stehen, funktioniert das ganze schon. Da ist es dann wirklich möglich, dass in Frankfurt der Vorstandvorsitzende eine Ansprache ans Unternehmen hält, und auch die 2000 Mitarbeiter in USA kriegen nur einen einzigen Stream, um mitzugucken. Und es spart dem Unternehmen, welches sicherlich ein VPN nach USA unterhält, gewaltig Traffic, den es auf der Leitung nach USA einkaufen muß. Schade für den Netzanbieter, der eben nur einmal Traffic kassieren kann.

man könnte das ganze auch wieder mit tcp/ip in verbindung bringen indem die anfrage auch gebündelt wird

Wie gesagt: Das _ist_ TCP/IP.

- Sven Rautenberg