BNetEx
Übersicht

Gehe zu Seite Zurück 1, 2, 3, 4, 5, 6 ... 11, 12, 13 Weiter
Ronny |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Kann es zusaetzlich noch sein, dass Bnetex unter Linux Probleme mit der Rueckgabe von Subnetzmasken bzw. der Ermittlung von Broadcast-Adressen hat? Unter Windows funktioniert alles prima (was wohl an den extern-Deklarationen spezifischer API-Befehle liegt) - unter Linux hingegen sind die Rueckgabewerte 0.
Und noch eine Frage.... Auf meinem Notebook laeuft ein Bluetoothstack, WLan und normales LAN... gibt es nun eine elegante Methode auf allen 3 Netzwerkteilnehmern zu horchen, ob ein Broadcast-Paket eintrifft? bzw. auf allen im PC eingebauten Netzwerkkarten ein Broadcast abzuschicken? Die "erste" Netzwerkschnittstelle, die Bnetex zurueckgibt, ist diejenige, die bei Windows in der Netzwerkliste an erster Stelle steht (was man ja umsortieren kann). In meinem Problem geht es darum, dass der "Server" eines Spieles im lokalen Netzwerk per Broadcastadresse das Hosten eines Spieles publiziert, sprich ein Announcement herausschickt... alle Clients im selben Subnetz bekommen nun dieses Paket in ihre Empfangsliste und schicken ein Join zurueck (falls sie an diesem Spiel teilnehmen wollen ;D). Wenn nun aber beispielsweise mein Notebook den Server uebernehmen will - und ich beispielsweise aus Langeweile mein Wlan aktiviert habe, aendert sich die "als erste zurueckgegebene IP-Addi" und ein Broadcast-Paket geht in ein voellig anderes Subnetz. Was ich also "woellte", waere eine Funktion, die mir das genutzte Geraet zurueckgibt - damit dieses zwischengespeichert werden und bei Bedarf explizit genutzt werden kann (um im Notfall wieder auf "nimm das Erstbeste" zurueckzuschalten). Zurueck zum Text: gibt's da eine elegante Moeglichkeit oder wird das dann eine Menge Gefrickel? Und weil ich gerade am Schreibseln bin: inwieweit kann man das "Geruckel" bei langlaufenden Paketen minimieren? Wenn Ich mit einem normalen Webserver kommuniziere (bspweise um die Onlinespiel-Liste zu aktualisieren), dann bleibt die Applikation fuer die Laufzeit der Pakete stehen - was natuerlich visuell zu unangenehmen Rucklern fuehrt. Ich schaetze nun allerdings, dass ohne Multithreading das Problem bestehen bleiben wird - oder habe ich da was uebersehen? bye Ron |
||
Ronny |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Sorry for bumping...
Das Linuxproblem besteht immernoch ;D. bye Ron |
||
![]() |
Vertex |
![]() Antworten mit Zitat ![]() |
---|---|---|
Habe leider keine Zeit z. Z. dafür. Mir fällt in erster Linie keine Lösung auf Berkeley Socket Ebene ein, zwischen mehreren Netzwerkkarten auszuwählen. Ich habe hier auch kein großes LAN o. ä., wo ich mal deine Broadcast Geschichte testen könnte.
Das Geruckel hatte ich schon mal auch unter Linux. Denke, es liegt an pselect, was noch nicht eingebaut ist. Ansonsten kannst du, laut Dreamora, Multithreading vergessen. Wäre aber gerade für Netzwerk Sachen essentiell. Pech ![]() mfg olli |
||
vertex.dreamfall.at | GitHub |
Ronny |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Das Ruckeln ist ja auch unter Windows...was Linux nicht alleine im Regen stehen laesst.
Fuer Bastelgeschichten kann ich mich gerne zur Verfuegung stellen - habe hier 2 Notebooks und 2 PCs die wahlweise per Lan oder Wlan miteinander kommunizieren und wunschweise per VPN mit einem anderen Lan (1NB + 4 PCs ) verbunden werden kann. Die "Broadcastgeschichte" funktioniert insoweit ganz gut, sofern man wie schon erwaehnt, bspweise unter XP die Anordnung (Reihenfolge) der Netzwerkschnittstellen so gestaltet, dass die zu verwendende Karte ganz oben gelistet ist. Falls noch jemand dieses Problem haben sollte- per Ini-Datei (oder XML oder...) eine Default-Fallback-IP angeben, die wird dann Code-intern bei den verfuegbaren Netzadaptern gesucht und falls gefunden - wird eben diese Schnittstelle genutzt. Ist halt nur schade, dass hier ein Usereingriff von Noeten ist. bye Ron |
||
![]() |
Jan_Ehemaliger Admin |
![]() Antworten mit Zitat ![]() |
---|---|---|
falls mal was zu testen ist,
habe hier ca. 30 PCs in 5 Netzen mit Firewalls dazwischen. |
||
between angels and insects |
Ronny |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Es ging hier nicht um irgendwelche Laengenvergleiche... vielmehr darum, dass fast alle PCs unterschiedliche Hardware einsetzen, diverse OS am Laufen haben und somit - nicht wie in Firmenumgebungen - verschiedenste Testszenarien genutzt werden koennen.
Hilfreiche Kommentare waeren mir allerdings gelegener... also ... schmeiss Deine 30 PCs an und schwing die Tasten... Anti-Ruckel und Linux warten auf Deine erfrischenden Ideen ;D. bye Ron |
||
![]() |
Vertex |
![]() Antworten mit Zitat ![]() |
---|---|---|
Musste empört feststellen, das BNetEx v1.65 gar nicht unter Linux lauffähig ist. Habe heute das Problem behoben. Danke für den Ansporn hier an k.o.g. ![]() Release gibt es dann zusammen mit dem behobenen pselect Problem, denn ich habe z.Z. Kubuntu hier als VM laufen und kann damit Programmieren. mfg olli |
||
vertex.dreamfall.at | GitHub |
Ronny |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Da ich keinen Mac habe und Mac ja schon ewig gewisse Affinitaeten zu Linux aufwies... unter MacOS XY funzt BnetEx aber oder?
Ist auf alle Faelle schonmal schoen, dass sich Warterei lohnt *wartet. Danke Vertex, bye Ron |
||
![]() |
Vertex |
![]() Antworten mit Zitat ![]() |
---|---|---|
Neue Version 1.66:
http://vertex.dreamfall.at/bnet/bnetex166.zip Beinhaltet Bugfixes auschließlich für Linux. Darunter Das Problem mit den Paketgrößen sowie mit der Signalmaske. Erfolgreich getestet unter Kubuntu und Debian. Der Eintrag auf dem BlitzHelp Server muss noch auf sich warten lassen. mfg olli |
||
vertex.dreamfall.at | GitHub |
![]() |
Mathias-Kwiatkowski |
![]() Antworten mit Zitat ![]() |
---|---|---|
also ich wäre interessiert an diesem UDP teil nur muss sagen wgal wie es funktioniert nich,
das mod habe ich in C:\Programme\BlitzMax\mod\bnetex.mod\ also sollte das da ja eigentlich richtig liegen oder? dann abe ich rebuild all Mods gemacht... und die examples funktionieren nicht, bitte fragt nicht nach einer fehlermeldung, das kann eh keiner entziffern... eine meldung länger als der screen! habe ich was falsch gemacht? |
||
![]() |
FOODy |
![]() Antworten mit Zitat ![]() |
---|---|---|
C:\Programme\BlitzMax\mod\vertex.mod\bnetex.mod\
>_> Steht sogar in der BlitzMax Help. Gruß, FOODy |
||
BlitzMax + MaxGUI, 64-bit Arch Linux: Intel Core² E8500 | 8 GB Ram | GeForce GTX 460 · 1024 MB |
![]() |
ICE TRUCK |
![]() Antworten mit Zitat ![]() |
---|---|---|
man merkt dass es noch in linux buggt^^ muiss wohl jedes mal die ports ändern damits geht? was solln das ![]() |
||
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Irgendwie ist es leider nicht nur unter Linux buggy. Selbst in Windows bleibt der Stream noch "erhalten". Wenn man eine TCP-Verbindung öffnet sieht man mit dem Dos-Befehl (ist das nun eigentlich noch Dos?) "netstat" die bestehenden Verbindungen. Nachdem man sein Programm beendet hat (führe vorher auch noch die Methode Close() aus) bleibt der Stream auf "Wartend", zu mindestens eine Zeit lang...? :-/
Wenn ich dann mein Programm neustarte, sagt er nicht, dass er den Port nicht setzen konnte, sondern dass er nicht zum Host geconnten konnte. Mit einem anderem Port gehts dann wieder... Und habe eben festgestellt, dass wenn ich .Close() weglasse, geht es wieder ohne Probleme :O Ansonsten finde ich das Modul echt klasse und nützlich ![]() |
||
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 ![]() |
---|---|---|
Der Bug von ICE TRUCK hat sich übrigens als nichtig ergeben(wir hatten das mal im ICQ geklärt)
#Reaper: Ich brauche ein Beispielprogramm dazu, sonnst kann ich dazu nix sagen. Code: [AUSKLAPPEN] Method Close()
If Self.Socket <> INVALID_SOCKET_ Then ' No receiving and sending shutdown_(Self.Socket, SD_BOTH) closesocket_(Self.Socket) Self.Socket = INVALID_SOCKET_ EndIf End Method Das shutdown mit SD_BOTH verhindert halt ein weiteres Senden und Empfangen über den Socket und closesocket gibt den Socket an das OS wieder frei. Was du mal testen kannst ist, shutdown auszukommentieren, so das nur noch closesocket ausgeführt wird. Ansonsten ruft BMax doch durch den GC am Ende die Destroy Methode jeder Instanz auf. Die Destroy Methode ruft bei BNetEx die Close Methode vorher auf, und gibt den Sende- und Empfangspuffer frei. Sollte also keinen Unterschied machen, ob du nun explizit Close() aufrufst oder nicht. Wie sieht es denn mit Firefox beispielsweise auf? Wenn Firefox eine Verbindung trennt, wird das sofort in NetStat angezeigt? mfg olli |
||
vertex.dreamfall.at | GitHub |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Naja, auf den GC würd ich mich nie so richtig verlassen.
Die Delete-Method wird eher selten mal aufgerufen, ob sie am Ende des Programms aufgerufen wird, weiß man auch nicht so sicher. Code: [AUSKLAPPEN] SuperStrict
Framework BRL.Blitz Type TBla Global cnt:Int Method New() cnt :+ 1 WriteStdout("Neuer!~n") EndMethod Method Delete() cnt :- 1 WriteStdout("Weg, Noch da: "+cnt+"~n") EndMethod EndType Function TuWas() Local bla:TBla = New TBla EndFunction For Local i:Int = 0 Until 100 '1000 TuWas() 'GcCollect() Next End Mal mit 100, mal mit 1000 und mal mit und mal ohne GcCollect() Probieren, immer andere ergebnisse. Bei 100+Kein GcCollect() wird die Delete()-Methode bei mir nicht einmal aufgerufen. |
||
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Mmm.. eigentlich dürfte der GC bei mir da eher nicht so eine große Rolle spielen...(?) :-/
Hier mal der Code: Code: [AUSKLAPPEN] SuperStrict Framework BRL.System ?win32 Import BRL.Win32MaxGUI ?linux Import BRL.FltkMaxGUI ? Import BRL.EventQueue Import Vertex.BNetEx Type TServer '------------------------------------------ Server-Type ------------------------------------------- # Const Host :String = "85.25.136.48" , .. Port :Int = 1234 , .. TimeOut :Int = 5000 Global Stream :TTCPStream = Null , .. IP :Int = 0 Function Connect() IP = TNetwork.IntIP( Host ) Try Stream = New TTCPStream If Not Stream.Init() Then Throw("Can't create socket") Stream.SetTimeouts( 10, TimeOut ) If Not Stream.SetLocalPort(3434) Then Throw("Can't set local port") Print Stream.GetLocalPort() Stream.SetRemoteIP( IP ) Stream.SetRemotePort( Port ) If Not Stream.Connect() Then Throw("Can't connect to host") TClient.Write "Connected to Server " + Host + ":" + Port Catch Exception:Object Notify("Error: ~n"+Exception.ToString()) End End Try End Function Function Close() If Stream Then Stream.Close() End End Function End Type Type TClient Const Version :String = "0.1.0005" , .. Title :String = "BMax-Chat v." + TClient.Version Function Write( Txt:String ) AddTextAreaText( TWindow.ChatArea, Txt+"~n" ) End Function Function SendMsg( Txt:String ) If Txt <> "" Then TServer.Stream.WriteLine( Txt ) While TServer.Stream.SendMsg() ; Wend EndIf End Function Function CheckMsg() Local Result :Int = 0 If TServer.Stream.GetState() <> 1 Then Notify("Error: ~nStream terminated!") TServer.Close() EndIf Result = TServer.Stream.RecvAvail() If Result = -1 Then Notify("Error: ~nSocket Error") ElseIf Result > 0 Then While TServer.Stream.RecvMsg() ; Wend If TServer.Stream.Size() > 0 Then While Not TServer.Stream.Eof() Write( TServer.Stream.ReadLine() ) Wend EndIf EndIf End Function End Type Type TWindow Global Width :Int = 800 , .. Height :Int = 600 , .. PosX :Int = (GadgetWidth(Desktop()) / 2) - (TWindow.Width / 2) , .. PosY :Int = (GadgetHeight(Desktop()) / 2) - (TWindow.Height / 2) , .. Style :Int = WINDOW_TITLEBAR|WINDOW_RESIZABLE|WINDOW_CLIENTCOORDS , .. BHeight :Int = 20 , .. BWidth :Int = 100 , .. BStyle :Int = BUTTON_OK , .. TStyle :Int = TEXTAREA_WORDWRAP|TEXTAREA_READONLY Global Window :TGadget = Null , .. ChatArea :TGadget = Null , .. ChatPanel :TGadget = Null , .. ChatField :TGadget = Null , .. ChatButton :TGadget = Null Function Start() AppTitle = TClient.Title Window = CreateWindow( TClient.Title, PosX, PosY, Width, Height, Null, Style ) ChatArea = CreateTextArea( 0,0, Width, Height-BHeight, Window, TStyle ) ChatPanel = CreatePanel( 0, 0, Width, Height, Window ) ChatField = CreateTextField( 0, Height-BHeight, Width-BWidth, BHeight, ChatPanel ) ChatButton = CreateButton( "Send", Width-BWidth, Height-BHeight, BWidth, BHeight, ChatPanel, BStyle) End Function End Type TWindow.Start() TServer.Connect() While Not AppTerminate() TClient.CheckMsg() Select PollEvent() Case EVENT_GADGETACTION Select EventSource() Case TWindow.ChatButton TClient.SendMsg( GadgetText( TWindow.ChatField ) ) SetGadgetText( TWindow.ChatField, "" ) End Select Case EVENT_WINDOWCLOSE TServer.Close() End Select Delay 25 Wend End Wenn ich das Stream.Close() in meiner .Close() Funktion auskommentiere, geht es ja :-/ Und wegen ICE TRUCK's Bug: Genau den selben habe ich ja auch unter Linux^^ (Hab da allerdings das mit Close() noch nicht ausprobiert) Hab das auch mal auskommentiert, funktioniert dennnoch nicht ![]() Oder habe ich vielleicht doch nur was falsch gemacht? Habe mich aber eigentlich an deine Beispielecodes gehalten ![]() PS: Ansonsten: Braucht man en GC dafür? Habe davon nicht so viel Ahnung ![]() |
||
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 ![]() |
---|---|---|
Dieser "Portbug" lässt sich anscheinend nicht beheben:
http://www.cim.mcgill.ca/~fran...ode77.html Das OS braucht also ca. eine Minute, um den Port wieder für den nächsten Socket freizugeben. Geschlossen wurde er aber dennoch. Und wegen dem GC: Ja, ich habe jetzt auch ein paar Tests durchgeführt, und das Ergebnis war ernüchternd. Nichtmal bei End werden die Destructors der Instanzen aufgerufen. Das macht mir doch recht Sorgen wegen Memoryleaks. mfg olli |
||
vertex.dreamfall.at | GitHub |
![]() |
BtbN |
![]() Antworten mit Zitat ![]() |
---|---|---|
Um beim beenden der App aufzuräumen solltest du OnEnd benutzen, um eine Aufräum-Funktion zu erstellen, und wenn zur laufzeit in Object aus dem speicher entfernt wird, wird der Dtor auch korreckt aufgerufen. Nur wann der GC das tut, bleibt ein geheimnis. | ||
#ReaperNewsposter |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Dass das OS so lange dafür braucht, ist irgendwie seltsam o_O
Naja, dann... Wegen dem GC: Wenn der GC unentwegs aufgerufen werden würde, wäre das ja ziemlich Performenceziehend. Deshalb werden eben die Type-Einträge nicht gleich gelöscht, sonder nur in Abständen. Wonach sich diese Abstände richten, ob nach Zeit oder vielleicht nach "New" aufrufen, weiß dann wohl eher nur Mark ![]() Soviel zu meiner Theorie ![]() Edit: Also sollte man immer, bevor man das Programm beendet, den GC aufrufen? |
||
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 ![]() |
---|---|---|
Nein, das weiß nicht nur mark, hab gerade die formel dafür gefunden, die steht im C-Source von BRL.Blitz(blitz_gc.c):
BlitzBasic: [AUSKLAPPEN] Das wird in der funktion bbGCAlloc ausgeführt, also immer dann, wenn neuer Speicher angefordert wird. und collectMem(0) entspricht einem gcCollect. Also es scheint durchaus ein System dahinter zu stecken. |
||
Gehe zu Seite Zurück 1, 2, 3, 4, 5, 6 ... 11, 12, 13 Weiter
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group