BNetEx
Übersicht

Gehe zu Seite Zurück 1, 2, 3 ... 10, 11, 12, 13 Weiter
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Bau eine Test-Verbindung in einem Separaten Thread auf, und guck, ob sie funktioniert, wenn es wichtig ist, dass das ganze nicht blockiert. | ||
![]() |
ChaosCoder |
![]() Antworten mit Zitat ![]() |
---|---|---|
Wow, die Idee ist nicht schlecht. Danke BtbN! | ||
Projekte: Geolaria | aNemy
Webseite: chaosspace.de |
![]() |
klin |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
||
![]() |
Progger93Betreff: Probleme mit Dateiversand [TCP] |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
AvaGast |
![]() Antworten mit Zitat |
|
---|---|---|
Hast Du Dein TStream-Objekt mal auf <> Null geprüft ? | ||
![]() |
mas93 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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] |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 ![]() |
||
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 |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
Es wird leider seit jeher ein neuer TCPStream angelegt. ![]() |
||
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
BlitzMax: [AUSKLAPPEN] Import vertex.bnetex 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 |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
@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 |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
#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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
Funktioniert bei mir unter Mac OS X auch nicht... :/ | ||
Projekte: Geolaria | aNemy
Webseite: chaosspace.de |
![]() |
Vertex |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 ![]() 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 |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() |
hamZtaAdministrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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. |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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. ![]() 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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group