BNetEx

Übersicht BlitzMax, BlitzMax NG Codearchiv & Module

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

Neue Antwort erstellen

 

Dreamora

BeitragMo, Apr 07, 2008 19:00
Antworten mit Zitat
Benutzer-Profile anzeigen
und was macht der Server genau? jeweils checken ob etwas da ist zum lesen vorm lesen nehm ich ma an und so damit er net ins "nichts" liest.
du kannst mit EOF aufm stream (glaub) sonst auch überprüfen ob er tot ist.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

D2006

Administrator

BeitragSo, Mai 04, 2008 23:31
Antworten mit Zitat
Benutzer-Profile anzeigen
Hallo,

hab auch mal ein paar Verständnisfragen: (Ich beziehe mich damit jeweils komplett auf TCP)

I) Wird der Empfangspuffer geleert, wenn ich eine Nachricht empfange? Also könnten mir noch nicht ausgewertete Bytes durch die Lappen gehen oder werden neue Nachrichten einfach "hinten rangehängt"?

II) Ich empfange Nachrichten derzeit so: Ich schaue mit RecvAvail(), ob es was zu empfangen gibt und wenn ja, dann empfange ich dies. Dann lese ich das erste Byte, weil das bei mir quasi der Nachrichtentyp ist, von dem die weitere Verarbeitung abhängt. Ende des Durchgangs. Sollte ich nun noch prüfen, ob ich nich noch eine Nachricht empfangen hatte, oder wird RecvAvail() auch True, wenn es zwar nichts mit "RecvMsg" zu empfangen gibt, aber noch unausgewertete Bytes im Puffer liegen?

III) Ist GetState nicht für Server vorgesehen? Solang noch auf eine Verbindung gewartet wird, gibt serverstream.GetState() brav ne 1 zurück. Sobald sich aber einer verbindet, kommt glaub ich ne 0 (jedenfalls keine 1 mehr). Lasse ich die Prüfung allerdings weg, funktioniert die Kommunikation (kleiner Testchat) trotzdem tadellos. Mach ich was falsch, ist das ein Bug oder ist GetState dafür einfach nicht vorgesehen?

Ansonsten bin ich von dem Modul echt begeistert. *Daumen hoch*
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

BeitragMo, Mai 05, 2008 0:11
Antworten mit Zitat
Benutzer-Profile anzeigen
Dee:
I) Nein, sie gehen nicht verloren. Sie werden erst dann aus dem internen Puffer gelöscht, wenn sie durch ReadInt usw. ausgelesen wurden.

II) RecvAvail gibt die Anzahl der Bytes zurück, die noch mit RecvMsg empfangen werden können. Size hingegen gibt die Anzahl an Bytes zurück, die schon mit ReadInt usw. ausgelesen werden können.

III) Habe ich noch nicht ausprobiert. Mit 0 wird aber normalerweise ein Disconnected signalisiert.

-----

Zum Thema Timeouts bei UDP: Es gibt auch eine SetTimeouts Methode bei TUDPStream. Damit kann man die Tiemouts fürs Senden und Empfangen einstellen.

-----

Ein paar Verbesserungsvorschläge die ich mir überlegt habe:
- UDP Pakete werden z. Z. von unterschiedlichen Absendern in einem Puffer gesichert. Hinter jedem RecvMsg kann ein anderer Absender stecken. Deswegen wäre es vllt. nicht verkehrt, eine Klasse TPackege einzuführen, die von TStream abgeleitet ist. Diese hat dann die 2 Eigenschaften SenderIP und SenderPort.
- Die Puffer werden bei jedem Byte zusätzlich oder weniger neu allokiert. Besser wären Puffer die in 2er-Potenzen-Größen ansteigen oder abfallen. Das würde unbedeutend mehr Speicher kosten dafür aber schneller sein.
- CRC32-, CRC16- und MD5-Funktion der Klasse TNetwork hinzufügen, da ich denke, dass das sehr häufig benutzte Funktionen bei der Netzwerkprogrammierung sind.

Was haltet ihr davon?

mfg olli
vertex.dreamfall.at | GitHub

kog

BeitragMo, Mai 05, 2008 0:53
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich finde eine solche Klasse recht sinnvoll.
Ich glaube wir haben schoneinmal darüber geredet gehabt, aufjedenfall empfehlenswert.

hamZta

Administrator

BeitragMo, Mai 05, 2008 1:36
Antworten mit Zitat
Benutzer-Profile anzeigen
Vertex hat Folgendes geschrieben:
Ein paar Verbesserungsvorschläge die ich mir überlegt habe:
- UDP Pakete werden z. Z. von unterschiedlichen Absendern in einem Puffer gesichert. Hinter jedem RecvMsg kann ein anderer Absender stecken. Deswegen wäre es vllt. nicht verkehrt, eine Klasse TPackege einzuführen, die von TStream abgeleitet ist. Diese hat dann die 2 Eigenschaften SenderIP und SenderPort.

Sicherlich sehr praktisch und hilfreich in der UDP-Programmierung

Vertex hat Folgendes geschrieben:
- Die Puffer werden bei jedem Byte zusätzlich oder weniger neu allokiert. Besser wären Puffer die in 2er-Potenzen-Größen ansteigen oder abfallen. Das würde unbedeutend mehr Speicher kosten dafür aber schneller sein.

Hätte eigentlich ein "Waaaas? Jedes Byte wird einzeln alloziert?" verdient, aber nachdem du ja draufgekommen bist lassen wirs durchgehen. Pflicht!

Vertex hat Folgendes geschrieben:
- CRC32-, CRC16- und MD5-Funktion der Klasse TNetwork hinzufügen, da ich denke, dass das sehr häufig benutzte Funktionen bei der Netzwerkprogrammierung sind.

Halte ich jetzt für BNetEx nicht unbedingt notwendig, das könnte man in ein anderes Modul auslagern.

hamZta
Blog.

Vertex

BeitragMo, Mai 05, 2008 10:42
Antworten mit Zitat
Benutzer-Profile anzeigen
kog: meinst du die TPackage-Klasse oder oder die Funktionen für TNetwork? (Wir können uns ja nochmal im ICQ unterhalten)

hamZta:
Jup, bei einer Puffergröße von 7 Byte gibt es jetzt nicht 7 mal 1 Byte große Puffer aber bei WriteLine("Hallo") wird insgesamt 6 mal neu allokiert: fünfmal neu für "Hallo" und dann einmal für 13 und 10. Das WriteLine jedes Zeichen einzeln abspeichert ist sicher eine große Performence-Bremse.

Ich habe hier eine Testklasse mit kapazitären Stream. Startgröße ist 16 Byte. D. H. bis 16 Byte Größe wird nicht neu allokiert. Beim 17ten Byte verdoppelt sich die Kapazität auf 32 Byte. So wird erst beim 33ten Byte neu allokiert auf 64 Byte Kapazität.
Das gilt auch beim Auslesen: bei einer Puffergröße von 128 Byte sollen 64 Byte ausgelesen werden. Hier wird die Kapazität halbiert.

Hier also meine Testklasse. Vllt. könnt ihr ein wenig damit herumspielen, damit auch sichergestellt ist, dass sie funktioniert:

Code: [AUSKLAPPEN]
SuperStrict

Framework BRL.Blitz
Import BRL.Stream

Local t : TTestStream

t = New TTestStream
t.WriteLine("ABCDEFGHIJKLMNOPQRSTUVW")
t.WriteLine("XYZ01234567890abcdefghi")
t.WriteLong(55566677)
t.WriteLong(55566677)
t.WriteLong(55566677)
t.WriteLine("Hello, world!")

DebugLog t.ReadLine()
DebugLog t.ReadLine()
DebugLog t.ReadLong()
DebugLog t.ReadLong()
DebugLog t.ReadLong()
DebugLog t.ReadLine()


Type TTestStream Extends TStream
   Field buffer     : Byte Ptr
   Field capacity   : Int
   Field bufferSize : Int
   Field position   : Int

   Method New()
      capacity   = 16
      buffer     = MemAlloc(capacity)
      bufferSize = 0
      position   = 0
   End Method
   
   Method Delete()
      MemFree(buffer)
      buffer     = Null
      capacity   = 0
      bufferSize = 0
      position   = 0
   End Method
   
   Method Read:Int(buf:Byte Ptr, size:Int)
      Local newCapacity : Int
      
      If size > bufferSize Then size = bufferSize
      
      newCapacity = capacity
      While newCapacity > bufferSize - size And ..
            newCapacity > 16
         newCapacity :Shr 1
      Wend
      If newCapacity < bufferSize - size Then newCapacity :Shl 1
      
      MemCopy(buf, buffer + position, size)
      bufferSize :- size
      position :+ size
      
      If newCapacity <> capacity Then
         Local temp : Byte Ptr
         
         temp = MemAlloc(newCapacity)
         MemCopy(temp, buffer + position, bufferSize)
         MemFree(buffer)
         
         buffer = temp
         capacity = newCapacity
         position = 0
      EndIf
      
      Return size
   End Method

   Method Write:Int(buf:Byte Ptr, size:Int)
      Local newCapacity : Int
   
      newCapacity = capacity
      While newCapacity < bufferSize + size
         newCapacity :Shl 1
      Wend
      If newCapacity <> capacity Then
         buffer = MemExtend(buffer, capacity, newCapacity)
         capacity = newCapacity
      EndIf
      
      MemCopy(buffer + bufferSize, buf, size)
      bufferSize :+ size
      
      Return size
   End Method

   Method Eof:Int()
      Return bufferSize = 0
   End Method
   
   Method Size:Int()
      Return bufferSize
   End Method

   Method Flush()
      MemFree(buffer)
      capacity   = 16
      buffer     = MemAlloc(capacity)
      bufferSize = 0
      position   = 0
   End Method

   Method Close()
      Flush()
   End Method
End Type


Also das kommt auf alle Fälle so rein. Bei der UDP-Package-Klasse könnt ich mir vorstellen, dass das dann etwas kompliziert gehandhabt werden wird und bei den Checksum/Hashfunktionen weiß ich es auch noch nicht.

mfg olli
vertex.dreamfall.at | GitHub
 

#Reaper

Newsposter

BeitragSa, Mai 17, 2008 20:08
Antworten mit Zitat
Benutzer-Profile anzeigen
Also ich bin mir nun nicht sicher, ob ich irgendwas falsch verstanden habe, aber seit wann gibt GetLocalPort() den Remote-Port zurück?
Also, folgendes:
Habe mir einen TCP-Host gebastet. Wenn nun eine neue Verbindung eingeht, wird ja bei TCP ein neuer Stream erzeugt, z.B.:

NewStream = HostStream.Accept()

Jetzt will ich den Port vom neuen Client herausbekommen, sollte ja dann folgendermaßen funktionieren:

Client.Port = NewStream.GetRemotePort()

Die Client.Port ist danach aber 1234, was nicht sein kann, da das der Port vom Host ist. Beides läuft auf dem selben Rechner. Wenn ich jedoch anstatt GetRemotePort() GetLocalPort() benutzte, bekomme ich den richtigen Port zurückgeliefert. Stimmt da was nicht, oder stehe ich auf dem Schlauch? ^^

Danke.

MfG
#Reaper
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

Vertex

BeitragSa, Mai 17, 2008 22:41
Antworten mit Zitat
Benutzer-Profile anzeigen
Dem NewStream kannst du dennoch was senden, oder? Ich habe gedacht, der neue Client mit Accept soll eine Art Kopie vom tatsächlichen Client sein. Beim Original hat man ja mit SetRemotePort/IP die Adresse des Server eingegeben. Aber vllt. hast du einen plausiblen Grund, Remote mit Local zu vertauschen.

Ansonsten habe ich heute die kapazitären Puffer eingebaut und auch gleich einen Bug im UDP-Stream gefunden. Er hatte bisher immer den Receivetimeout ignoriert, weil ich eine 0 statts recvTimeout angegeben habe.

Die neue Version wird dennoch noch auf sich warten müssen, da ich noch ein paar kosmetische Sachen ändern möchte (das Interface wird nicht verändert!)

mfg olli

Edit: CRC16, CRC32 und MD5 sind bereits implementiert und stimmen mit den PHP Funktionen überein. Bei den CRC Funktionen können sogar unterschiedliche Generatorpolynome verwendet werden. Mal schauen, was ich die Tage noch so rein mache. SHA, Huffman, RC4, Blowfish usw. wären möglich. Damit würde das Utilsmodul die gängigsten Prüfsummen-, Hash, Verschlüsselungs- und Kompressionsfunktionen beinhalten.

Achja, Exceptions statt Rückgabewerte werden eventuell folgen. Das macht die Fehlerbehandlung benutzerfreundlicher.
vertex.dreamfall.at | GitHub
 

#Reaper

Newsposter

BeitragDi, Mai 20, 2008 20:46
Antworten mit Zitat
Benutzer-Profile anzeigen
Öh...also...öhm..^^

Entweder habe ich da was von Anfang an falsch verstanden, oder.. :-/
Also ich habe einen Stream vom Host (Port z.B.: 1001) zum Client (Port z.B.: 1002). Wenn der Host nun den Port vom Client wissen will (^.^), muss ich ja ClientStream.GetRemotePort() benutzten. Nur liefert GetRemotePort beim Host 1001, nicht 1002 wie es sein sollte.
Der Quellcode ist etwas zu lang/unübersichtlich, um ihn hier Posten zu können und er was hilft. Falls ich ihn doch Posten soll, sag bitte bescheid. Smile

MfG
#Reaper
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

Vertex

BeitragMi, Mai 21, 2008 18:07
Antworten mit Zitat
Benutzer-Profile anzeigen
Es geht hier nicht um den Quellcode sondern um die Logik. Die beiden Ports für Accept-Streams zu vertauschen ist nicht das Problem. Ich brauche einen nachvollziehbaren Grund, warum Client.GetRemotePort() nicht den Port des Hosts sondern den, des Clients zurückgeben soll.

Mein Gedanke dazu:
Client = Server.Accept()
Client soll sich so verhalten, wie der TCP-Stream, der den Server kontaktiert. Also praktisch eine Art Kopie vom Original. Und das Original hat nunmal den Port des Servers als Remote-Port.

mfg olli
vertex.dreamfall.at | GitHub
 

#Reaper

Newsposter

BeitragMi, Mai 21, 2008 18:24
Antworten mit Zitat
Benutzer-Profile anzeigen
Hmm.. nach meiner Logik ist vom Server aus der Remote-Port der Port beim Client. War doch auch bei B3D so, meine ich.
Aber nagut, wenn das so rum ist. Das wäre dann wenigstens geklärt. Muss ich mir nur merken. Wink

MfG
#Reaper
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

BtbN

BeitragMi, Mai 21, 2008 18:28
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich seh das aber auch so. LocalPort sollte immer der Port sein, wie er lokal auf dem das Programm ausführenden Rechner ist. Und der RemotePort immer der port, der eben NICHT auf meinem Rechner ist.

ChaosCoder

BeitragDi, Sep 16, 2008 19:03
Antworten mit Zitat
Benutzer-Profile anzeigen
Okay, hab nich viel Zeit, hier mein Problem:

Ich versuche mittels TCPStream mit einem Server zu verbinden, um über HTTP POST-Daten an ein php script zu übergeben und die Antworten auszulesen. Das Verbinden klappt super, die Antworten erhalt ich auch richtig, nur was mir zu schaffen macht, ist die Tatsache, dass wenn meine Firewall mein Programm blockt (oder ein Internetverbindungsabbruch besteht) wartet der ca 12 Sekunden oda so (habs nich genau nachgemessen) und kriegt dann anscheinend n Timeout. Ich möchte dieses Timeout allerdings nicht so lang haben (max 1s).

Connecten tu ich mittels TCPStream.Connect()
SetTimeouts hat bei mir nix gebracht?!?

Die einzige alternative die mir einfällt ist vorher anzupingen, allerdings ist das nicht die sauberste Lösung, gibts noch was anderes?

lg,
chaos
Projekte: Geolaria | aNemy
Webseite: chaosspace.de

Vertex

BeitragDi, Sep 16, 2008 19:20
Antworten mit Zitat
Benutzer-Profile anzeigen
SetTimeouts haben keine Wirkung auf die Connect-Methode, korrekt! Ich habe mir das mal früher angeschaut, wie man die Timeouts fürs Connecten setzt, weiß aber nicht mehr wie, nur, dass es kompliziert war Smile Das hat nämlich schon viele angeätzt, die einen Portscanner schreiben wollten.

Sorry, schreibe ich mir auf die To-Do-Liste Smile
vertex.dreamfall.at | GitHub

ChaosCoder

BeitragDi, Sep 16, 2008 22:00
Antworten mit Zitat
Benutzer-Profile anzeigen
okay, schade, hätte ja sein können, schick ich einfach immer n ping raus, danke vertex =)
Projekte: Geolaria | aNemy
Webseite: chaosspace.de
 

fliege

BeitragDi, Jan 06, 2009 17:51
Antworten mit Zitat
Benutzer-Profile anzeigen
Okay, irgendwie komm ich nicht dahinter..
Code: [AUSKLAPPEN]
msg:String = Client.ReadLine()

Warum kann ich das nicht kompilieren? - Bin ich da zu irgendwas zu blöde oder hab ich nur was verwechselt? Embarassed

BtbN

BeitragDi, Jan 06, 2009 18:22
Antworten mit Zitat
Benutzer-Profile anzeigen
Eine Fehlermeldung wäre nett.
Von welchem Type ist Client?
 

fliege

BeitragDi, Jan 06, 2009 18:28
Antworten mit Zitat
Benutzer-Profile anzeigen
Oh, vergessen.. sorry.. Embarassed
Also Client ist TTCPStream, und der Fehler:
Zitat:

Compiler Error
Identifier type does not match declared type

BtbN

BeitragDi, Jan 06, 2009 18:52
Antworten mit Zitat
Benutzer-Profile anzeigen
msg scheint kein string zu sein, aber du sagst es soll einer sein.
Ich kann nur SuperStrict ans herz legen, wenn meine Vermutung richtig ist.
 

fliege

BeitragDi, Jan 06, 2009 19:29
Antworten mit Zitat
Benutzer-Profile anzeigen
Okay, nachdem msg:string global definiert wurde und superstrict angeschalten funktionierts.. nur noch eine Frage.. Warum? ^^

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

Neue Antwort erstellen


Übersicht BlitzMax, BlitzMax NG Codearchiv & Module

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group