Seite 3 von 3

Verfasst: 09.04.2009 11:29
von DarkDragon
Joel hat geschrieben:Frag ma nach...dann guck ich mri auch den Stream an :D
Kann ich nicht, ich bin nicht dort. :wink:

Verfasst: 09.04.2009 11:36
von Joel
Hach schade...ok, jetzt aber zurück zum Thema, wie geht TCP hole punching?

Wenn jemand auch Interesse an der technik hat, dann bitte mir eine PN schreiben, dann können wir das mal probieren. Brauche nur eine 2. PC, der nicht hinter mienem NAT ist...

Verfasst: 14.04.2009 20:35
von Joel
Ich habe das jetzt mal probiert, erstmal mit UDP. Aber leider klappt das nicht. Ich habe 2 PCs hinter nem Router gehabt und beide Router unterstützen UDP hole punching, aber der Code schafft es nicht. Positive Connections bestimme ich durch ein Empfangenes Teststring.

Server:

Code: Alles auswählen

If InitNetwork() = 0
  MessageRequester("Error", "Can't initialize the network !", 0)
  End
EndIf

  Procedure Conn(l.l)
Shared ConnectionID
ConnectionID = OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)
SendNetworkString(ConnectionID, "aaa")
EndProcedure 

*Buffer = AllocateMemory(1000)

If CreateNetworkServer(0, 9000, #PB_Network_UDP)
  
  Repeat
  


Conn_Thread = CreateThread(@Conn(), 77)
Delay(50)
  
      
    SEvent = NetworkServerEvent()
  
    If SEvent
    
      ClientID = EventClient()
  
      Select SEvent
      
        Case 1
          MessageRequester("PureBasic - Server", "A new client has connected !", 0)
  
        Case 2
          MessageRequester("PureBasic - Server", "Client "+Str(ClientID)+" has send a packet !", 0)
          ReceiveNetworkData(ClientID, *Buffer, 1000)
          MessageRequester("Info", "String: "+PeekS(*Buffer), 0)
    
      EndSelect
    EndIf
    
  Until Quit = 1 
  
  MessageRequester("PureBasic - Server", "Click to quit the server.", 0)
  
  CloseNetworkServer(0)
Else
  MessageRequester("Error", "Can't create the server (port in use ?).", 0)
EndIf

  
End   
Client:

Code: Alles auswählen

If InitNetwork() = 0
  MessageRequester("Error", "Can't initialize the network !", 0)
  End
EndIf

Procedure Conn(l.l)
ConnectionID = OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)
Debug ConnectionID
SendNetworkString(ConnectionID, "testa")
EndProcedure 

Repeat
Conn_Thread = CreateThread(@Conn(), 77)
Delay(1000)
ForEver 
Der Code ist normal verständlich. Die Prozesse Bombadieren sich mit Verbindungsversuchen und der Cleint sendet immer dateien, die beim Server aber nicht ankommen. Es muss an meinem Code liegen, da beide Router UDP udn TCP punching unterstützen und eien normale TCP Verbindung mit Portforwarding auch klappt.[/quote]

Verfasst: 18.05.2009 18:19
von Joel
Gibts schon neue Ansätze für TCP- oder UDP hole punching?

Verfasst: 20.05.2009 19:30
von Joel
Also heißt das jetzt, das UDP/TCP Hole Punching nicht mit PB möglich ist?

Verfasst: 21.05.2009 08:30
von DarkDragon
Joel hat geschrieben:Also heißt das jetzt, das UDP/TCP Hole Punching nicht mit PB möglich ist?
Du musst etwas auf dem Port 9000 senden, damit die NAT Box wieder zum Port 9000 zurücksendet. Das geht ohne API nicht (SOCK_RAW -> UDP Header selbst hinzufügen).

>> OpenNetworkConnection("0.0.0.0", 9000, #PB_Network_UDP)

Der Port auf dieser Seite ist damit nicht 9000 sondern liegt wohl irgendwo jenseits der 50000.

Verfasst: 31.08.2009 15:01
von Joel
Achso, udn wie mach ich das mit der API bzw. Wie bekomme ich so einen Header usw...

Verfasst: 31.08.2009 16:23
von DarkDragon
Joel hat geschrieben:Achso, udn wie mach ich das mit der API bzw. Wie bekomme ich so einen Header usw...
Schau mal mein Beispiel hier, wie man es ohne API macht, aber mit einem Introducer, der die Port-Schätzung übernimmt.

Mit API könnte man den Port für einige wenige NAT-Boxen festlegen, dann kann man den u.U. besser "erraten" ohne Introducer.

Verfasst: 31.08.2009 16:43
von Joel
Wieso erraten?

Wie meinst du das jetzt genau?

Versteh ich da jetzt was falsch?

Also ich habe gedacht: Ich habe gedacht ich mach auf PC1 einen Port z.B. 7000 und PC2 bombadiert den mit anfragen auf Port 7000. Dann stellt PC1 einen Verbindung zu PC2 auf Port 7000 her.....Dadurch kann PC2 nun wieder durch die Firewall von PC1 durch....

Verfasst: 31.08.2009 16:51
von DarkDragon
Joel hat geschrieben:Wieso erraten?

Wie meinst du das jetzt genau?

Versteh ich da jetzt was falsch?

Also ich habe gedacht: Ich habe gedacht ich mach auf PC1 einen Port z.B. 7000 und PC2 bombadiert den mit anfragen auf Port 7000. Dann stellt PC1 einen Verbindung zu PC2 auf Port 7000 her.....Dadurch kann PC2 nun wieder durch die Firewall von PC1 durch....
Im Prinzip ist das auch richtig (Nur das bombadieren stimmt nicht). Doch leider kann man dabei nur systematisch raten, welcher Port jetzt außen, also nach der NAT Box das Paket hat, außer man hat einen Introducer, der einem genau das sagt. Mit API gibt es da noch eine Möglichkeit den Port Clientseitig einigermaßen festzuhalten, aber da muss die NAT-Box auch mitspielen, ansonsten wird wieder systematisch geraten.