EasyNetworkManager [Neu: Log - System][V# 1.3.3][Include]

[cxAlex]

Update V# 1.1.6

Der Fehler mit den Ping wurde gefixt. Ebenso funktioniert der Check auf die minimale PB Version (4.51) nun auch korrekt. Außerdem wurde eine Compiler-Weiche eingebaut die eine Fehlermeldung ausgibt wenn die PB 4.6 Beta x64 verwendet wird, da ENM unter dieser Version (noch) nicht korrekt funktioniert.

Download im 1. Post

Gruß, Alex

[jamirokwai]

Hi cxAlex,

hier mal ein paar Hinweise, um das Ganze auch "irgendwann" auf dem Mac voll laufen lassen zu können...

Ergänzen, jeweils mit Ersetzen, in
- zlib.pbi

Code: Alles auswählen

CompilerSelect #PB_Compiler_OS
    CompilerCase #PB_OS_Windows : #zlib_ImportPath$ = "zlib.lib"
    CompilerCase #PB_OS_Linux   :  #zlib_ImportPath$ = #PB_Compiler_Home + "purelibraries/linux/libraries/zlib.a"
    CompilerCase #PB_OS_MacOS   :  #zlib_ImportPath$ = "/usr/lib/libz.dylib"      
  CompilerEndSelect

- ENM_CommonIncludes.pbi

Code: Alles auswählen

CompilerIf #PB_Compiler_OS = #PB_OS_Linux Or #PB_Compiler_OS = #PB_OS_MacOS

- in den Beispiele überall IncludePath "../src/" schreiben, damit Linux und Mac den Ordner finden.

Das Target muss auch "Console" umgestellt werden, sonst schmiert der Server direkt beim Start ab.
Der Debugger sagt beim mirror-Beispiel sehr oft so was hier: "PureBasic3(1269,0xb050d000) malloc: *** error for object 0x4145e4: pointer being freed was not allocated"

Die Timer-Library läuft auf dem Mac gar nicht wegen der API-Funktionen, ebenso läuft das deskstream-Beispiel nicht, da bitblit oder so auf dem Mac nicht existiert.

Mit Debugger läuft die Stream-Demo, jedoch bricht das Beispiel bei genau 1 MB (1024*1024 Bytes) ab... Danach hängt das Client-Programm.

Das Mirror-Beispiel läuft übrigens mit der 4.61 Beta mit Debugger super durch. Wenn ich den Server als Consolen-App starte, schmiert er mit einem Segmentation Error ab.

Hm. Sieht so aus, als wären die Routinen noch nicht Mac-Like :-O

Gruß
Jörg

[cxAlex]

Hi cxAlex,

hier mal ein paar Hinweise, um das Ganze auch "irgendwann" auf dem Mac voll laufen lassen zu können...

Ergänzen, jeweils mit Ersetzen, in
- zlib.pbi

Code: Alles auswählen

CompilerSelect #PB_Compiler_OS
    CompilerCase #PB_OS_Windows : #zlib_ImportPath$ = "zlib.lib"
    CompilerCase #PB_OS_Linux   :  #zlib_ImportPath$ = #PB_Compiler_Home + "purelibraries/linux/libraries/zlib.a"
    CompilerCase #PB_OS_MacOS   :  #zlib_ImportPath$ = "/usr/lib/libz.dylib"      
  CompilerEndSelect

- ENM_CommonIncludes.pbi

Code: Alles auswählen

CompilerIf #PB_Compiler_OS = #PB_OS_Linux Or #PB_Compiler_OS = #PB_OS_MacOS

- in den Beispiele überall IncludePath "../src/" schreiben, damit Linux und Mac den Ordner finden.

Solle nicht das Problem sein, kann ich bis zur nächsten Version ändern

Das Target muss auch "Console" umgestellt werden, sonst schmiert der Server direkt beim Start ab.
Der Debugger sagt beim mirror-Beispiel sehr oft so was hier: "PureBasic3(1269,0xb050d000) malloc: *** error for object 0x4145e4: pointer being freed was not allocated"

Ok, das mit Console ist nicht das Problem. Das mit dem malloc-Error ist komisch. Ich finde hier keinen Fehler, auch mit eingeschalteten Purifier. Eventuell ein Bug in der PB - Thread lib oder Memory lib unter OS X?
In welcher Zeile tritt der Fehler den auf? Warscheinlich hilft eh nicht weiter da Threads den PB - Debugger echt verwirren, aber vielleicht haben wir ja Glück.

Die Timer-Library läuft auf dem Mac gar nicht wegen der API-Funktionen, ebenso läuft das deskstream-Beispiel nicht, da bitblit oder so auf dem Mac nicht existiert.

Ok, Kenn mich leider gar nicht mit der Mac-API aus, da kann ich jetzt nichts machen :P

Mit Debugger läuft die Stream-Demo, jedoch bricht das Beispiel bei genau 1 MB (1024*1024 Bytes) ab... Danach hängt das Client-Programm.

Das Mirror-Beispiel läuft übrigens mit der 4.61 Beta mit Debugger super durch. Wenn ich den Server als Consolen-App starte, schmiert er mit einem Segmentation Error ab.

Hm... komische Sache... Kann ich hier nicht reproduzieren, ohne Mac zum testen echt schwer.

Hm. Sieht so aus, als wären die Routinen noch nicht Mac-Like :-O

Gruß
Jörg

Ne, leider noch nicht ganz.

Gruß, Alex

[HeX0R]

SendNetworkData() gibt im Fehlerfall -1 und nicht 0 zurück.
D.h. deine Schleife könnte durchaus auch in eine Endlosschleife kommen.

Wenn man es richtig machen wollte, müsste man aber zur API greifen, weil man dann noch keine Ahnung hat, wieso ein Fehler kommt.
Es kann sich z.B. um einen Verbindungsabriss handeln, dann sollte man schleunigst aufhören, oder aber um eine #WSAEWOULDBLOCK Meldung,
die nur soviel bedeutet wie: Puffer der Gegenstelle voll, versuche es später weiter.
(Richtig wäre übrigens:
#WSAEWOULDBLOCK Meldung erhalten -> warte auf #FD_WRITE Meldung [die dir signalisiert, der Gegenseitenpuffer ist wieder empfangsbereit] -> Sende weiter.)

Ich hatte das mal im Feature-Request Forum angefragt, weil ich finde, man kann mit den hausinternen Befehlen keine robusten Netzwerktools herstellen.

Diese #WSAEWOULDBLOCK-Meldungen (und daher -1 als Rückgabewert) bekommst du übrigens zuhauf, wenn du versuchst in einem lumpigen LAN richtig große Dateien hin- und herzusenden.

[cxAlex]

SendNetworkData() gibt im Fehlerfall -1 und nicht 0 zurück.
D.h. deine Schleife könnte durchaus auch in eine Endlosschleife kommen.

Nope, da das SafeNetwork - Include das auf Null überschreibt.

Ein Verbindungsabriss wird auch ganz gut im SafeNetwork detektiert, unter Benutzung von API Befehlen für Windows, Linux und Mac. Und zum resend/reload automatisch im Hintergrund hab ich auch ganz gute Routinen, hab schon gemerkt dass das PB nativ nicht so ganz klappt ;D

Gruß, Alex.

[HeX0R]

Ah, o.k., dann nehme ich alles zurück und behaupte das Gegenteil

[cxAlex]

Update 1.1.7.

Das mit dem Ping und Stream sollte nun allgemein besser funktionieren, unter Windows und Non-Windows. Außerdem wurde ein Settings-Checker eingebaut der schlichtweg sinnlose Konfigurationen erkennen soll.

Download im 1. Post

Gruß, Alex

[cxAlex]

Update V# 1.2.0

Großes Update! Neben div. interner Optimierungen gibt es eine große Neuerung: Den Protocol - Manager

Was benötigt man bei (fast) jeder Client-Server Anwendung neben den allgemeinen Sende/Versand usw. Routinen? Ein Protokoll.
Das Entwickeln eines guten Protokolls ist essentiell für jede Netzwerk-Anwendung. Es sollte nicht zu viel Overhead erzeugen, nach Möglichkeit Auf/Abwärtskompatibel, ... . Und Fehler im Protokoll können unter anderem zu verdammt langen Debug-Zeiten führen

Das kann nun die Integrierte Protokoll-Verwaltung für euch übernehmen. Sie besteht aus 3 Teilen:

• Protocol-Builder
• Protocol-Blueprint
• Protocol-Transceiver

Der Builder:
Der Builder erstellt euch die Struktur eures Protokolls. Jedes Protokoll hat einen Namen, eine Version und beliebige Anzahl von Einträgen vom Typ Byte,Long,Quad,Float,Double,String oder Memory. Jedem Typ kann ein Default-Wert zugewiesen werden.

Daraus erstellt der Builder einen Blueprint. Ein kleiner Beispielcode für ein Protokoll:

Code: Alles auswählen

; Protokol erstellen
MyBuilder.ENM_Protocol_Builder = ENM\OpenProtocolBuilder("MyProto", 12)

; Einträge hinzufügen
MyBuilder\AddEntry_Byte("Flag")
MyBuilder\AddEntry_String("User", "Local")
MyBuilder\AddEntry_String("Password")
MyBuilder\AddEntry_Long("Para_1")
MyBuilder\AddEntry_Double("Para_2", #PI)
MyBuilder\AddEntry_Byte("Para_3", 1)

; exportieren
MyProto$ = MyBuilder\ExportBlueprint()

Daraus mach ensteht folgender Blueprint:

Code: Alles auswählen

PN: MyProto
PV: 1
flag I: 0 T: BYTE D: 0
user I: 1 T: STRING D: Local
password I: 2 T: STRING D: 
para_1 I: 3 T: LONG D: 0
para_2 I: 4 T: DOUBLE D: 3.1415926536

Könnte man im Prinzip auch selbst schreiben, der Builder ist in erster Linie für Developer-Tools gedacht um bequem eigene Protokolle "zusammenzuklicken". Wenn ich Zeit finde werde ich selbst so ein kleines Tool schreiben.

Das nächste Element ist der Blueprint. Dieser Parst den oben entstandenen Text und erzeugt eine Art Token, der Anweisungen enthält wie ein Protokoll auszuwerten ist.

Code: Alles auswählen

MyBlueprint.ENM_Protocol_Blueprint = ENM\OpenProtocolBlueprint(MyProto$)

Der Blueprint wird am Besten einmal pro Protokol Global erstellt und am Ende des Programms freigegeben. Er wird zum erstellen der Transceiver benötigt. Das erspart das der Blueprint jedesmal beim erstellen eines Transceivers geparst werden muss.

Und nun der wichtigste Teil, der Transceiver:

Die Transceiver ist Transmitter und Receiver zugleich. Der Transceiver setzt die Werte für die Einträges eines Protokolls, und exportiert diese in einen kompakten Memory-Block der über die Paket-Funktionen von ENM gesendet werden kann.

Auf der anderen Seite wandelt der Transceiver den Speicher aus den Paketen wieder zurück.

Code: Alles auswählen

; Transceiver aus Blueprint erstellen
MyTransceiver.ENM_Protocol_Transceiver = ENM\OpenProtocolTransceiver(MyBlueprint)

; Felder setzen
MyTransceiver\T_SetByte("Flag", 12)
MyTransceiver\T_SetString("Password", "geheim")
; Paket erstellen
*Mem = MyTransceiver\T_Export(@MemSize.i)

; Memory via Paket senden....
; .......
; .......
; Paket empfangen

; Rückwandeln
MyTransceiver\R_Import(*Mem, MemSize)

Debug MyTransceiver\R_GetByte("flag")
Debug MyTransceiver\R_GetString("user")
Debug MyTransceiver\R_GetString("password")
Debug MyTransceiver\R_GetDouble("para_2")

Das ganze ist extrem dynamisch. Ein Server könnte Protokoll - Aktualisierungen an Clients übertragen, und diese könnten auf das neue Protokoll Umschalten ohne sich neustarten zu müssen, genauso umgekehrt!

Das übertragene Protokoll an sich ist binär, so fällt nicht viel Overhead an.

Das ganze ist noch etwas experimentell und es können noch Fehler auftreten, es ist verdammt viel frischer Code. Auch ist das ganze noch nicht vollständig dokumentiert. Über gefundene Bugs, Feature-Requests, konstruktive Kritik usw. freu ich mich immer

Download im 1. Post

Gruß, Alex

[PMV]

Das klingt ja schon mal ziemlich gut. Zeit zum ausprobieren hab
ich zwar nicht, aber sollte ich doch mal Server-Client Anwendungen
brauchen, ist der Manager hier die erste wahl (obwohl mein JSON-
Parser nun nicht dabei ist ). Hier noch ein Anreitz für deinen
ProtocolManager:

So wie ich das verstanden hab, müssen die einzelnen übertragenen
Daten immer mit MyTransceiver\R_GetXXX("name") ausgelesen
werden. Viel cooler wärs, wenn das Ergebnis nicht erst durch einzelne
Methoden abgerufen wird, sondern mit *MyData.MyData =
MyTransceiver\R_Import(*Mem, MemSize) das Datenpacket direkt
ein eine Struktur geschoben wird.

Klar, so ist das Programm auf ein bestimmtes Protokoll angewiesen,
aber mal ganz erlich, wann arbeitet ein Client schon mit undefinierten
Daten? Es ist in fast jedem Fall so, dass der Client wissen muss, was
er für Daten bekommt, damit er damit umgehen kann. Wenn das
Protokoll geändert werden muss, dann in 99% der Fälle auch das
Handling im Client, weil er nun anders damit umgehen soll. Sonst
hat das Ändern auch selten sinn. Cool ist es aber trotzdem, denn
solche Protokollanpassungen können einen wirklich nerven ... zusätzlich
zum umstellen der eigentlichen Logik.



MFG PMV

[cxAlex]

Code: Alles auswählen

 *MyData.MyData = MyTransceiver\R_Import(*Mem, MemSize)

Stimmt, über sowas hab ich auch am Anfang nachgedacht. Dabei ist dann halt die Sache wieder das ich mich die Structure dann wieder fix programmieren muss, und dann ist eben der ganze Ansatz mit dem dynamischen Protokoll bei der Katz :P. Mal sehen ob ich das vlt. parallel einbaue wenn ich Zeit übrig habe

Ich hab mir ja beim Design des ganzen auch überlegt wie ich das ganze später ausbauen kann, deshalb auch dieser jetzt auf den 1. Blick vielleicht etwas "überdimensionierter" Aufbau. Ich will später noch ein paar optionale Spielereien einbauen, wie z.B. das nur die Felder übertragen werden die ich brauche, bzw. auch wirklich gesetzt habe. So könnte man z.B. ein größeres Protokoll designen mit vielen Einträgen und beispielsweise einen Flag - Element und ich setzte immer nur das Flag-Element und eben die Felder die für diese Anfrage/Übertragung/... gebraucht werden, und es werden dann auch wirklich nur diese Felder übertragen und alle anderen Felder nehmen beim Receiver den Default-Wert an. So spart man bei vielen Paketen dann doch einiges an Traffic ein.

Oder man geht den anderen Weg und designed ein paar kleine Protokolle für die verschiedenen Anfragen und mit einem kleinen Universal-Protokoll in dem beispielsweise nur der Protokoll-Name des Protokolls steht mit dem sich der Client mit dem Server unterhalten will. Alles kein Problem mit dem Manager.

Ist halt eine schwierige Sache, einerseits will ich die ganze Verwaltung/Übertragung/Protokoll-Entwicklung so einfach wie möglich machen, andererseits dem Programmierer so wenige Vorgaben/Einschränkungen wie möglich. Nicht gerade ein kleiner Spagat den es da zu meistern gilt

Gruß, Alex