Telefonnetze sind ohne IP ausgekommen

[pica]

und dies lange bevor es IP überhaupt gab. FAX Geräte kommen auch ohne IP aus.

Somit verstehe ich nicht, weshalb ein Netz ohne IP praktisch nicht umsetzbar sein soll.

Gruß,
pica

[Megusta]

pica schrieb:
--------------------------------------------------------------------------------
> und dies lange bevor es IP überhaupt gab. FAX Geräte kommen auch ohne IP
> aus.
>
> Somit verstehe ich nicht, weshalb ein Netz ohne IP praktisch nicht
> umsetzbar sein soll.


So richtig ist diese Aussage nicht! Jeder Telefonanschluss hat eine Adresse und eine Verwaltungsstelle, die Telefonate umleitet, also im Grunde genommen das Gleiche wie mit IP und DNS Server.

[M.P.]

Dein Beispiel ist auch ein gutes Gegenbeispiel

Als man IP erfunden hat, gab es Telefonnetze, Faxgeräte und Fernschreiber.

Wenn IP nicht einige Probleme mit diesen Techniken zu lösen geholfen hätte, hätte es sich nicht durchgesetzt, und man hätte weiter mit "Balkonen" an bewährter Technik weitergemacht...

Vielleicht denkt man jetzt, dass es wieder Zeit für einen grundlegenden Wechsel ist, IP grundsätzlich auf den Prüfstand zu stellen ist.

Aber genau, wie sich auch Jahrzente nach IP bei der Telefonie noch nicht flächendeckend Voice-Over-IP durchgesetzt hat, wird man auch IP nicht einfach so mit einem Fingerschnipsen von der Bildfläche verbannen könne ...

[Tuxraxer007]

Megusta schrieb:
--------------------------------------------------------------------------------
> So richtig ist diese Aussage nicht! Jeder Telefonanschluss hat eine Adresse
> und eine Verwaltungsstelle, die Telefonate umleitet, also im Grunde
> genommen das Gleiche wie mit IP und DNS Server.
Eben, nur hieß das Teil nicht IP-Adresse sondern Telefonnummer - aber ist nichts anderes.

Heute haben Telefonanschlüsse eben IP-Adressen, weil ein Großteil der Vermittlungstechnik auf VoIP umgestellt ist und ob ein Großrechner ( nichts anderes sind Vermittlungsstellen heute ) nun Datenverbindungen durchschaltet oder Telefonverbindung, die im Digitalzeitalter auch nichts anderes als eine Datenverbindung sind, ist dem Rechner egal, aber er braucht halt eine Zieladresse.
Ob ich der Zieladresse nun eine IP geben oder das Teile baum.stift.auto heißt, ist egal ( baum.stift.auto ist übrigens für Leute die es nicht kennen, eine 3Word Beispiel-Bezeichnung, mit der Ort dieser Erde mit 3 Wörter beschrieben werden kann - früher waren es mal Geo-Koordinaten - what3words für google-suche )

[senf.dazu]

Ein Problem das man mit der Leitungsvermittlung nicht lösen kann ist wenn das Netz voll ist - sprich der nächste Teilnehmer kriegt gar dann eben gar keine Verbindung weil die Resourcen (Nicht nur die Datenrate sondern genauso die Schaltwege/Switches) irgendwo begrenzt sind.

Dafür kriegt jede erfolgkreiche leitungsvermittelte Verbindung aber definierte Übertragungsparameter wie Bandbreite und Latenz. Sprich "perfektes" QoD. Und der nicht erfolgreiche eben nix. Muß es dann sozusagen am nächsten Tag noch mal probieren.

IP geht einen anderen Weg - der sich aber so äußert das im Prinzip alle "Video/Audio" Verbindungen unzuverlässig sind - Latenz, Datenrate, Qualität, Holpern, Aussetzer, Hänger sind dabei - vom Prinzip her - unvermeidbar. Weil die Resourcenkapazität in der Praxis nie ausreichend ist kriegt eben jeder einen "gerechten" Anteil. Wenn ein Telefongespräch holpert oder TV aussetzt oder man den wesentlichen Moment des Krimis mitkriegt ist das eben Pech. Kann schon verstehen das gerade Mobilfunkfirmen, TV Anbieter damit nicht gerade glücklich sind. Eine eigentlich irgendwie bescheuerte Methode damit innerhalb von IP umzugehen ist den TV Stream einfach kräftig zu puffern (so ne min oder so). Sprich 1 min Latenz (nogo für Musiker) und lange Reaktionszeiten beim Channel-Zapping, leicht mal asynchronität zwischen gertrennten Audio und Video Netzwerkgeräten sind die Folge.

Die Abhilfe die manche lokalen Netzwerke gehen ist einen Teil der Netzbandbreite aus dem asynchronen IP Netz rauszunehmen und für sie Bandbreitenreservierung vorzunehmen. Der Rest wird für die asynchronen Requests verwendet.

Altes Thema, konkrete Lösungen oder Lösungsversuche gibt's z.B. bei Firewire: asynchroner vs. isochroner Traffic, ist aber wirklich ein uraltes Thema. Auch bei der Einführung der erste Cu basierten Ethernet Standards gab's ne ganze Latte solcher Demosysteme verschiedener Firmen bevor man sich für den Minimalkonsens rein asynchrone entschieden hat.. USB .. ATM ..
Der wesentliche Punkt scheint aber bei allen diesen Ansätzen zu sein das der synchrone Verkehr mit Reservierunge ein drunterliegendes asynchrones Netz (IP) braucht das die synchronen Verbindungen erstmal zwischen den Endpunkten aufsetzt und da wo notwendig Resourcen reserviert und nach beendigung der synchronen Verbindung wieder freigegeben werden.

Bei Highspeednetzen (heute 100G+) wie Infiniband (Protokoll auch mal neben IP: RDMA) gibt's noch mehr Spielarten - für die RDMA werden typ. zweiseitige Verbindungen aufgebaut - die dann ohne Zutun der CPU betrieben werden - und die z.B. bei der Verbindung mit einem schlichten RoundRobin eine Prioritätsverteilung im Netz vornehmen - ohne Zwischenspeicher, so das sich eine über die Zeit recht gleichmäßige und kleinteilige (Paketweise) Priorisierung zwischen den Konkurrenzverbindungen gibt. Kein First comes first Serve mit volllaufenden Switch-FIFOs wie bei Ethernet/IP. Pakete werden nicht einfach versendet, sondern erst wenn die Verbindung steht - kurze Latenzen.



3 mal bearbeitet, zuletzt am 26.06.20 14:27 durch senf.dazu.

[User_x]

Eine Telefonnummer ist fixiert. Fällt dort ein Knotenpunkt weg, ist die Leitung weg. Eine IP kann durch diverse Routen leiten, das es heute nicht mehr so Anwendung findet ist eine andere Sache.