BNetEx
Übersicht

Gehe zu Seite Zurück 1, 2, 3 ... 8, 9, 10, 11, 12, 13 Weiter
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. |
![]() |
D2006Administrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ich finde eine solche Klasse recht sinnvoll.
Ich glaube wir haben schoneinmal darüber geredet gehabt, aufjedenfall empfehlenswert. |
||
![]() |
hamZtaAdministrator |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Ö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. ![]() 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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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. ![]() 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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 ![]() Sorry, schreibe ich mir auf die To-Do-Liste ![]() |
||
vertex.dreamfall.at | GitHub |
![]() |
ChaosCoder |
![]() Antworten mit Zitat ![]() |
---|---|---|
okay, schade, hätte ja sein können, schick ich einfach immer n ping raus, danke vertex =) | ||
Projekte: Geolaria | aNemy
Webseite: chaosspace.de |
fliege |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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? ![]() |
||
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Eine Fehlermeldung wäre nett.
Von welchem Type ist Client? |
||
fliege |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Oh, vergessen.. sorry.. ![]() Also Client ist TTCPStream, und der Fehler: Zitat: Compiler Error Identifier type does not match declared type |
||
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
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 |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
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
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group