BNetEx

Übersicht BlitzMax, BlitzMax NG Codearchiv & Module

Gehe zu Seite Zurück  1, 2, 3 ... 10, 11, 12, 13  Weiter

Neue Antwort erstellen

BtbN

BeitragMo, Jan 18, 2010 23:03
Antworten mit Zitat
Benutzer-Profile anzeigen
Bau eine Test-Verbindung in einem Separaten Thread auf, und guck, ob sie funktioniert, wenn es wichtig ist, dass das ganze nicht blockiert.

ChaosCoder

BeitragMo, Jan 18, 2010 23:06
Antworten mit Zitat
Benutzer-Profile anzeigen
Wow, die Idee ist nicht schlecht. Danke BtbN!
Projekte: Geolaria | aNemy
Webseite: chaosspace.de

klin

BeitragMo, Jan 25, 2010 23:07
Antworten mit Zitat
Benutzer-Profile anzeigen
Hallo,
ich bin gade dabei über TCP einen kleinen www Server zu machen (WebInterface). So... nun ist mir ja seit langsam aufgefalenn, dass Bnetex nur eine bestimmte größe übertragen kann. Und dies ist schlecht wegen.. Bilder.
Nun zu meiner frage:
Wie könnte ich am besten (bin noch in der übung das HTTP Protokoll zu verstehen^^) die Bilder fehlerfrei übertragen? Könntet ihr mir einen kleinen Beispiel code posten?

Vielen Dank.

THX
MFG
Klin

Progger93

Betreff: Probleme mit Dateiversand [TCP]

BeitragSo, Feb 14, 2010 23:24
Antworten mit Zitat
Benutzer-Profile anzeigen
Hi Vertex [und alle anderen die mir eventuell helfen können],
Ich benutze mit großer Begeisterung dein Modul. Allerdings tritt bei mir der folgende Fehler auf, welchen ich nicht lösen kann, beziehungsweise nicht weiß warum er auftritt.

"Error reading from stream"

Das Problem liese sich warscheinlich leicht lösen wenn ich die genaue Bedeutung dieser Fehlermeldung kennen wurde.
Wäre nett wenn mich jemand aufklären könnte

MfG
Pascal
MfG Pascal
Win 7|T7250@2.0Ghz|3GB RAM|M8600GT
 

Ava

Gast

BeitragSo, Feb 14, 2010 23:54
Antworten mit Zitat
Hast Du Dein TStream-Objekt mal auf <> Null geprüft ?

mas93

BeitragMo, Feb 15, 2010 14:07
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich melde mich hier jetzt auch mal noch kurz zu Wort..
Also ich und Progger93 arbeiten an einem Datei versand programm.
Es gibt ein Server au den die Clients zugreifen können.

Bei einem Dateiversand wird die Datei in Päckchen aufgeteilt.
Client_a schickt die Päckchen an den Server, dieser sendet die Päckchen dann weiter an Client_b + Client_c.
Das komische ist, das bis zum Dateiversand selber alles funktioniert hat.
Das heißt Clients können sich am Server anmelden und alle anderen Clients auflisten usw.

Wir gehen also davon aus, dass es an unserer Dateiversand Routine liegt.

Diese sieht auf der Serverseite so aus:Code: [AUSKLAPPEN]
[...]
               Case "PACKAGE"
               Local filename:String = c.stream.ReadLine()
               For Local f:TFileTransfer = EachIn FileTransferList
                  Local size:Int = c.stream.ReadInt()
                  Local container:Byte[size]
                  
                                                '//PAKET EMPFANGEN
                  For Local i:Int = 0 To size - 1
                        container[i] = c.stream.ReadByte()
                        'WriteStdout(Chr(container[i]))
                  Next
                  

                                                '//PAKET AN ALLE WEITERVERSENDEN
                  For Local c2:TClient = EachIn f.clients
                        c2.stream.WriteLine("PACKAGE")
                        c2.stream.WriteLine("f" + filename)
                        c2.stream.WriteInt(size)
                        For Local i:Int = 0 To size - 1
                           c2.stream.WriteByte(container[i])
                        Next
                        c2.stream.SendMsg()   
                  Next
[...]



Wir sind jetzt gerade zum 3. Mal dabei das Projekt neu zu schreiben und dachten einfach, dass dieser Aufbau am sinvollsten wäre.
Habt ihr jetzt eventuell eine Idee woran das ganze liegen könnte?

Achja noch etwas: Wir haben herausgefunden, dass es abhängig von der Größe der Pakete ist ob die Fehlermeldung auftritt. Bei einem Paket von 1024 bytes geht genau 1 Dateiversand gut.
Wenn wir aber die Paketgröße auf 2000 bytes stellen kommt die Fehlermeldung mitten im Dateiversand..

Wäre nett wenn ihr uns Verbesserungsvorschläge geben könntet.

Mit freundlichen Grüßen
Mas93
www.lpbase.de
Meine Linkin Park Fanseite[Noch im Aufbau]

D2006

Administrator

BeitragSo, März 14, 2010 18:26
Antworten mit Zitat
Benutzer-Profile anzeigen
So, da mein aktuelles Problem gerade meine gesamte Motivation zum Abendbrot verspeist, muss ich mich hilfesuchend an diesen Thread wenden.

Es geht um TCP. Es gibt einen Host und ein oder zwei Joins. Mal der Einfachheit halber bei einem Join erklärt: Bricht dieser das Spiel ab, is der Server allein. Nun kann der das Spiel beenden und ein neues Spiel eröffnen. Dazu wird der TCP-Server geschlossen und dann wieder neueröffnet. Klappt prima. Aber andersrum: Wenn der Server das Spiel abbricht, wird der Join natürlich rausgehauen, was der auch superb erkennt. Wenn ich jetzt allerdings mit dem Host ein neues Spiel erstellen (und damit den Server wiedereröffnen) will, geht das nich, weil der Port noch belegt ist (es scheitert also bei setLocalPort). Der Code des Hosts zum Beenden des Servers ist in beiden Fällen identisch. Und in diesem wird die Verbindung zu allen Clients per close() gekappt und natürlich der Server an sich (ebenfalls per close()). Aber das scheint nicht zu klappen.

Wie muss ein TCP-Server die Verbindung zu einem Clienten ordentlich beenden? close() scheint nicht zu reichen. Aber was anderes find ich nicht. Das Problem treibt mich noch in den Wahnsinn. :/

Ich danke im Vorraus für jede Hilfe.
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2
 

Lion

BeitragSo, März 14, 2010 18:29
Antworten mit Zitat
Benutzer-Profile anzeigen
probier mal nach dem close auch noch stream=New TTcpstream und die ganze init sachen neu zu machen, ich meine dann gehts.
Wenn nicht, weiß ich leider auch nicht, hab mich gerad erst durch das ganze zeug durchgeschlagen und möglichst schnell wieder verdrängt Very Happy
Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb
Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb
AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

D2006

Administrator

BeitragSo, März 14, 2010 18:33
Antworten mit Zitat
Benutzer-Profile anzeigen
Es wird leider seit jeher ein neuer TCPStream angelegt. Crying or Very sad
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2
 

Lion

BeitragSo, März 14, 2010 18:43
Antworten mit Zitat
Benutzer-Profile anzeigen
BlitzMax: [AUSKLAPPEN]
Import vertex.bnetex

Global tcpstream:TTCPStream = New TTCPStream
tcpstream.Init()
If Not tcpstream.SetLocalPort(5552) Then Print "no port"
tcpstream.Close()

tcpstream = New TTCPStream
tcpstream.Init()
If Not tcpstream.SetLocalPort(5552) Then Print "no port"
tcpstream.Close()


Also bei mir geht das.

Keine ahnung ob du jetzt was anderes meinst...
Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb
Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb
AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

D2006

Administrator

BeitragSo, März 14, 2010 19:00
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich mein das schon so. Und genau so funktioniert das bei mir auch. Erst wenn sich ein Client verbunden hat, wird's Essig. Es sei denn, dieser hat davor die Verbindung von sich aus wieder getrennt. Dann geht's auch wieder.

EDIT: Neue heiße Infos. Was ich bisher verschwiegen habe: Ich arbeitete unter Mac OS X. Jetzt hab ich den Code auf meinen Windows-Rechner rübergeschoben und siehe da: Das funktioniert alles super bestens, genau wie es soll. Da scheint es also einen Bug unter OSX beim Schließen von TCP-Server zu geben. Hab leider kein Linux da um zu schauen, ob das Problem da auch auftaucht. Wäre sehr genial, wenn man den Bug beheben könnte, bin auch gerne bereit bei der Fehlersuche zu helfen.
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2
 

#Reaper

Newsposter

BeitragSo, März 14, 2010 21:02
Antworten mit Zitat
Benutzer-Profile anzeigen
@Dee:
So wie ich es verstanden habe, schließt du nur den Server-Stream, oder? Hast du mal versucht vorher die einzelnen Client-Streams zu schließen und dann erst den Server? Vielleicht hilft es ja was.


@mas93:
Auch wenn es schon etwas her ist, und ohne das ich mir den Code genauer angeschaut zu haben:
Vertex verwenden in seinen Beispielen zum senden und empfangen von Dateien eine Schleife:
Code: [AUSKLAPPEN]
While Stream.RecvMsg() ; Wend
...
While Stream.SendMsg() ; Wend

Ich denke mal das es an der For-Schleife beim empfangen der Pakete liegt, versuche nicht eine festgelegte Größe auszulesen, sondern verwende Stream.Eof() zum abfragen, ob überhaupt noch etwas zum auslesen da ist.
AMD Athlon 64 3500+, ATI AX800 Pro/TD, 2048 MB DRR 400 von Infineon, ♥RIP♥ (2005 - Juli 2015 -> sic!)
Blitz3D, BlitzMax, MaxGUI, Monkey X; Win7

D2006

Administrator

BeitragMo, März 15, 2010 16:38
Antworten mit Zitat
Benutzer-Profile anzeigen
#Reaper: schon versucht, ändert leider nichts.

Ich hab jetzt mal ne fixe Teststellung aufgesetzt, mit der man das Problem rasch nachvollziehen kann.

Der Server-Code: [AUSKLAPPEN]
SuperStrict

Import Vertex.BNetEx


AppTitle = "Host"
Graphics 320,200

Local timer:TTimer = CreateTimer(10, Null)

Const MODE_START:Int = 1
Const MODE_OPEN:Int = 2
Global mode:Int = MODE_START
Global server:TTCPStream
Global client:TTCPStream
Global msg:String
Repeat

   Cls
   
   Select mode
      Case MODE_START
      
         DrawText ">LEERTASTE< startet den Server",10,10
         If KeyHit(KEY_SPACE) Then startServer()
         
      Case MODE_OPEN
   
         DrawText ">E< beendet den Server",10,10
         updateServer()
         If KeyHit(KEY_E) Then stopServer()
   End Select
   
   DrawText msg, 10, 100
   
   Flip 0
   WaitTimer timer

Until KeyHit(KEY_ESCAPE) Or AppTerminate()

Function startServer()
   
   server = New TTCPStream
   
   If Not server.init() Then
      msg = "init failed"
      Return
   ElseIf Not server.SetLocalPort( 8000 ) Then
      msg = "port 8000 in use"
      Return
   ElseIf Not server.listen() Then
      msg = "listen failed"
      Return
   EndIf
   msg = "server open"
   mode = MODE_OPEN
   
End Function

Function stopServer()
   If client <> Null Then
      client.close()
      client = Null
   EndIf
   server.close()
   msg = "server stopped"
   server = Null
   mode = MODE_START
End Function

Function updateServer()
   Local tmp:TTCPStream
   
   If server = Null Then Return
   
   'Neuling da? ab in die temp-liste
   tmp = server.Accept()
   If tmp <> Null Then
      client = tmp
      msg = "client connected"
   EndIf

   If client <> Null Then
      
      If client.getState() < 1 Then
         msg = "client has quit"
         client.close()
         client = Null
      Else
      
         While client.RecvMsg() ; Wend
         While Not client.Eof() ; client.ReadByte(); Wend

      EndIf
   EndIf
   
End Function


Der Client-Code: [AUSKLAPPEN]
SuperStrict

Import Vertex.BNetEx


AppTitle = "Client"
Graphics 320,200

Local timer:TTimer = CreateTimer(10, Null)

Const MODE_START:Int = 1
Const MODE_CONNECTED:Int = 2
Global mode:Int = MODE_START

Global server:TTCPStream
Global msg:String
Repeat

   Cls
   
   Select mode
      Case MODE_START
      
         DrawText ">LEERTASTE< verbindet Server",10,10
         If KeyHit(KEY_SPACE) Then connectToServer()
      
      Case MODE_CONNECTED
   
         DrawText ">E< trennt die verbindung",10,10
         updateClient()
         If KeyHit(KEY_E) Then disconnect()
   End Select
   
   DrawText msg, 10, 100
   
   Flip 0
   WaitTimer timer

Until KeyHit(KEY_ESCAPE) Or AppTerminate()

Function connectToServer()
   server = New TTCPStream
   
   If Not server.init() Then
      msg = "init failed"
      Return
   ElseIf Not server.SetLocalPort() Then
      msg = "cannot reserve port"
      Return
   EndIf
   
   server.SetRemoteIP( TNetwork.IntIP("127.0.0.1") )
   server.SetRemotePort( 8000 )

   If Not server.connect() Then
      msg = "connect failed"
      Return
   EndIf
   
   msg = "connected to server"
   mode = MODE_CONNECTED
   
End Function

Function disconnect()
   If server = Null Then Return
   server.close()
   server = Null
   mode = MODE_START
   msg = "disconnected"
End Function

Function updateClient()
   Local tmp:TTCPStream
   
   If server = Null Then Return
   
   If server.getState() < 1 Then
      server = Null
      msg = "server was closed"
      mode = MODE_START
   Else
   
      While server.RecvMsg() ; Wend
      While Not server.Eof() ; server.ReadByte(); Wend

   EndIf
   
End Function


Nun wie man das Problem reproduzieren kann: beide Programme starten. Den Host per Leertaste den Server erstellen lassen und den Client per Leertaste verbinden lassen (Port 8000 muss frei sein). Nun ohne vorher den Client die Verbindung trennen zu lassen einfach im Host via E den Server beenden. Das merkt dann auch der Client ordnungsgemäß. Wenn man nun aber den Server wieder starten, kommt unter MacOS der Fehler, dass der Port noch belegt sei. Unter Windows nicht. Ebenso geht's supi prima, wenn vor dem Beenden des Servers der Client von sich aus die Verbindung trennt. Linuxianer können ja so lieb sein und das mal testen.
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2

ChaosCoder

BeitragMo, März 15, 2010 19:22
Antworten mit Zitat
Benutzer-Profile anzeigen
Funktioniert bei mir unter Mac OS X auch nicht... :/
Projekte: Geolaria | aNemy
Webseite: chaosspace.de

Vertex

BeitragDi, März 16, 2010 0:19
Antworten mit Zitat
Benutzer-Profile anzeigen
Also ein NetStream.Close() ist immer mit einem shutdown(s, SD_BOTH) (Kein Lesen und Schreiben) und anschließenden closesocket(s) verbunden, wobei hier die StdC-Funktion genutzt wird
Code: [AUSKLAPPEN]
void closesocket_( int s ){
#if _WIN32
   closesocket( s );
#else
   close( s );
#endif
}


Du könntest ja mal ein Step-Into von SetLocalPort machen, und mir sagen, obs bei INVALID_SOCKET_, bind_ oder getsockname_ scheitert; wenn Du pfiffig bist, auch den errno-Code dazu geben Smile

Des Weiteren kannst du mal
Code: [AUSKLAPPEN]
Const SO_REUSEPORT_ : Int = $0200
Local reuse : Int = True
setsockopt_(Stream.Socket, SOL_SOCKET_, SO_REUSEPORT_, Varptr(reuse), 4)

probieren, bevor du den Server-Socket an ein Port bindest. Sollte theoretisch einen nicht-freigegebenen Port dennoch nutzen können.

Ciao
Olli
vertex.dreamfall.at | GitHub

D2006

Administrator

BeitragDi, März 16, 2010 1:01
Antworten mit Zitat
Benutzer-Profile anzeigen
Hi Vertex,

danke schonmal für deine Hilfe. Es kracht bei bind_ und der errno-Code ist 48:
Zitat:
EADDRINUSE
Some other socket is already using the specified address.
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2

hamZta

Administrator

BeitragDi, März 16, 2010 1:08
Antworten mit Zitat
Benutzer-Profile anzeigen
Dann probier obenstehenden Code mit setsockopt und dafür mit SO_REUSEADDR aus. Was für einen Wert das hat weiß ich nicht auswendig, lässt sich aber sicher rausfinden.
Blog.

D2006

Administrator

BeitragDi, März 16, 2010 1:18
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich mach gerade einen auf Sherlock Holmes und hab folgendes herausgefunden: In dem fehlerhaften Szenario schlägt das "shutdown" beim Stream zum Clienten fehl. Errno-Code ist 60 und besagt:
Zitat:
#define ETIMEDOUT 60 /* Operation timed out */


Und jetzt hoffe ich, dass vertex einen Aha-Effekt hat und das Problem lösen kann. Smile
Für halbgare Workarounds is ja später noch Zeit, trotzdem danke für den Hinweis, hamZta.
Intel Core i5 2500 | 16 GB DDR3 RAM dualchannel | ATI Radeon HD6870 (1024 MB RAM) | Windows 7 Home Premium
Intel Core 2 Duo 2.4 GHz | 2 GB DDR3 RAM dualchannel | Nvidia GeForce 9400M (256 MB shared RAM) | Mac OS X Snow Leopard
Intel Pentium Dual-Core 2.4 GHz | 3 GB DDR2 RAM dualchannel | ATI Radeon HD3850 (1024 MB RAM) | Windows 7 Home Premium
Chaos Interactive :: GoBang :: BB-Poker :: ChaosBreaker :: Hexagon :: ChaosRacer 2

Vertex

BeitragMi, März 17, 2010 0:40
Antworten mit Zitat
Benutzer-Profile anzeigen
Weniger ein Aha als ein Hmm...
Also laut http://linux.die.net/man/2/shutdown kann shutdown nur folgende Fehlernummern haben:
Zitat:
EBADF
s is not a valid descriptor.
ENOTCONN
The specified socket is not connected.
ENOTSOCK
s is a file, not a socket.

Also ETIMEDOUT sollte gar nicht auftreten.

Funktioniert es denn, wenn Du shutdown auskommentierst?
vertex.dreamfall.at | GitHub
 

Lion

BeitragFr, März 26, 2010 20:15
Antworten mit Zitat
Benutzer-Profile anzeigen
Hab glaub nen bug,
Hatte nen TCP- sowie UDPStream auf ner windowsmaschine als server laufen, für den TCPStream hab ich timeouts gesetzt, für den UDPStream nicht, jedoch war der UDPStream anscheinend ebenfalls von diesem Timeout betroffen, zmd war die Verzögerung immer gleich dem gesetzten Timeout. Als ich für TCP den Timeout rausgenommen hatte war die UDP Verbindung normalschnell.
Intel Core 2 Quad 4x2.66 ghz - 4gb ddr2 - nvidia GeForce GTX660 2gb
Intel Atom 1x1.83 ghz - 2gb ddr2 - intel GMA 3150 256mb
AMD A10-5750M 4x2.5 ghz - 8 gb ddr4 - AMD R9 M290x

Gehe zu Seite Zurück  1, 2, 3 ... 10, 11, 12, 13  Weiter

Neue Antwort erstellen


Übersicht BlitzMax, BlitzMax NG Codearchiv & Module

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group