loopback-socket: Welcher PORT ?

[joost]

Ja. Aber wenn man selstsame Sachen wie zusätzliche Loopback-Interfaces (?) zu installieren versucht, wundert es mich nicht, dass da jetzt irgendwas kaputt ist. Scheint so, als hättest du dein OS gegen die Wand gefahren.

Die Installation war ein totaler Selbstläufer und - wie gesagt -, das Netzlaufwerk war einen Tag lang toleranter gegenüber Abstürzen als 127.0.0.1 - der jeweilige Port war schon nach Neuanmeldung wieder verfügbar. Und am Ende lief ja sowieso alles, die Lösung finde ich für das Füllen eines reinen Anzeigefensters nur ziemlich unpassend (und auch eine Performancefrage). Aber ich hatte auch in einigen früher überflogenen Sachen immer wieder gelesen, dass andere Inter-Prozess-Kommunikation auf Windows ausschließlich über sockets machen (müssen).

Ich kann jetzt über subprocess.stdin ständig Daten in den subprocess pumpen.

[Leonidas]

Aber ich hatte auch in einigen früher überflogenen Sachen immer wieder gelesen, dass andere Inter-Prozess-Kommunikation auf Windows ausschließlich über sockets machen (müssen).

Nein. Es gibt auch unter Windows IPC-Möglcihkeiten ohne sockets. COM wäre gleich mal das erste Beispiel.

[joost]

Danke für den Hinweis. Aber für so kleine Pakete wie eine .csv-Zeile ist alles zu groß, solange Popen<object>.stdin funktioniert.

ActivePython macht ne ganze Menge in der Registry. Eigentlich möchte ich meine Programme einfach durch Kopieren weiterreichen (Einträge in 'PATH' oder 'PYTHONPATH' mal ausgenommen, man könnte übrigens versuchen, die aus den Programmen heraus zu manipulieren). Mit dem Python-Interpreter geht das, mit gtk auch. Deshalb hab ich es zusammen mit den win32 nach gestriger Installation wieder abgeschafft. Es half nichts bei den Problemen mit subprocess (eben auch nicht der Start aus Mark Hammonds IDE).

[Y0Gi]

Nochmal zur Klarstellung:

Das Loopback-Device gibt es sowohl unter Windows als auch UNIXen und vermutlich auf so gut wie allen Systemen mit einem TCP/IP-Stack. Es hat per Default die IP-Adresse 127.0.0.1 und den Hostnamen 'localhost'. Weitere Adressen wie 127.0.0.2 usw. lassen sich aber auch anlegen.
Das Device dient zum Testen und ist nur Host-intern verwendbar, von Außen nicht zugänglich. Der Adressbereich 127.0.0.0/8 ist extra für diese interne Nutzung reserviert.

Eine Zeroconf-/Link-Local-Adresse aus 169.254.0.0/16 wird u.a. an Interfaces vergeben, die (zumindest unter Windows) per DHCP keine Adresse von Außerhalb zugewiesen bekommen. Allerdings bekommt das Loopback-Device so eine Adresse *nicht*, sondern nur richtige Devices wie deine Netzwerkkarte (oder andere, virtuelle NICs).

Wenn du ein 'Address/port/socket already in use' erhältst, sollte das Abschießen des verursachenden Prozesses das aus der Welt schaffen. Wenn da nur ein Neustart hilft, ist an deinem OS wohl was ziemlich kaputt.

[lunar]

Nochmal zur Klarstellung:

Das Loopback-Device gibt es sowohl unter Windows als auch UNIXen und vermutlich auf so gut wie allen Systemen mit einem TCP/IP-Stack. Es hat per Default die IP-Adresse 127.0.0.1 und den Hostnamen 'localhost'.

Korrigiert mich, wenn ich falsch liege, aber kann man "localhost" als Namen nicht auch umbiegen (z.B. über einen Eintrag in der /etc/hosts)?

Eine Zeroconf-/Link-Local-Adresse aus 169.254.0.0/16 wird u.a. an Interfaces vergeben, die (zumindest unter Windows) per DHCP keine Adresse von Außerhalb zugewiesen bekommen.

Deswegen kann man mit Windows auch Netzwerke ohne manuelle IP-Konfiguration und ohne DHCP Server aufbauen. Das Linux-Pendant dazu heißt avahi...

[birkenfeld]

Nochmal zur Klarstellung:

Das Loopback-Device gibt es sowohl unter Windows als auch UNIXen und vermutlich auf so gut wie allen Systemen mit einem TCP/IP-Stack. Es hat per Default die IP-Adresse 127.0.0.1 und den Hostnamen 'localhost'.

Korrigiert mich, wenn ich falsch liege, aber kann man "localhost" als Namen nicht auch umbiegen (z.B. über einen Eintrag in der /etc/hosts)?

Ja, und sogar noch genauer: Durch diesen Eintrag wird der Name erst erstellt. Wenn du ihn auskommentierst, ist "unknown host: localhost" die Folge.

[joost]

@rayo

Die 169er Adresse kommt von einem Interface das keinen DHCP gefunden hat.

Verstehe ich richtig, dass unter solchen Umständen immer '169.x.x.x' vergeben wird ?

[Y0Gi]

Ja! Wie in dem von mir genannten Zeroconf-Artikel bei Wikipedia auch steht:

Wenn ein Rechner eine Link-Local IP-Adresse konfigurieren will, wählt er einfach mit Hilfe eines Zufallszahlengenerators eine IP-Adresse zwischen 169.254.1.0 und 169.254.254.255 (RFC 3330) aus. Die ersten 256 und die letzten 256 Adressen sind von der IANA für zukünftige Anwendungen reserviert, und dürfen unter keinen Umständen ausgewählt werden.

Und wie in der von mir ebenfalls genannten RFC 3330 steht:

127.0.0.0/8 - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only 127.0.0.1/32 for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].

[...]

169.254.0.0/16 - This is the "link local" block. It is allocated for
communication between hosts on a single link. Hosts obtain these
addresses by auto-configuration, such as when a DHCP server may not
be found.

Nix für ungut, aber mich beschleicht das Gefühl, dass du auf jene Dokumente nicht mal einen genaueren Blick geworfen hast.

Wie dem auch sei, noch klarer kann ich es selbst mit weiteren Posts nicht mehr ausdrücken.[/url]

[joost]

@YOGI: Ja gut, weshalb willst Du es denn auch klarer ausdrücken ? Den Absatz, den Du aus der RFC 3330 zitierst, ist der, den ich ca.10 Posts weiter oben selbst schon zitiert habe - habe aber in der RFC aber tatsächlich NUR diesen Absatz gelesen. Sorry, aber über 127.0.0.x sollten wir an dieser Stelle wirklich nicht mehr reden.

Das mit 169.x.x.x war informativ, danke.

Es ist aber schade, wie ihr alle mit diesem Fund umgeht, dem, dass MS eine 'Extra'-Loopback-Installation anbietet, kostenlos und gut dokumentiert. Das ist und bleibt sehr merkwürdig, fast so, als würde MS seiner Implementierung im Netwerkstack des Betriebssystem nicht trauen. Davon berichtet zu haben, hat mir hier nichts als endlos wiederholte Posts darüber, was 127.0.0.x ist (wie geschrieben, all diese Dinge sind allerdings schon neu für mich) und überflüssige Schreibarbeit eingebracht. Schade !

Und @Leonidas: Nein, ich habe jenes OS nicht zerschossen. Und die sockets in meiner ftpXact funktionieren weiter tadellos.

[lunar]

Es ist aber schade, wie ihr alle mit diesem Fund umgeht, dem, dass MS eine 'Extra'-Loopback-Installation anbietet, kostenlos und gut dokumentiert.

Wieso? Das ist ganz normal. Sowas gibt es auch unter Linux mit dem dummy-Treiber. Er ist zum Testen vom Netzwerk-Funktionalität auf Rechnern gedacht, die keinerlei echte Schnittstellen verfügen. Microsofts Namensgebung ist nur etwas unglücklich: Dieser Treiber bietet kein Loopback-Interface im eigentlichen Sinne, sondern nur ein virtuelles Interface, was sich wie ein richtiges Interface verhält.

Das ist und bleibt sehr merkwürdig, fast so, als würde MS seiner Implementierung im Netwerkstack des Betriebssystem nicht trauen.

Nein, sie trauen ihrem Netzwerk-Stack schon. Nur bietet Windows normalerweise keine Dummy-Treiber für virtuelle Schnittstellen, deswegen bietet MS sowas zum Download an. Das ist aber kein echtes Loopback-Interface, sondern was ganz anderes (worauf schon die Zeroconf-Adresse hindeutet). Das schreibt MS übrigens auch selbst:

Der Microsoft Loopbackadapter kann zu Testzwecken in einer virtuellen Netzwerkumgebung verwendet werden, in der kein Zugriff auf ein Netzwerk möglich ist.

Man sollte diesen Adapter nicht dazu zweckentfremden, um lokale Kommunikation zu betreiben. Dazu ist das schlicht nicht gedacht.

Davon berichtet zu haben, hat mir hier nichts als endlos wiederholte Posts darüber, was 127.0.0.x ist (wie geschrieben, all diese Dinge sind allerdings schon neu für mich) und überflüssige Schreibarbeit eingebracht. Schade !

Das waren unsere Versuch, die klarzumachen, dass du da eben kein echtes Loopback-Interface installiert hast, sondern was ganz anderes.

[birkenfeld]

Nein, sie trauen ihrem Netzwerk-Stack schon.

Schließlich ist er von BSD geklaut.

[joost]

Zitat:

Der Microsoft Loopbackadapter kann zu Testzwecken in einer virtuellen Netzwerkumgebung verwendet werden, in der kein Zugriff auf ein Netzwerk möglich ist.

Man sollte diesen Adapter nicht dazu zweckentfremden, um lokale Kommunikation zu betreiben. Dazu ist das schlicht nicht gedacht.

Danke dafür, aber ich verstehe es nicht. Ich habe doch in jedem Windows Netzwerk-Funktionalität, die 127.0.0.x doch unabhängig von 'Zugriff auf ein Netzwerk' auflösen können müßte. Aber lasst man: Ich muss mir hier ganz sicher einiges mehr an Grundlagenwissen erarbeiten und werde das in den nächsten Tagen tun.

[lunar]

Zitat:

Der Microsoft Loopbackadapter kann zu Testzwecken in einer virtuellen Netzwerkumgebung verwendet werden, in der kein Zugriff auf ein Netzwerk möglich ist.

Man sollte diesen Adapter nicht dazu zweckentfremden, um lokale Kommunikation zu betreiben. Dazu ist das schlicht nicht gedacht.

Danke dafür, aber ich verstehe es nicht. Ich habe doch in jedem Windows Netzwerk-Funktionalität, die 127.0.0.x doch unabhängig von 'Zugriff auf ein Netzwerk' auflösen können müßte.

127.0.0.1 ist immer verfügbar, selbst wenn der Rechner keine Netzwerkkarte hat. Ansonsten würde das System nicht mehr rund laufen.

Wenn man allerdings auf einem netzwerklosen Rechner mal ein Interface benötigt, um etwas zu testen (z.B. Netzwerkkommunikation zu simulieren und dabei abzuhören), sollte man tunlichst nicht an 127.0.0.1 rumpfuschen. Ich weiß nicht mal, ob man das loopback-Interface unter Windows überhaupt manipulieren kann.

Dazu kann man dann virtuelle Dummy-Schnittstellen hernehmen, die eben dieser Windows-Treiber auch zur Verfügung stellt.

[joost]

Dank ! Das Bild wird allmählich klarer.