Frage zu Netzwerkprotokoll

TheTester

ceplusplus schrieb:

Mhm, aber was, wenn eine enorme Verbindungsverzögerung existiert, und der Client schon auf den Gegner einhaut, während der Server erst 20 Sekunden später damit beginnt?

IMHO wird die Kampflogik etc. vom Server verwaltet. Soll heissen falls so eine extrem hohe Verbindungsverzögerung existiert wird sich das nur auf der Clientseite bemerkbar machen, auf dem Server sollte alles normal ablaufen. D.h. wiederum, nicht du haust auf einen nichtreagierenden Computergegner, sondern der Computergegner haut auf deinen nicht reagierenden Avatar ein. Falls zwei menschliche Spieler gegeneinander spielen, wird wohl der gewinnen der die wenigsten Lags hat.

tt

ceplusplus

Hmm, bezüglich deinem Schema, @krabbels:

Wäre es nicht besser am Clienten erst mit dem Attackieren zu beginnen, wenn die erste Antwort vom Server kommt?

Also in etwa so:

- Client sendet an Server, "Möchte attackieren"
- Server erhält Nachricht und berechnet den Kampf, beginnt gleichzeitig mit dem ständigen senden von zB. "A31", "A95", .. 
was für ATTACK + abgezogenes Leben steht.

Dabei weiß dann der Client ganz sicher, dass die Attacke stattfindet.
Mir fällt keine einfachere, gleichsichere Möglichkeit ein.

Und es macht doch einen Unterschied, ob man 11592 oder 62 sendet?!

MfG

hustbaer

Am "einfachsten und sichersten" machst du das mit TCP - solange die Verbindung steht brauchst du dir da keine Sorgen machen dass irgendwas nicht angekommen ist.

Am "besten" macht man sowas aber mit UDP, da die Fehlerkorrektur-Mechanismen in TCP leider dafür sorgen dass deutliche Lags auftreten, wenn mal ein Paket nicht oder verändert angekommen ist.

ceplusplus

Wobei ja Fehlerkorrektur nicht unbedingt nötig wäre. Man könnte ja Bestätigungen einbauen, und falls was nicht ankommt, einfach nochmal senden oder so.

krabbels

ceplusplus schrieb:

Wäre es nicht besser am Clienten erst mit dem Attackieren zu beginnen, wenn die erste Antwort vom Server kommt?

Warum? Was erhoffst du dir davon?

krabbels schrieb:

Lags wirst du auch so nicht vermeiden können, im Gegenteil. Deine Variante halte ich sogar für noch gefährlicher, da auf dem Server bereits gekämpft wird während der Spieler gar nichts davon mitbekommt.

Bei Verbindungsstörungen würde der Client mit meiner Variante bereits kämpfen. Bei deiner Variante würde u.U. lediglich auf dem Server gekämpft werden. Der Spieler selber würde also gar nicht merken, dass schon lange gekämpf wird. Außerdem ist mit deiner Variante, durch die Rückbestätigungen, ein höheres Maß an Leistung bei Server und Bandbreite notwenig.

mad_martin

ceplusplus schrieb:

Und es macht doch einen Unterschied, ob man 11592 oder 62 sendet?!

MfG

Ich wage einfach mal die Behauptung, dass das nicht interessiert. Ob man jetzt ein Byte oder 2 oder 3 schickt, der Overhead durch UDP und IP ist auf jeden Fall da.

ceplusplus

@krabbels:
Stimmt sorry, da hatte ich nen Denkfehler.

@mad_martin:
Und bei 100.000 Spielern, die gleichzeitig auf einem Server online sind? (Lässt WinSock überhaupt so viele connects zu?)

krabbels

ceplusplus schrieb:

Und es macht doch einen Unterschied, ob man 11592 oder 62 sendet?!

Es macht sicher einen Unterschied, wieviel Daten du am Ende sendest. Nur ist es unrealistisch, dass man zum Speichern der Lebenspunkte mehr als 1 oder 2 Byte braucht und dass Veränderungen in einem wesentlich kleineren Rahmen liegen.

ceplusplus

Deinen letzten Satz verstehe ich nicht.

Naja jedenfalls wären es wohl immer 2 Byte, egal ob man nun das abzuziehende Leben oder den Lebenstand sendet. Das meintest du wohl?

Thomy

@mad_martin:
Und bei 100.000 Spielern, die gleichzeitig auf einem Server online sind? (Lässt WinSock überhaupt so viele connects zu?)

Man müsste wahrscheinlich auf ein anderes System umsteigen, wenn man mehr als 65000 Clienten bedienen müsste!
Ich hab auch schon nachgeschaut und überlegt wie man das Problem lösen könnte! Letztendlich bin ich zu der Erkenntnis gekommen, dass es garnicht zu lösen ist!
Wer Lösungen hat, bitte sofort nennen!

-Mehrere Server laufen lassen!

krabbels

ceplusplus schrieb:

Naja jedenfalls wären es wohl immer 2 Byte, egal ob man nun das abzuziehende Leben oder den Lebenstand sendet. Das meintest du wohl?

Du kannst auch anfangen bei einer maximal möglichen Energie von 200 Punkten(mind. 1 Byte) bei einem Ereignis, was dem Spieler 25 Punkte abzieht nur 5 Bit zu schicken. Mir wäre das zu frickelig. Und ob du da nun wirklich ein Leistungszuwachs rausholst, ist fragwürdig.

ceplusplus

Jo, schon klar.

Aber ich hätte halt gerne optimalste Optimalität
Also so trafficsparend und sicher wie nur möglich.

Pyr0kar

ich finde schon, dass es sinn macht für den client erst den server zu fragen, ob er einen mob angreifen darf oder nicht.

was wenn z.b. der client versucht einen befreundeten spieler/NPC/mob anzugreifen? der client würde dann einfach drauf loshämmern und die animation abspielen und dann (vielleicht) irgendwann merken dass er es nicht darf, oder auch nicht. ziemlich unsinnig.

bsp:

client -> server: [attack-request] auf mob id 338
server -> client: [attack-reply] accept
client -> server: [attack-action] skill id 228 (irgendein skill halt)
(animation abspielen für skill id 228)
...

client -> server: [attack-request] auf mob id 339
server -> client: [attack-reply] denied (ist ein befreundeter spieler)

um vollständige sicherheit zu garantieren müsste der server natürlich so schlau sein, und ein [attack-action] packet auch nur akzeptieren, wenn vorher ein [attack-request] abgeschickt und mit accept beantwortet wurde.

ceplusplus

Jo stimmt.
Geht aber noch einfacher, attack-action braucht man doch nicht mehr zu senden.

client -> server: [attack-request] auf mob id 338 
server -> client: [attack-reply] accepted

Accepted am server bedeutet: Berechnung beginnen
Accepted am clienten bedeutet: Animation beginnen

client -> server: [attack-request] auf player id 594
server -> client: [attack-reply] denied

...

MfG

Pyr0kar

ceplusplus schrieb:

Jo stimmt.
Geht aber noch einfacher, attack-action braucht man doch nicht mehr zu senden.
client -> server: [attack-request] auf mob id 338 
server -> client: [attack-reply] accepted
Accepted am server bedeutet: Berechnung beginnen
Accepted am clienten bedeutet: Animation beginnen
client -> server: [attack-request] auf player id 594
server -> client: [attack-reply] denied
...

MfG

Hatte ich mir auch überlegt.
Das hätte aber den Nachteil, dass du nach jedem Angriff neu serverseitig prüfst, ob der Mob angegriffen werden kann.
Ich dachte es mir also so, dass die [attack-action]-Packete nicht mit accept beantwortet werden müssen um Overhead zu vermeiden, sondern nur einmalig mittels des [attack-request]-Packets geprüft wird, ob man den Mob angreifen darf.

Bsp:

client -> server: [attack-request] auf mob id 338
server -> client: [attack-reply] accept
client -> server: [attack-action] skill id 228 (irgendein skill halt)
(animation abspielen für skill id 228) 
client -> server: [attack-action] skill id 228 (irgendein skill halt)
(animation abspielen für skill id 228) 
client -> server: [attack-action] skill id 228 (irgendein skill halt)
(animation abspielen für skill id 228) 
...

Wahrscheinlich ist deine Variante aber doch sicherer/besserer.
Soll auch vorkommen, dass Mobs die Seiten wechseln, außer Reichweite geraten oder Ähnliches - also lieber jedesmal neu auf Bestätigung warten.

ceplusplus

Eigentlich meinte ich, dass attack-request nur einmalig gesendet wird...

client -> server: [attack-request] auf mob id 338
server -> client: [attack-reply] accepted

Somit beginnt der Server mit dem berechnen und am Client findet die Animation statt.

Die einzigen Pakete, die während der Attacke gesendet werden, sind Aktualisierungs-Pakete vom Server zum Clienten wie neuer Lebenstand, ob die Attacke getroffen hat usw...

Is ja egal ob der Gegner wegrennt, vor jeder Attacke wird ja eine Bereichsprüfung durchgeführt, ob der Spieler in Reichweite des Mobs ist.

MfG

krabbels

Pyr0kar schrieb:

was wenn z.b. der client versucht einen befreundeten spieler/NPC/mob anzugreifen? der client würde dann einfach drauf loshämmern und die animation abspielen und dann (vielleicht) irgendwann merken dass er es nicht darf, oder auch nicht. ziemlich unsinnig.

Blödsinn. Der Client weiß doch selber, dass das ein befreundeter Spieler/NPC/Mob ist und wird daher einen Angriff verweigern.

hustbaer

@Thomy:

Thomy schrieb:

@mad_martin:
Und bei 100.000 Spielern, die gleichzeitig auf einem Server online sind? (Lässt WinSock überhaupt so viele connects zu?)

Man müsste wahrscheinlich auf ein anderes System umsteigen, wenn man mehr als 65000 Clienten bedienen müsste!
Ich hab auch schon nachgeschaut und überlegt wie man das Problem lösen könnte! Letztendlich bin ich zu der Erkenntnis gekommen, dass es garnicht zu lösen ist!

Es bedarf keiner Lösung wo kein Problem ist.
Das 64k Limit ist soweit ich das beurteilen kann eine "Urban Legend".
Eine TCP Verbindung wird festgelegt durch Source IP, Source Port, Destination IP und Destination Port.
Destination IP und Port sind dabei festgelegt (durch den Server), aber Source IP und Source Port sind es nicht.
Serverseitig wird bei einer TCP Verbindung kein Port "verbraucht" (Wobei der Server hier einfach derjenige PC ist welcher listen/accept macht, der Client derjenige der connect macht.)
Serverseitig wird nur ein Socket verbraucht, und nirgends steht geschrieben dass es nur 64k SOCKETs geben kann (ein SOCKET ist normalerweise ein "int" Handle, d.h. meist 32 Bit breit - da kann es wesentlich mehr als 64k davon geben).

Und mit UDP exisitert das Problem sowieso nicht.

Davon abgesehen ist UDP für Server mit massiv vielen gleichzeitigen "Connections" sowieso die bessere Wahl (bzw. sagen wir einfach mal "Clients" statt "Connections", da UDP keine Connections kennt), da man bei UDP viel besser die Kontrolle hat wieviel Resourcen pro Client verbraucht werden. Man muss z.B. das "Demultiplexing" selbst machen, was es aber eben ermöglicht genau zu kontrollieren wie gross die verwendeten Puffer sind etc.

Wer Lösungen hat, bitte sofort nennen!

-Mehrere Server laufen lassen!

Reicht dir das als "Lösung" (für das IMO nicht vorhandene Problem)?

Pyr0kar

krabbels schrieb:

Pyr0kar schrieb:

was wenn z.b. der client versucht einen befreundeten spieler/NPC/mob anzugreifen? der client würde dann einfach drauf loshämmern und die animation abspielen und dann (vielleicht) irgendwann merken dass er es nicht darf, oder auch nicht. ziemlich unsinnig.

Blödsinn. Der Client weiß doch selber, dass das ein befreundeter Spieler/NPC/Mob ist und wird daher einen Angriff verweigern.

Blödsinn. Wenn du die Clientseite entscheiden lässt, welche Spieler angegriffen werden können, ist dein Spiel ziemlich unsicher.

Da lässt du Memory-Editoren, selbstgebaute Clients, Hexeditoren, Cheattools usw. freien Lauf.

Nur als reales Bespiel, in "Kalonline" kann man mit Hilfe eines einfachen Tricks mit einem Memory-Editor die Reichweite der Angriff bis ins Unendliche erhöhen und die Spielergeschwindigkeit ebenso, und der Server spielt dort einfach mit ohne Nachzuprüfen, wie weit du nun von deinem Ziel entfernt bist.

Dazu brauchst du nichtmal eine Programmiersprache zu können, sondern nur ein Tool haben und ein paar Werte umstellen indem du Knöpfchen drückst

Solche Spiele sind es dann, die Anti-Hackingtools und solch einen Kram einbauen um die Sicherheit zu erhöhen, weil sie alles clientseitig haben.

Soviel also zu "der client weiß doch selbst".

Thomy

Reicht dir das als "Lösung" (für das IMO nicht vorhandene Problem)?

THX, bin bisher immer davon ausgegange, dass jede Connection einen Port verbraucht! Dass es aber mehr als 2^16 Ports gibt, bezweifele ich trotzdem!
Man sieht doch praktisch überall nur Einstellungen und co., die von "0"-65535 gehen!

---

Klaro mit UDP hat man das Problem nicht :p !

Gruß
tHOMY