PureBoard

Max_der_Held hat geschrieben:öh ist das besser...? *denk.* (hört sich kompliziert an..) ^^ ... aber.. du bist der Profi

Danke

Es währe ja keine Änderung, nur ne Erweiterung. Ich hab mir das ganze überlegt und bin zu dem Schluss gekommen, das ich keinen eigenen Registry-Server machen werde sondern viel eher diese Funktionen in den Slave integrieren werde. Also das sich die Slaves unterreinander vernetzen können. Hab schon ne Idee im Hinterkopf wie ich das einfach, unkompliziert und ohne Performanceverlust machen kann ...

Das ganze würde dann so funktionieren das man einfach ECluster_Slave_AddAssignment(Address$, Port) aufruft, und dann synchronisieren diese Slaves ihre Service Listen immer wenn ein neuer Service hinzugefügt wird. Und ECluster_Master_GetServiceInfos(...) wird wie gehabt verwendet nur das man alles Funktionen aller Verknüpften Slaves bekommt. Also, das Ergebniss eines solchen Aufrufs währe dann z.B.:

ECluster_Master_GetServiceInfos() hat geschrieben:192.168.0.1:589
Name: "Job_1" Description: "lalala"
Name: "Job_2" Description: "huhuhu"

192.168.1.243:2891
Name: "Job_1" Description: "lalala"
Name: "Job_3" Description: "oioioi"

Das hört sich gut an
Fast so wie ein Peer-2-Peer Netzwerk...

Update:

• ECluster_Master_CountSlaveJobs(): Ermittelt Anzahl ausstehender Jobs am Slave
• #ECluster_Slave_EventType(): #Event_Master_CountJobs: Master fragt Jobanzahl ab
• Sicherungs & Prüfungsroutinen verbessert
• Kleines Memoryleak in Slave & Master gefixt
• Download Lizenz beigelegt

Das mit dem Registry-Server/Slave lass ich doch erst mal sein da es 1. teilweise etwas auf die Performance schlagen würde und 2. Das Kosten/Nutzen Verhältniss nicht ganz stimmt. Außerdem werden solche Registry Server eigentlich in RPC-Varianten eingesetzt die anders konzepiert sind als ECluster. Wenns einer unbedingt haben mochte kann er ja fragen, dann werd ich sehen wie man das lösen könnte.

Derzeit überarbeite ich das Protokoll etwas um noch Performance zu gewinnen, und räume den Code etwas auf, damit ich nicht plötzlich den Überblick verliere.

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip

Update:

• ECluster_Slave_CountJobs(): Anzahl ausstehender Jobs ermitteln (kA wiso ich das vorher vergessen hab )
• ECluster_Slave_Pause(): Pausiert die abarbeitung der JobQueue
• ECluster_Slave_Resume(): Setzt die Abarbeitung der JobQueue fort
• ECluster_Master_Event_Type(): #Event_Slave_Paused, #Event_Slave_Resumed: Slave pausiert/setzt fort.
• Kleine interne Optimierungen
• Demos Sources erweitert

Die Befehle sind an sich selbsterklärend, detailierte Infos zu allen Befehlen wie immer in der ECluster_inc.pbi. Die Sources wurden um Pause/Resume/JobQueue - Count Zeugs erweitert, mal rumspielen, Slave starten, ein paar Master aufmachen, Slave pausieren, Jobs absenden, Slave resumen, ... . Ich konnte bisher noch keine Fehler/verirrte/verlorene Packete usw. feststellen alles läuft rund . Währe schön wenn ihr mal alles kreutz und quer testen könntet. Einfach wie wild auf alle Tasten drücken, 10.000 Master aufmachen ... (Einfach mal DAU spielen ).

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip

Update:

• ECluster_Master_Event_Type(): #Event_Master_BufferUnderrun : Master Buffer Unterlauf
• Datensicherungs Routinen verbessert
• Leere Übergabe-Parameter möglich (übergabe von 0 statt einem Parameter - Stack)
• Automatisches ReSend in den Slave integriert
• Interne Verbesserungen

Details:

Natürlich kann auch beim Master ein Buffer Underrun auftreten, so wie bei jedem Programm das mit Netzwerkbefehlen arbeitet. Die Daten die der Master brauch sind einfach noch nicht da, oder werden noch gesendet. Außerdem wurden Optimierungen an der Datensicherung vorgenommen. Ich hatte vergessen das ja sogar ein Long (für die Packet - Länge) aus 4 Bytes besteht und es nicht sicher ist ob der in einem Stück ankommt. Versuche ich nun den auszulesen gibts natürlich nen IMA. Auch hierfür gibt es jetzt ensprechend automatische Erkennungs & (wenn möglich) Korrekturmaßnahmen.

Eine weitere Optimierung ist das automatische ReSend des Slave. Kann der Slave ein Datenpacket nicht an den Master schicken weil der eben gerade ausgelastet usw. ist, kommt das Packet in eine Warteschlange und der Slave versucht in regelmäßigen Abständen immer wieder das Packet zu senden.

Würd mir ein bisschen umfangreichere PB - Netzwerkbefehle wünschen (ZB. ein Event wenn der Client wieder bereit ist um das ReSend besser zu triggern)

Sonst gibts nur ein paar kleine interne Perfomance - Optimierungen.

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip

Update:

• ECluster_Master_CountSlaveWorkers(): Ermittelt Anzahl Worker am Slave
• ECluster_Slave_Event_Type(): #Event_Master_CountWorkers: Master zählt Workers
• ECluster_Master_CountSlaves(): Ermittelt Anzahl verbundener Slaves
• ECluster_Master_IterateSlaves(): Iteriert alle verbundenen Slaves an ein CallBack.
• Interne Optimierungen

Viel Spaß damit.

Alex

Update:

• ECluster_Slave_CountMasters(): Online Master am Slave zählen
• ECluster_Slave_IterateMasters(): Online Master an ein Callback iterieren
• ECluster_Master_GetSlaveXtraData(): Extra-Daten eines Slave lesen
• ECluster_Master_SetSlaveXtraData(): Extra-Daten eines Slave setzen
• ECluster_Slave_GetMasterXtraData(): Exta-Daten eines Master lesen
• ECluster_Slave_SetMasterXtraData(): Extra-Daten eines Master setzen
• Kleinen Bugfix in der ECluster_Inc.pbi (Iterations CB & Aufruf nicht ganz korrekt deklariert)
• Cooles Logo erzeugt

IterateMaster & CountMasters sind das Äquivalent zu den masterseitigen Befehlen, nur logisch das die eingebaut wurden. Interessant sind die Xtra-Data Befehle. Durch sie kann jedem Master/Slave individuell Extra - Daten zugewiesen werde. Verwendet man dafür etwa Pointer auf Strukturen bracht man sonst überhaupt keine Client/Server usw. Verwaltung mehr zu machen sonder kann die interne Verwaltung von ECluster nutzen. In Verbindung mit den Iterate Befehlen werden so Anwendungen wie Chat/Gaming usw. Server sehr einfach.

Ich werd in den nächsten Tagen mal schauen das ich ein kleines Chat Demo auf ECluster - Basis zusammenbastle.

mensch, jetzt sogar mit Logo!

Andesdaf hat geschrieben:mensch, jetzt sogar mit Logo!

Jo, Marketing ist alles .

Update:

• ECluster_Slave_GetMasterIP(): IP-Addresse des Masters ermitteln
• ECluster_Master_GetSlaveIP(): IP-Addresse des Slave ermitteln
• ECluster_AllocateMemory(): Wie AllocateMemory()
• ECLuster_FreeMemory(): Wie FreeMemory()
• ECluster_ServiceProcedure(), ECluster_Master_SlaveCB(), ECluster_Slave_MasterCB(): Prototypes um Slave/Master-Handle und/oder Slave/Master Nummer erweitert.

So. Ich denke mal so ziemlich jeder wird sich über die ECluster - Memory Befehle wundern. Das ganze liegt daran: Ich hab das Demo um ein Beispiel zum versenden größerer Speicherblöcke (eben ein Logo am Anfang) erweitert. Nun übergibt man einen mit AllocateMemory() erzeugten Speicherblock an ECluster und der gibt ihn später mit FreeMemory() frei, und einen von ECluster übergebenen Speicherblock, der mit AllocateMemory() erstellt wurde könnte man doch ganz leicht mit FreeMemory() freigeben. FALSCH! IMA. Nach langer Suche in den Foren & MSDN hab ich folgendes festgestellt: Mann kann aus PB keinen Speicher aus der DLL freigeben, und die DLL kann keinen Speicher aus PB freigeben. Liegt daran das PB intern HeapAlloc() benutz und die Speicher unterschiedlichen Threads zugerordnet sind.

Kurzum: Speicher: ECluster -> PB: ECluster_FreeMemory(), PB -> ECluster: ECluster_AllocateMemory()

Die andere Lösung währe gewesen die automatische Speicherbereinigung wegzulassen, aber das würde zu enormen Memory-Leaks führen.


<center></center>

Die anderen neuen Befehle sollten selbsterklärend sein, ansonst Details in der ECluster_inc.pbi und in den DemoCodes.

Viel Spaß, damit bei Fragen usw. wie immer einfach hier posten.

Download im 1. Post oder:

http://www.paladiumx.forgesoft.net/publ ... r_Beta.zip



PS: center-Tags ftw!