BUG nachgewiesen -close ports-

Du glaubst einen Bug / Fehler gefunden zu haben?
Melde ihn hier...

BUG nachgewiesen -close ports-

Beitragvon BNE » 23. Jan 2020, 00:23

BNE hat geschrieben:
ATZENPOWER hat geschrieben:so... habe mir mal erlaubt die Angriffs und ClosePort-Zeiten zu überarbeiten...

wie sicherlich bekannt war, gab es zb beim close port immer das problem das es fast egal war wie hoch firewall oder die geschwindigkeitsprozente waren der close port ab 100% geschwindigkeit bedeutend langsamer wurde.

und auch beim hacken machte es ab einer bestimmten menge viren nicht mehr mehr vertretbar wie lange ein hack dauerte...

von nun an ist es wie folgt

ein close port dauert nun zwischen 20 und 90 sek

dabei kommt es auf die höhe der firewall an sowie auf die geschwindigkeitsprozente... die prozente werden bis zu 250% berechnet... alles was drüber ist bleibt demnach bei 250% was die berechnung angeht.
wenn ein user also fw999 und 250% geschwindigkeit hat, kann er in 20 sek closen....
andersrum, wenn ein user fw1 und 0% geschwindigkeit hat braucht er 90 sek...


bei den hacks ist es im grunde genauso...

subscans und remote manipulate bleibt so wie es war...

hacks und scans unterscheiden sich nur von den zeiten.... scans gehen etwas schneller als ie restlichen hacks

scans dauern zwischen 30 und 120 sek
hacks dagegen zwischen 35 und 240 sek
transfers dauern zwischen 35 und 120 sek


dabei kommt es auf die internetverbindung, die anzahl der viren und die geschwindigkeitsprozente an. die geschwindigkeitsprozente für die hacks werden bis zu 300% berrechnet...

wenn beide user (angreifer/verteidiger) also eine 10gb leistung haben, und der angreiffer 1 virus versendet und 300% geschwindigkeit hat, dann brauch er für einen hack 35 sek und für einen scan 30 sek
wenn jedoch ein user nur ein 28k modem hat, und der angreifer 1998 viren versendet und 0% geschwindigkeit hat, dann dauert ein hack 4 minuten und ein scan 2 minuten....


weiterhin habe ich die angriffs- und verteidigungswerte verbessert... bzw die berechnung

im grunde stehen sich nun die werte wirklich gegenüber.... av gegen mk, angriffs% gegen verteidigungs%, vergleich der geschwindigkeits% sowie der betriebssystemwerte und natürlich auch die virenstärke...

auch beim ids und ips fließen nun angriffs% und verteidigungs% so wie die geschwindigkeiten mit ein...


ich denke auf die art und weise der berechnung macht es nun wirklich merkbare unterschiede durch die skillung eurer pcs bzw accs...

viel spass damit und gebt bitte ein feedback...


Ich hätte bitte information über die aktuell gültigen Werte? Den Beitrag an sich finde ich ganz toll, aber die Berechnungen stimmen mit der Realtät derzeit nicht überein. Ich habe auch bereits teste gemacht und einen längeren Beitrag dazu geschrieben. Der ist aber hinfällig wenn derzeit andere Werte die Berechnungen verändern.

Daher was ist denn aktuell der Stand bitte?

Herzlich Dank.




Ich beziehe mich auf den besagten Thread. Und der von Atze angegebenen Formel.

Ich habe folgendes Festgestellt:
Bild

Im Bild sind die Unterschiede zwischen Messungen innerhalb des Clusters, und nach austritt zu erkennen.. es gibt keine.

Es gibt zwar, basierend auf meinem Messverfahren und den Reload nach dem close ports gewisse Abweichungen , aber der Fehler ist dennoch klar identifizierbar wenn man hierauf schaut:

Bild

Die ersten beiden Balken sind identisch, der gelbe Balken ist das das Soll laut der angegebenen Formel, der letzte Balken ist das Resultat wenn man die Berechnung nach
der Formel ausführt allerdings bei Clusterspeed 90 , also den Maximalwert berechnet. (ohne Rundungen in den Zwischenschritten).

Zu den gegenarbumenten in der originaldiskussion möchte ich noch aufgreifen , das Spieler gemeckert haben close Ports wären zu schnell.
Da die Angriffsmeldung eher in der Regel als nur gelegentlich deutlich verspätet auftritt , und manchmal gar nicht, sehe ich die FW im Grunde als zu langsam und benachteiligt an.


2. Problem

Ebenso wie bei den Angriffen, unterliegt der tatsächliche Berechnung der Geschwindigkeit des Tabs im Browser, kann also ERHEBLICH verzögert werden, bis zu einigen Minuten.
Das läßt darauf schließen das die Berechnung nur Clientseitig erfolgt, anstatt serverseitig oder per Systemuhr. Ich nehme an das die Systemuhr wegen der Manipulationsgefahr nicht verwendet wird. Das ist aber ein Problem. Insbesondere da sich der Tab im grunde auch "beschleunigen läßt". Ich sehe hier deutliche Probleme für die Spielbalance und eine Schwachstelle / einen Angriffspunkt.
Derzeit kann ich nur davn abraten, Tabs zu wechseln oder während eines Angriffs z.B. den Chat zu benutzen, insbesondere bei der Nutzung von Browsern und ggf Plugins die ein Zeit- oder Prioritästsmangment für Tabs erlauben oder nutzen. Bei mir ist das definitv der Fall. (Chrome).

Hier könnte man über verschiedenen Lösungsansätze zur Verbesserung nachdenken.


Alle Messungen wurden im Aktiven Tab ohne Tabwechsel vorgenommen, die Messungen soweit erforderlich erscheinend zu Kontrollzwecken wiederholt vorgenommen...
Die Messung wurde nur "Sekundengenau" Manuell vorgenommen. Abweichungen hierdurch im Rahmen von ca. 1 Sek sind als normal anzusehen.

ich wünscht , es gäbe Spoiler

so long

Bone

edit :
Firewall variabel, siehe Tabelle
Speed 86,84%
System Tuner 10
Cluster Root Speed 200
BNE
Cheater
 
Beiträge: 140
Registriert: 17. Sep 2019, 06:59
Hat Gedankt: 6 times
 Danksagungen: 5 times

Re: BUG nachgewiesen -close ports-

Beitragvon BNE » 23. Jan 2020, 16:00

Es noch eine Korrektur zu den Grafiken. die erste Firewall 121 sollte 211 lauten , Zahlen verdreht beim Tippen- was auch den falschen Wert bei der Berechneten Close Zeit begründet..

211 = 63,73813714 s ohne Cluster 46,23813714 s mit Max Cluster Speed
121 = 65,31471371 s ohne Cluster 47,81471371 s mit Max Cluster Speed
BNE
Cheater
 
Beiträge: 140
Registriert: 17. Sep 2019, 06:59
Hat Gedankt: 6 times
 Danksagungen: 5 times

Re: BUG nachgewiesen -close ports-

Beitragvon BNE » 8. Feb 2020, 15:07

Ist dieser Beitrag vielleicht nur untergegangen??
BNE
Cheater
 
Beiträge: 140
Registriert: 17. Sep 2019, 06:59
Hat Gedankt: 6 times
 Danksagungen: 5 times

Re: BUG nachgewiesen -close ports-

Beitragvon ATZENPOWER » 13. Feb 2020, 21:42

wenn ich mich nicht ganz irre, fließt zb auch das joblevel mit ein.... die berechnungen stimmen auf jeden fall und wurden über einen langen zeitraum ausgiebig getestet.... und da daran seit langen nichts verändert wurde, sollten diese demnach auch stimmen....
BildBildBildBildBildBildBild

Bild
ATZENPOWER
Geschäftsführung
 
Beiträge: 1759
Registriert: 28. Jun 2008, 20:29
Hat Gedankt: 113 times
 Danksagungen: 176 times

Re: BUG nachgewiesen -close ports-

Beitragvon BNE » 14. Feb 2020, 20:16

Im Cluster befindlich ist equivalent zu ohne Cluster.. das kann zumindest nach Deinen Angaben zur Formel mometan leider nicht stimmen.

Kannst es ja ganz einfach nachrechnen oder selber messen wenn du meiner Messung nicht vertraust.
BNE
Cheater
 
Beiträge: 140
Registriert: 17. Sep 2019, 06:59
Hat Gedankt: 6 times
 Danksagungen: 5 times


Zurück zu Bugs / Fehlermeldungen



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron