sockets: 111 Connection Refused durch Router --> umgehen?

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Antworten
Benutzeravatar
Klip
User
Beiträge: 98
Registriert: Donnerstag 10. August 2006, 20:39

Hallo zusammen,

ich habe in letzter Zeit ein wenig mit Sockets rumgespielt und bin dabei auf Probleme gestoßen. Zuerst einmal hier zwei minimalistische Beispiele:

Server

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import socket

if __name__ == '__main__':
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
    
    server.bind(('', 50007))
    server.listen(1)

    (client, caddr) = server.accept()
    print caddr, "connected."
    client.send("Hello client!")
    print client.recv(1024)
    
    server.close()
    
    print "done..."
Client

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import socket

if __name__ == '__main__':
    client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    client.connect(('', 50007))

    print client.recv(1024)
    client.send("Hello there, server!")
    
    client.close()
    
    print "done..."
Der Server wartet nur auf eine Verbindung und tauscht einmal Text mit dem Client aus. Das funktioniert prima auf localhost, wenn ich meiner Freundin eine der beiden Dateien schicke und wir es über das Internet testen, bekommen wir die Meldung: "Connection Refused" vom Client. Der Server meldet nichts und lauscht weiter auf Verbindungen.
(IP-Adresse in der connect und bind-Anweisung dementsprechend für den Test angepasst natürlich)

Meine Vermutung: Der Router (wir haben beide einen) hat den entsprechenden Port nicht freigeschaltet.

Das ist soweit kein Problem, aber hier kommt meine eigentliche Frage:
Es gab vor einigen Jahren mal ein P2P-Programm (ich weiß nicht mehr welches genau), für welches man seine Ports freischalten musste. Da ich damals einen sehr seltsamen Router hatte, habe ich das Programm direkt wieder deinstalliert und den Vorfall vergessen.
Einige Zeit später gab es dann eine neue Version des Programms und siehe da: auf einmal war es nicht mehr nötig die Ports freizuschalten. Irgendeine Software-Lösung hat das Router-Problem aus der Welt geschafft.

Wie war das möglich? Gibt es entsprechende socket-Optionen? Ich habe SOL_SOCKET --> SO_DONTROUTE ausprobiert, leider ohne Erfolg.
In Dokus und Foren habe ich nichts gefunden, was mir weiterhilft.

Hat da jemand Erfahrung?

Würde mich über Ideen und Ratschläge sehr freuen =)
Benutzeravatar
Rebecca
User
Beiträge: 1662
Registriert: Freitag 3. Februar 2006, 12:28
Wohnort: DN, Heimat: HB
Kontaktdaten:

Ich kann mir vorstellen, dass in dem Fall UDP-Holepunching dahintersteckte. Das setzt aber voraus, dass man einen dritten "Vermittlungsserver" irgendwo hat, und man muss die Nachteile des UDP-Protokolls selber ausbuegeln.
Offizielles Python-Tutorial (Deutsche Version)

Urheberrecht, Datenschutz, Informationsfreiheit: Piratenpartei
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Was du suchst ist NAT traversal. Die beste Lösung wäre natürlich langfristig, dass jeder Computer seine eigene IP hat und es kein NAT mehr gibt, siehe IPv6.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
ms4py
User
Beiträge: 1178
Registriert: Montag 19. Januar 2009, 09:37

Also ich tippe mal auf die Software ``Azureus``, die konnte nämlich mit UPnP die Ports auf den meisten Routern automatisch forwarden, ohne dass man direkt was am Router einstellen musste ;)

Und für so eine simple Anwendung ist es IMHO die beste und auch einfachste Lösung, sich mit seinem Router auseinander zu setzen und die Ports manuell freizuschalten, anstatt sich mit noch viel komplizierteren Technologien auseinanderzusetzen.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Das funktioniert aber auch nur falls die Hardware UPnP unterstützt. Das ist sicherlich bei weitem nicht überall gegeben.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Klip
User
Beiträge: 98
Registriert: Donnerstag 10. August 2006, 20:39

Vielen Dank für die Antworten!

Ja, anscheinend suche ich NAT-Traversal.

Was ich langfristig vorhabe, ist ein kleines Chat-Tool mit GUI zu realisieren. Das steht auch soweit, abgesehen von obigen, angesprochenen NAT-Problemen. Ich möchte nicht jeden Benutzer dazu nötigen, an seinem Router rumzufummeln, das wirkt sehr abschreckend.

Ich würde gerne NAT-traversal für meine Applikation implementieren: welches Protokoll bietet sich da besonders an? Gibt es da Erfahrungswerte?

Hauptaugenmerk liegt auf verlässliche, korrekt angeordnete Datenübertragung (Chat), also ist TCP das Mittel der Wahl.

Ich habe gelesen, dass UPnP recht weit verbreitet bei Routern ist, also sollte ich mich wohl damit beschäftigen. Große Gefahr: Ausschluss durch Hardware... Und siehe da: es gibt dafür fertige Python-Frameworks.

PyMediaServer, BRisa, MiniUPnP kämen in Frage, wobei letzteres anscheinend kein reines Python ist (C-libs).

Der MediaServer ist für meine Zwecke wohl etwas zu viel. Habe aber noch nicht die Zeit gefunden mich da genauer einzulesen. Werde alle drei mal genauer unter die Lupe nehmen und hier Rückmeldung erstatten, sobald ich Genaueres weiß.

Vielleicht ist UPnP auch der ganz falsche Weg?

In der Zwischenzeit bin ich für jeden Hinweis und jeden Erfahrungsbericht dankbar :)
Die ganze Materie ist ein wenig verwirrend.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Ich würde UDP hole punching nehmen, das scheint für Skype das ja auch einen Chat bietet ausreichend gut gewesen zu sein.

UPnP scheitert eben daran: mein Router (eine normale Linux-Kiste mit iptables) unterstützt es nicht und Firmenrouter werden sich auch ganz sicher nicht überreden lassen sich einfach so per UPnP umzukonfigurieren. Daher UDP hole punching was in der Hinsicht universeller ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
Klip
User
Beiträge: 98
Registriert: Donnerstag 10. August 2006, 20:39

Hmm, verstehe. Danke für den Hinweis Leonidas.

Dann scheint UPnP doch weniger weit verbreitet zu sein als ich gelesen habe.

Wenn ich UDP-Holepunching verwende, müsste ich dann einkommende Datenpakete prüfen und gegebenenfalls "nachfragen", wenn Teile fehlen.

Die TCP-Varianten scheinen ja nicht so weit verbreitet zu sein (ergo funktionieren wieder nicht mit allen NAT-Konfigurationen).
Antworten