Beiträge von ilou

    Ich bin jetzt kein Jurist, aber gibt es nicht die Möglichkeit sowas juristisch zu verfolgen. Insbesondere dann, wenn die Polizei ja schon ohne Grund zu dir geschickt wird, nehmen die doch sicherlich schon die Ermittlungen auf.


    Soweit ich weiß, machst du dich mit Angabe falscher Daten im Impressum strafbar - und das wird teurer als ne Pizza:

    Zitat

    Bis zu 50.000€ Bußgeld bei Verstößen gegen die Impressumspflicht sowie Abmahnrisiko.


    In einem weiteren Artikel hab ich auch gelesen, das auch Anklagen wegen unlauteren Wettbewerbs möglich sind. Da sind die Strafen noch höher (teils mit Haftstrafen). Das wird zwar wahrscheinlich nicht bei nem Server in MC passieren, ich persönlich würde das Risiko aber auch nicht eingehen wollen.

    Hallo,


    insbesondere in letzter Zeit sehe ich immer wieder Themen, insb. Suche-Themen, die weder alle nötigen Informationen enthalten, noch ansprechend gestaltet sind. Insbesondere leidet die Rechtschreibung sehr oft und tritt bei jedem Beitrag immer die gleiche Diskussion los, dass der Beitrag nochmal überarbeitet werden soll und auch von anderen gegengelesen werden soll und so weiter und sofort.


    Um solche immer wiederkehrenden Diskussionen zu vermeiden, wurde damals ein sehr guter Leitfaden geschrieben:

    Ghostium


    Bisher galt dieser Leitfaden als optional.


    Ich würde mir allerdings wünschen, dass dieser Leitfaden im Groben zur Pflicht werden sollte, bevor ein Beitrag freigeschaltet wird. Direkt dazu sollten Beiträge, deren (schlechte) Rechtschreibung die Unleserlichkeit des Beitrags fördert, ebenfalls von vorne rein nicht freigeschaltet werden. Das sollte aber schon aus derzeit gütligen Forenregeln §3, Abs. 1 hervorgehen.


    Gruß

    Marc

    Bei ernsthaftem Interesse geben wir den Namen des Servers per E-Mail bekannt, damit du ihn erstmal anschauen kannst.

    Ich sehe hier eine Art Paradoxon: Ich habe erstmal kein Interesse an einem Server, den ich mir nicht vorher in Ruhe ansehen kann. Gleichzeitig wollt ihr aber, dass man Interesse hat, damit man die Daten vom Server erhält.


    Wäre es vielleicht möglich, die Webseite von eurem Server zu verlinken oder andere Daten anzugeben, sodass man sich ein Bild vom Server machen kann?

    Ich sehe aber nicht, warum das nicht funktioneren sollte.

    Also mein "unmachbar" war vielleicht nicht ganz richtig, das stimmt. Aber das Alternating Bit Protocol wird ja im ersten Sinne dazu genutzt, bei der Kommunikation zwischen zwei einzelnen Kommunikationspartner Datenverlust zu erkennen, indem Nutzer A mit z.B. Bit-Wert 0 ein Paket schickt und erst das Paket mit Bit-Wert 1 verschickt, sobald Paket 0 von Nutzer B geacked wurde.


    Ich selber weiß auch jetzt noch nicht, wie man mit nur 1 Bit (im Zweifel) endlos viele Clients ohne Master synchronisieren möchte, sodass die ihre Schreiboperationen nicht überschreiben. Wie du sagtest, könnte man es sicher mit n Bits machen, aber das wird auch schwierig, je größer das Cluster wird. Daher auch der Vorschlag von CSMA/CA, worin ich eine bessere Lösung für das Problem sehe.


    Eine Alternative wäre noch, solche Operationen über einen Master im Cluster zu kontrollieren. Dort gibt es auch Ansätze, die nicht mal zwingend einen eigenständigen Master benötigen, da reicht es, wenn ein Client den Master übernimmt und fällt dieser aus, übernimmt ein anderer Client im System den Master. Da könntest du dann die Anfragen zum Schreiben über den Master organisieren, den Clients die Erlaubnis erteilen und die kümmern sich dann um den Broadcast.


    Du könntest dir auch noch Konsens-Algorithmen anschauen. Ein Beispiel dafür wäre der Raft Consensus Algorithm: https://raft.github.io/

    Bei einem einzelnen Bit kommt mir das ganze fast so vor, als versuche man an der Stelle eine Art Alternating Bit Protocol zu verwenden, um den Datenaustausch zu regeln. Das ist für die direkte Kommunikation zwischen 2 Clients vielleicht praktisch, bei 3 aufwendig und ab 4 würde ich fast sagen unmachbar.


    Ich würde an der Stelle vielleicht versuchen eine Art von Collision Detection bzw Collision Avoidance zu verwenden. Eine solche Collision Detection wird häufig im Netzwerk-Bereich verwendet (CSMA/CD) und speziell bei drahtlosen Netzwerken kommt die Technik von Collision Avoidance (CSMA/CA) zum Einsatz.

    Bei CSMA/CD, bzw. CSMA/CA besteht eine Übertragung zwischen mehreren Clients, die das gleiche Medium zur Übertragung verwenden, aus mehreren Schritten, die den kollisionsfreien Zugriff auf das Medium sicherstellen sollen.

    Du kannst zur genauen Funktionsweise gerne selber ein wenig recherchieren. Ich hätte so auf Anhieb hier einmal den Link zum entsprechenden Wikipedia-Eintrag. Meine Vorlesungsfolien darf ich wegen Urheberrecht leider nicht einfach hier reinstellen, auch wenn die das etwas kleinschrittiger erklären: https://de.wikipedia.org/wiki/…ccess/Collision_Detection bzw. https://de.wikipedia.org/wiki/…ccess/Collision_Avoidance


    Du kannst es dir ja mal anschauen. Vielleicht hat Aquaatic aber auch was anderes gemeint. Dann siehe meinen Beitrag nicht als Ergänzung, sondern als weiteren Vorschlag :)

    Nur als Hinweis, weil es mir im Beitrag von DerSchlawiner fehlt: Egal ob ein kleines oder großes Projekt: Man sollte Passwörter natürlich nicht in Klartext speichern, sondern immer hashen. Und da kann man auch gerne starke Hashing-Verfahren wie Argon2(id)* oder bcrypt verwenden. Man sollte nur von Hashing-Verfahren wie MD5 oder SHA-1 oder Ähnlichen die Finger lassen.


    * Die Nutzung von Argon2 bietet zwar State-of-the-Art-Hashing, ist aber nicht ohne weiteres auf jedem Webserver verfügbar. bcrypt ist mWn immer verwendbar, da es standardmäßig in PHP mitgeliefert wird.

    Ich habe auch mit Nodejs keine Erfahrung. Wie einfach ist denn das zu lernen,

    Da es für mich so klingt als hast du Erfahrung in der Webentwicklung ist es praktisch, wenn du JavaScript schon kannst. Der Rest ist eigentlich gleich, nur andere Libraries halt. Die Umstellung sollte dir dann eigentlich leicht fallen.


    wie einfach ist das in eine Java CLI einzubringen?

    Das weiß ich nicht. Das habe ich noch nicht gemacht, bzw. werde ich auch wahrscheinlich nie machen.

    So findet ihr das ihr besser (Ist Jetzt mit einer ArrayList)


    Kannst du mal selber erklären, Schritt für Schritt, was du vor hast?


    Aktuell machst du etwas ganz komisches.


    Und wer hat dir beigebracht, abzufragen, ob ein "Wert eine Eigenschaft" besitzt anstatt eine "Eigenschaft einen Wert".

    Normalerweise strukturiert man Abfragen mit player.getLevel() > 100 und nicht 100 < player.getLevel()

    Um da direkt anzuknüpfen:

    Hey Benne,


    danke für deine Anregung, ich habe nochmal über entsprechendes drübergeschaut.

    So ganz gefunden hast du nicht alles, wodurch der Lesefluss noch immer ein wenig gestört wird, aber immerhin ist diese Suche mal ausführlicher, als eigentlich jede andere, die man hier finden kann.


    Für mich ist euer Projekt leider nichts, aber ich wünsche euch viel Erfolg bei der Suche.

    Aber theoretisch gesehen sind ja nicht alle Statements/Queries anfällig für SQL Injections. Genauer gesagt sind es ja nur die, die direkte Inputs von Spielern annehmen.

    Das stimmt. Ich verwende zumindest in der Webentwicklung trotzdem immer Prepared Statements. Vielleicht auch, um solche Anfragen immer einheitlich zu haben, also den Code zum Anfragen. Ich werde durch das WSC aber auch dazu gezwungen, da deren Database-API nur noch Prepared Statements unterstützt.


    Aber wie oben erwähnt, nehmen sich Prepared Statements und normale Statements bei einmaliger Ausführung scheinbar nichts.


    Bei dem Rest kann ich dir nicht helfen, habe noch nicht mit Datenbanken in Java gearbeitet.

    Sollte ich für einmalige SQL-Tasks auch PreparedStatements nutzen oder ist es besser die normalen Statements zu nutzen?

    Wie sieht es von der Performance bei einmaliger Verwendung aus? Gibt es eine grundlegende Faustregel, wann was genutzt werden sollte?

    Genau kann ich dir diese Frage nicht beantworten. Für meinen Teil würde ich aber immer Prepared Statements in Betracht ziehen, allein schon aus dem Grund, wie du selber sagtest, um SQL Injections zu vermeiden.


    Soweit ich das gerade richtig interpretiere, werden "normale" Statements ebenfalls compiled, so wie PreparedStatements, nur mit dem Unterschied, dass Prepared Statements gecached werden, so also eine schnellere Ausführung bei weiteren Aufrufen dieser erfolgen kann. Performance-technisch dürften sich Prepared Statements meines Erachtens nach also nicht großartig viel gegenüber "normalen" Statements geben, zumindest bei einmaliger Ausführung :)

    Falls du Maven nutzt, versuch mal den Cache zu leeren und IntelliJ neu zu starten. Falls du kein Maven verwendest, kannst du es trotzdem mal versuchen.

    Ich frage mal nicht, warum du weißt, dass eine deiner Command-Klassen nicht funktionieren, wenn die Main schon nicht auffindbar ist.


    Wer gibt dir denn den Fehler? Der Server? Stimmen deine Imports?