Beiträge von Señor Zynko

  • [OFFER]Metin2 CMS API for Developers

    Moin,


    auf Wunsch eines Kumpels habe ich für seinen Metin2 Server ein neue Version eines Metin2 CMS geschrieben. I

    Nun möchte ich dies Entwicklern anbieten die eventuell einen eigenen Webseiten Service eröffnen wollen.

    Dabei könnt ihr mein Backend verwenden sodass ich nur noch das Frontend machen müsst. Ich bekomme 80€ pro Website die ihr mit meinem Backend verkauft ab.

    Ihr bekommt das CMS vorab auf Vertrauensbasis. Es handelt sich um ein REST Api. Ihr könnt also euer Frontend mit einem Frontendframework wie React, Vue, Angular, Svelte oder ähnliches umsetzen oder auch klassisch mit HTML, CSS und vanilla js. Das Angebot richtet sich nur an Entwickler die ihr eigen Frontend coden entwickeln wollen.


    Funktionen:

    • Register & Login
    • 2Faktor Authentication mit TOTP (Kann man aktivieren oder deaktivieren) ihr müsst es selber ingame implementieren
    • Email & Password Change
    • Char create
    • Debug account
    • Payment AMZ & PSC & PP (Nicht automatisiert)
    • News in mehren Sprachen
    • Slider in mehren Sprachen
    • Support Ticket System
    • Server Status
    • Server Statistik
    • Ranking
    • Player Detail via Ranking
    • Vote 4 coins
    • Recaptcha v3 for Spam Protection


    Settings:

    • Enable zwei Faktor Auth
    • Enable new password hash sha256 (Müsst ihr ingame selber implementieren)
    • Encrypt user data with AES ( email & ip are encrypted only you can decrypt them)
    • Require email verification
    • Enable payments with amz, psc & pp
    • Show/Hide API Dokumentation


    Technologie:

    • Go 1.6
    • REST API
    • Redis cache

    Kind regards

    Zynko

  • Interesse an einem "Pentest" Service?

    Lass es lieber sein Aufwand und Verdienst steht einfach nicht im Verhältnis. Seminare bringen nichts wenn die Leute keine Ahnung haben. Wer selber keine exploits erkennt oder seine Devs das nicht erkennen sollte einfach keinen Server machen gibt eh schon genug Müll online.

  • Source nach Backdoors suchen + FIX!

    Du suchst einen Pentester für deine ganze Source ? Dir ist bewusst das du dafür ein ganzes Team brauchst und Wochen Arbeit ?

    BTW der Standard Stundenlohn für so eine Arbeit liegt bei 30-40€ die Stunde


    Oder suchst du nur offensichtlich Issues ?

  • Einführung in die Programmierung

    Moin,


    Nur noch max 1 Plätze frei!


    da ich zur Zeit einigen Schülern neben bei das Programmieren beibringen möchte ich dies auch nun hier anbieten. Der Kurs richtet sich an diejenigen die den ersten Schritt in die Entwicklung wagen wollen. Der Kurs richtet sich nach Themengebiet und Niveau.


    Ein Kurs besteht aus bis zu max. 10 Teilnehmern und entspricht immer dem gleichen Aufbau:

    1. Auswahl der Programmiersprache ( allgemein wird Wissen Programmiersprachen unabhängig vermittelt)

    2. Einführung in die Sprache

    3. OOP/ FP and Datastructures

    4. Fehlerbehebung und Analyse

    5. Networking

    6. Git ( Versionierung)


    Eine Einheit umfasst ca 90-120min mit ca 5 -7 Unterrichtseinheit. Am Ende des Kurses werdet ihr ein kleines Spiel oder Networking Implementiert haben.


    Themengebiete:

    - Softwareentwicklung

    - Appentwicklung

    - Webentwicklung

    - Cloud GCP & AWS


    Programmiersprachen:

    - Java

    - C#

    - Node.js / Typescript

    - Golang

    - Dart

    - Python

    - C & C++ ( Basics )


    Der Preis pro Einheit kommt auf die Teilenehmeranzahl an, ca 10-20€.

    Am Ende solltet ihr in de Lage sein eigenständigen Probleme lösen zu können und die ersten eigenen Programme zu entwickeln. Sowie ein Grundverständnis für die Programmierung haben außerdem zeige ich euch wie ihr schnell neue Sprachen lernt.


    Zu mir ich bin seit 4 Jahren als Fullstackentwickler tätig im Cloud Bereich und berate große Deutsche Unternehmen bei Systemdesign sowie Umsetzung.


    Bei Interesse gerne eine PN.

  • Over-engineering Metin2

    Zitat von Ente

    Klingt auf jeden Fall interessant.

    Mich wuerde noch interessieren, wie weit ihr gekommen seid. ^^

    Zitat von Señor Zynko

    Bugs mehr als Deadline 2 - wir haben nicht alles gefixt, da es nur ein Experiment war

    Kannst du den Stand beschreiben, den ihr erreichen konntet? Oder beschreiben was ihr nicht erreichen konntet?

    Sorry für die späte Antwort ich versuche so gut wie möglich den Stand zu umschreiben. Es gibt bestimmt noch viele Bugs die wir noch gefunden haben. Bevor wir die Files überhaupt annähernd zu laufen bringen konnten hatten wir ca. 87 Bugtickets.


    Viele dieser Bugs hatten mit Fehler im neuen Networking und in dem Costume Auth zu tun und entstanden eher im Prozess der Entwicklung. Beispielsweise Update des MySQL Conectors etc.


    Bugs die immer noch bestehen sind:

    - Gildenchat funktioniert nicht

    - Länderflags mussten im Chat mussten deaktiviert werden

    - manchmal sind die Auth Server out of Sync was in eigenen Fällen dazu führt das man mit einem Account 2x gleichzeitig einloggen kann und dass crasht den Gameserver.

    - Error Messagees vom System crashen ab und zu den Client


    Es war möglich drauf zu spielen und wir hatten mehrere Stunden keine Probleme. Man könnte die Files weiter optimieren und in immer mehr Services aufteilen. Sowie die restlichen Bugs lösen.


    Als Basis dienten Fliege V2 Files die absolut nicht mehr mit dem Original zu tun haben.


    Aus den learnings, arbeite ich gerade an einem Code für ein Gameserverbackend für ein eigenes Spiel

  • Over-engineering Metin2

    Erstmal Danke für dein Lob. Wie gesagt der Lob sollte zu den anderen beiden Entwicklern gehen die sind absolute C++ Monster.

    Ich habe als Cloud Engineer natürlich mittlerweile genug Erfahrung um solche Solutions zu designen und Leute dementsprechend zu kordieren.

    Nur beim C++ bin ich nicht annähernd so gut im Vergleich zu anderen Devs.


    Zu dem Thema wieso Chat auslagern? Ganz einfach es sind extreme viele Requests die dort drüber laufen. Wir reducen die Traffic

    auf die Game Instanz an sich. Vor allem löst dies auch das Problem, dass man Leute auf anderen Cores keine Messages senden kann.

    Egal wo du dich befindest ihr könnt kommunizieren. Das Ziel war es eben die Code Base pro Service zu verkleinern um besser entwickeln zu können und den Traffic auf die Game Instanz zu reduzieren. Übrigens ist das gängig für Cloud basierte Games.

  • Over-engineering Metin2

    Moin Community,


    dieses Thema sollte nicht zu ernst genommen werden und diente eher als eine Art Experiment um die Möglichkeiten

    einer MMORPG Serverarchitektur zu testen. Die gesammelten Erfahrungen würde ich bis zu einem gewissen Grad teilen

    und eventuell kann der eine oder andere auch weitere Ideen reinbringen. Vorab möchte ich sagen jeder der diesen kleine Bericht

    liest und mich anschreibt und fragt ob er die Serverfiles für dieses Projekt haben kann, es gleich lassen kann. Mir gehören die Fiels nicht

    und habe selbst nur ca. 5% des Codes beigetragen. Ich habe hauptsächlich die Infrastruktur aufgesetzt und verwaltet, sowie

    die Architektur designed.


    Worum geht es denn nun eigentlich ?

    Wie die meisten wissen handelt es sich beim Metin2 Server um eine monolithische Anwendung

    "Monolithic applications are designed to handle multiple related tasks. They’re typically complex applications that encompass several tightly coupled functions.As you can imagine, given their broad scope, monolithic tools tend to have huge code bases. Making a small change in a single function can require compiling and testing the entire platform, which goes against the agile approach today’s developers favor."


    Heutzutage setzen wir im modernen Umfeld auf Service basierte Architekturen, dass heißt wir brechen große Applikationen in mehre, teilweise auch hunderte kleine Applikationen auf und lassen die miteinander kommunizieren. Dies hat viele Vorteile wie:

    • Einfach zu maintainender code, da die Services unabhängig voneinander funktionieren und ledgelich eine abstracke Schnitstelle bieten
    • Seperations of concerns: Ein service hat immer nur 1 Aufgabe/Domain die er behandelt.
    • Übersichtlicherer Code
    • No single point of failure
    • Schnellere compile times
    • Gezielte verticale/horizontale Skalierung
    • etc.

    Wir haben im Rahmen dieses Experiments die Serverarchitektur in 3 Services aufgeteilt (ja man kann diese noch weiter aufteilen, aber wird extrem complex)

    • Auth
    • Chat ( Beinhaltet nur den Worldchat sowie private Chat + offline messages)
    • World


    Was mussten wir vorher erledigen?

    • Update den komplleten Serverside & Clientside Code auf C++17/C++20
    • Update sämtlicher Libs
    • Update des MySQL Connectors
    • Anpassungen der SQL Query systems
    • Rewrite des kompletten Chat Systems
    • Rewrite des kompletten Auth Systems ( Implementierung einer Methode, sodass die anderen Systeme/Instancen vom Auth wussten)
    • Rewrite des Networkings


    Wie hosten wir so eine Architektur?

    Gute Frage wir hosten es natürlich in der Cloud. In welcher Cloud ? In unserem Fall haben wir das Experiment in der GCP (Google Cloud Platform) gehostet.

    Aber gleichermaßen hätten wir Aamazon Web Services, Microsoft Azure, oder IBM Cloud oder Digitalocean verwenden können. Ja uns ist es bewusst das diese

    aktiv gegen DCMA vorgehen aber mit einer TCP proxy vor dem ganzen System wird der Traffic nur den proxy geroutet und keiner weiß wo ihr eiegentlich hostet.


    Welche Services verwenden wir?

    • GKE Autopilot ( Manged Kubernetes Kluster im Autopilot modus)
    • Compute Engines (Fancy name für VPS)
    • Cloud SQL (Fancy version of MySQL in der Cloud mit sharding und edge locations)
    • Cloud Bigtable ( NoSQL Database für Playerlogs (werde ich nicht thematisieren))
    • Cloud Amor ( Firewall von Google (werde ich auch nicht thematisieren))
    • Cloud Loadbalancing


    Bitte melden Sie sich an, um dieses Bild zu sehen.


    Was ist Kubernetes?

    Kubernetes ist ein Container Orchestration System. Es erlaubt uns Services in Docker Containern zu definieren und diese automatisch zu skalieren.

    Jedder Container ist ein sogenannter POD. Diesem können mehr vCPUs oder Ram je nach Auslastung zugewiesen werden. Da aber nicht jeder Service

    mit mehr Ressourcen besser skaliert, können auch sogenannte Replicas eingesetzt werden. Das sind exakte kopien des Services und die user werden mittels

    des Cloud Load Balancers auf die Instanzen verteilt. In GKE können wir Scaling-Rules setzen z.B. je nach Network/vCPU/RAM Verbrauch. Beispielweise sagen wir

    user Auth POD hatte eine Rule für Replica-Saklierung bei 80% Auslastung von vCPU und RAM. Sollte dies erreicht werden instanziert das System automatisch eine weiteren Auth Server.

    In diesesm Beispiel erlauben wir es nur den Auth Service mehre PODs zu instanzieren. Chat und Game Server bekommen je nach Auslastung mehr Hardware Ressourcen zugewiesen.

    Außerdem prüft Kubernetes ob die PODs noch alive sind, sollte einer nicht mehr funktionieren, wird dieser zerstört und ein neuer aufgesetzt.


    Was bringt uns das jetzt?
    Ganz einfach kosten sparen und je nach auslatung nachskalieren und unnötigerweise selber einen neuen Server aufzusetzen.

    Wenn Beispielsweise nur 100 Spieler online sind skalieren die PODs runter z.B. downscaled der Server von 4vCPU und 8 GB Ram runter auf 2vCPU und 4 GB ram. Je nach Auslastung.

    Wir nutzen nur die Ressourcen die wir wirklich brauchen. Dies spaar uns Kosten, da das Billing teilweise pro Sekunde/Stunde funktioniert.




    Was haben wir beobachtet im Rahmen des Experiments:

    • Reduction in Packetanzahl/Packetcomplexity um ca. 10-20% auf dem Gameserver
    • Du bekommst den Server nicht down, beim besten willen nicht. Es sei du hast Fehler im Code.
    • Bugs mehr als Deadline 2 - wir haben nicht alles gefixt, da es nur ein Experiment war
    • Metin2 in die Cloud zu ziehen ist lustig aber absolut Sinnlos, solange man keine License hat
    • Teuer für normale Hosting Verhältnisse wie OVH, HETZNER etc.
    • Viel Zeit & Erfahrene Entwickler braucht es
    • Einer musste Cloud Kentnisse haben und basic DevOps Knowledge besitzen
    • Lasst es einfach sein wir haben eigentlich nur Zeit verschwendet.



    Nun die Kosten:

    • Cloud SQL : Pro vCPU 36,1$ , Pro GB RAM 6,13$, PRO GB SSD Speicher 0,17$ (Alles pro Monat)
    • GKE Autopilot: Pro vCPU 32,4850$ , Pro GB Ram 3,5934245$, Pro GB SDD Speicher 0,04$ pro Monat, GKE 0,10$/STD Mangement Gebühr
    • etc.

    Am ende hätte man bei Livebetrieb eine Rechnung pro Monat im Bereich von 500-1500€ je nach Spieler Anzahl. Achtung vor Kostdesasters!

    Es gibt keine Billing Limit, da ihr Kreditkarte oder Konto hinterlegen müsst. Ihr könnt den maximalen Verbrauch über Billing Rules setzen.



    Fazit:

    Wie ich schon mehrfach angeteasert habe war der Zeitaufwand viel zu hoch und auch die Hostingkosten rentieren sich nur für die größten Server.

    Ihr solltet also nie mit dem Gedanken spielen Metin2 Cloud ready zu gestallten. Aber für diejenigen die eventuell davon träumen irgendwann

    ihr eigenes Spiel zu entwickeln kann ich die Cloud nur empfhelen. Am Ende dieses Projektes ist ein halbfertiges Produkt entsanden welches

    mehr Bugs und Probleme besitzt, als es uns Lieb ist.


    Ich danke euch dass ich eure Zeit verschwenden konnte.

  • Erworbene Systeme als Dev bei anderen Servern einbauen?

    Ich würde eher die 3K im Monat nehmen als mich mit den Holbirnen von Käufern rumzuschlagen und die alle zu supporten.

    Finde 3K okay solange es keine Vollzeitstelle ist. Aber das ist eventuell für jeden sehr subjektiv.



    Zitat von Lead0b110010100
    Zitat von Señor Zynko

    Stimme ich dir absolut zu. Aber generell haben für mich Systeme die andere besitzen keinen bis nur minimalen Wert.

    Da es das Alleinstellungsmerkmal verloren hat und dies ist für mich der Hauptgrund neue Systeme auf einem Server zur Verfügung zu stellen.

    Deswegen haben ja auch die großen Server ihre eigenen Devs die nur für den Server arbeiten.

    Aber glaubst du das sowas wie ein Offlineshop oder das Target Information System oder eine Rangliste wie ein Mountsystem noch ein alleinstellungsmerkmal darstellen?

    Sowas zu verkaufen würde doch absolut Sinn machen. Es gibt genug Käufer (jeder neue Server ist quasi ein neuer Käufer für dich) und damit auch genug Anfrage.

    Kommt stark auf die Implementation an, nicht jedes Offlineshopsystem oder Mountsystem ist gleich.

    Wie gesagt dass ist meine sehr Subjektive Meinung, Mir wäre es nicht wert den Stress mit Kunden anzutun, die dann am besten noch meine Sachen resellen und sich daran weiter bereichern.


    Aber wir sollten zurück zum Thema.

  • Erworbene Systeme als Dev bei anderen Servern einbauen?

    Zitat von Lead0b110010100
    Zitat von Señor Zynko

    Wenn beim Verkauf nichts festgelegt wird, kann der Käufer meiner Meinung nach das System so oft auf anderen Server nutzen indem er aktiv Teil des Teams ist . Sollten jedoch eine Reglung wie Lizenz pro Server verhandelt worden sein. Wäre eine Nutzung des Systems auf einem anderen Server nicht rechtens. Wer Teil eines Teams wird nur mit der Intention ein System weiterzugeben betreibt reselling.


    Aber ganz ehrlich all diese Gründe tragen dazu bei ,wieso ich nie verstehen werde, wieso DEVs überhaupt noch Systeme anbieten.

    Anstatt sich bei den großen Server anständig bezahlen zu lassen und nur für dieses zu arbeiten.

    Wenn du heutzutage Systeme anbietest mit >= 150€ Preis, solltest du sowieso auf ein Lizenzsystem setzen welches das Reselling erschwert (wenn auch nicht verhindert).

    Stimme ich dir absolut zu. Aber generell haben für mich Systeme die andere besitzen keinen bis nur minimalen Wert.

    Da es das Alleinstellungsmerkmal verloren hat und dies ist für mich der Hauptgrund neue Systeme auf einem Server zur Verfügung zu stellen.

    Deswegen haben ja auch die großen Server ihre eigenen Devs die nur für den Server arbeiten.

  • Erworbene Systeme als Dev bei anderen Servern einbauen?

    Wenn beim Verkauf nichts festgelegt wird, kann der Käufer meiner Meinung nach das System so oft auf anderen Server nutzen indem er aktiv Teil des Teams ist . Sollten jedoch eine Reglung wie Lizenz pro Server verhandelt worden sein. Wäre eine Nutzung des Systems auf einem anderen Server nicht rechtens. Wer Teil eines Teams wird nur mit der Intention ein System weiterzugeben betreibt reselling.


    Aber ganz ehrlich all diese Gründe tragen dazu bei ,wieso ich nie verstehen werde, wieso DEVs überhaupt noch Systeme anbieten.

    Anstatt sich bei den großen Server anständig bezahlen zu lassen und nur für diesen zu arbeiten.

  • Suche eine GIT Schulung

    Bitte melden Sie sich an, um diesen Link zu sehen.

    ist häufig Standard macht aber nur Sinn für highly commercial projects.


    Sonst hat da jeder seinen eigenen Workflow.


    Kann dir es theoretisch gerne zeigen.