Frage zu Netzwerkprotokoll

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

rapso

hustbaer schrieb:

Das 64k Limit ist soweit ich das beurteilen kann eine "Urban Legend".

es ist also dein glauben vs die legend, spannender fight ;).

da ich das vor ewigkeiten auch mal wissen wollte, hab ich natuerlich nachgesehen. windows95 hatte 255sockets als limit, winNT hatte 65535.

Wie das zZ ist sollte man einfach irgendwo raussuchen statt das hier jeder was anderes postet

krabbels

Pyr0kar schrieb:

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

grml $:\$
Wenn der Client die Information, dass xyz ein NPC ist, anders interpretieren würde, würde das Spiel auf ihm nicht mehr synchron mit dem Server laufen. Du kannst daraus keinen Hack schlagen. Du kannst ja sinnloserweise gerne eine Nachricht "Möchte attackieren" absenden, aber auf dem Client auch noch die Kampf Animation/Musik etc. beim Angriff eines NPCs abzuspielen, wäre vermutlich nicht wirklich im Interesse des Spiels.

Pyr0kar

krabbels schrieb:

Pyr0kar schrieb:

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

grml $:\$
Wenn der Client die Information, dass xyz ein NPC ist, anders interpretieren würde, würde das Spiel auf ihm nicht mehr synchron mit dem Server laufen. Du kannst daraus keinen Hack schlagen. Du kannst ja sinnloser weise gerne eine Nachricht "Möchte attackieren" absenden, aber auf dem Client auch noch die Kampf Animation/Musik etc. beim Angriff eines NPCs abzuspielen, wäre vermutlich nicht wirklich im Interesse des Spiels.

Hast du dir überhaupt mal mein Beispiel angeschaut?

In "kalonline" _kann_ man in der Tat sehr gut einen Hack daraus schlagen, dass nicht serverseitig überprüft wird ob der Angriff stattfinden darf.

Du kannst vom einen Ende der gesamten Map ein anderes Monster auf dem anderen Ende angreifen, wenn du es selektiert hast.
Du kannst das Vieh damit sogar töten, geht alles wunderbar.

Und das nur, weil der Client einfach "greife NPC ... an" sendet und der server so blöd ist, und es einfach tut und die HP abzieht.

Der Server sollte die anfrage prüfen (auf Reichweite, Befreundete Spieler usw.) und seine Antwort dem Client schicken, damit dieser weiß, ob er die Animation abzuspielen hat oder nicht, ist nämlich ziemlich blöd wenn der Client die Angriffsanimation abspielt und der Mob keine HP verliert.

Wenn du Hacks vermeiden willst kommst du um eine serverseitige Überprüfung nicht drum herum.

Den Client zu cheaten/bearbeiten ist immer möglich, ob das nun schwer oder leicht gemacht wird ist eine andere sache, bei kalonline wird es leicht gemacht.

Den Server zu cheaten/bearbeiten wird ziemlich schwer ohne physikalischen Zugang.

Wenn der Client die Information, dass xyz ein NPC ist, anders interpretieren würde, würde das Spiel auf ihm nicht mehr synchron mit dem Server laufen. Du kannst daraus keinen Hack schlagen.

Ein Memory-Editor sorgt eigentlich ganz schnell dafür, dass der _Client_ denkt, es sei ein nicht-befreundeter. Da lässt sich super ein Hack draus schlagen.

Mit der Reichweite dauert das z.b. bei einigen Onlinespielen nur wenige Sekunden mit dem richtigen Programm die Speicherstellen zu bearbeiten und es funktioniert super.

Ein gutes Spiel würde sich selbst nicht cheaten lassen, wenn du den Source von deinem Client freigibst. Du musst immer damit rechnen dass jemand den Client umbiegt, der Server muss damit klar kommen und darf nicht falsch handeln.

Alles andere is Security through obscurity (siehe http://de.wikipedia.org/wiki/Security_through_obscurity)

krabbels

Pyr0kar schrieb:

In "kalonline" _kann_ man in der Tat sehr gut einen Hack daraus schlagen, dass nicht serverseitig überprüft wird ob der Angriff stattfinden darf.

Du schickst an den Server die Nachricht "Möchte attackieren" also wird es doch serverseitig überprüft. Niemand spricht davon, dass es nicht so sein sollte. Der Client braucht nun aber keine Rückbestätigung mehr. Der Client kann Ereignisse gerne anders interpretieren; Er kann aus NPCs Blumen machen, aus Häusern Bäume und Schwertern Atombomben. Das tatsächliche Spiel findet aber auf dem Server statt, wo Schwerter eben keine Atombomben sind.

Pyr0kar schrieb:

Der Server sollte die anfrage prüfen (auf Reichweite, Befreundete Spieler usw.)

Richtig. Und anschließend das tatsächliche Spiel aktualisieren.

Pyr0kar schrieb:

und seine Antwort dem Client schicken, damit dieser weiß, ob er die Animation abzuspielen hat oder nicht, ist nämlich ziemlich blöd wenn der Client die Angriffsanimation abspielt und der Mob keine HP verliert.

Nein. Der Client weiß selber, dass er da einen NPC angreifen will also braucht er gar keine Animation zu starten, da er die Antwort vom Server bereits kennt.

Pyr0kar schrieb:

Ein Memory-Editor sorgt eigentlich ganz schnell dafür, dass der _Client_ denkt, es sei ein nicht-befreundeter. Da lässt sich super ein Hack draus schlagen.

Wenn der Client durch einen Hack NPCs für angreifbar oder Schwerter für Atombomben hält, kann er das gerne machen. Der Server wird die Zusammenarbeit aber verweigern. Die beiden Spiele laufen nicht mehr synchron.
Verstehst du es nun?

ceplusplus

Achso, krabbels, du meinst dass eine Prüfung sowohl clientseitig als auch serverseitig stattfinden soll? Würde sogar traffic einsparen.

Client will NPC angreifen -> Verweigert, da Client überprüft

-Client wird gehackt-

Client sendet Paket zum NPC angreifen -> Server verweigert, da überprüft

MfG

krabbels

ceplusplus schrieb:

Achso, krabbels, du meinst dass eine Prüfung sowohl clientseitig als auch serverseitig stattfinden soll? Würde sogar traffic einsparen.

Client will NPC angreifen -> Verweigert, da Client überprüft

-Client wird gehackt-

Client sendet Paket zum NPC angreifen -> Server verweigert, da überprüft

MfG

Korrekt. Auf beiden Seiten läuft ja das gleiche Spiel, von daher liegt das nur Nahe. Es würde ja imho auch keinen Sinn machen die Spiele-Logik beim Client auszuschalten. Vielmehr entstehen dadurch enorme Probleme, da der Client in der Zeit, in der er keine Daten vom Server erhält nichts machen kann. Nehmen wir an, der Abgleich mit dem Server findet nur 3 mal pro Minute statt, dann würde eine Aktualisierung des Client-States auch nur 3 mal pro Minute geschehen. Ich glaube, das hemmt dann doch den Spielspass ein wenig.

hustbaer

Thomy schrieb:

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!

Es gibt auch nur 2^16 Ports, du darfst aber Ports nicht mit Sockets verwechseln.

rapso schrieb:

hustbaer schrieb:

Das 64k Limit ist soweit ich das beurteilen kann eine "Urban Legend".

es ist also dein glauben vs die legend, spannender fight ;).

da ich das vor ewigkeiten auch mal wissen wollte, hab ich natuerlich nachgesehen. windows95 hatte 255sockets als limit, winNT hatte 65535.

Wie das zZ ist sollte man einfach irgendwo raussuchen statt das hier jeder was anderes postet

Also hier steht was von 100k in der 32 Bit Version und 1m in der 64 Bit Version. Beides > 64k.

http://download.microsoft.com/download/5/8/7/587312a9-d421-4f07-9d9e-b6515720082b/perfscal.doc

rapso

hustbaer schrieb:

Thomy schrieb:

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!

Es gibt auch nur 2^16 Ports, du darfst aber Ports nicht mit Sockets verwechseln.

rapso schrieb:

hustbaer schrieb:

Das 64k Limit ist soweit ich das beurteilen kann eine "Urban Legend".

es ist also dein glauben vs die legend, spannender fight ;).

da ich das vor ewigkeiten auch mal wissen wollte, hab ich natuerlich nachgesehen. windows95 hatte 255sockets als limit, winNT hatte 65535.

Wie das zZ ist sollte man einfach irgendwo raussuchen statt das hier jeder was anderes postet

Also hier steht was von 100k in der 32 Bit Version und 1m in der 64 Bit Version. Beides > 64k.

http://download.microsoft.com/download/5/8/7/587312a9-d421-4f07-9d9e-b6515720082b/perfscal.doc

schaut wie Marketing BS aus.
man sollte man-pages oder msdn bevorzugen. siehe: http://msdn2.microsoft.com/en-us/library/ms739169.aspx

Pyr0kar

krabbels schrieb:

ceplusplus schrieb:

Achso, krabbels, du meinst dass eine Prüfung sowohl clientseitig als auch serverseitig stattfinden soll? Würde sogar traffic einsparen.

Client will NPC angreifen -> Verweigert, da Client überprüft

-Client wird gehackt-

Client sendet Paket zum NPC angreifen -> Server verweigert, da überprüft

MfG

Korrekt. Auf beiden Seiten läuft ja das gleiche Spiel, von daher liegt das nur Nahe. Es würde ja imho auch keinen Sinn machen die Spiele-Logik beim Client auszuschalten. Vielmehr entstehen dadurch enorme Probleme, da der Client in der Zeit, in der er keine Daten vom Server erhält nichts machen kann. Nehmen wir an, der Abgleich mit dem Server findet nur 3 mal pro Minute statt, dann würde eine Aktualisierung des Client-States auch nur 3 mal pro Minute geschehen. Ich glaube, das hemmt dann doch den Spielspass ein wenig.

*zustimm*

Nur schade, dass dadurch die gleiche Prüfung 2x im Programmcode vorkommt, einmal im Client und einmal im Server.
Oder würdet ihr dafür eine Lib oder was ähnliches coden und von beiden benutzen lassen?

hustbaer

rapso schrieb:

hustbaer schrieb:

Thomy schrieb:

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!

Es gibt auch nur 2^16 Ports, du darfst aber Ports nicht mit Sockets verwechseln.

rapso schrieb:

hustbaer schrieb:

Das 64k Limit ist soweit ich das beurteilen kann eine "Urban Legend".

es ist also dein glauben vs die legend, spannender fight ;).

da ich das vor ewigkeiten auch mal wissen wollte, hab ich natuerlich nachgesehen. windows95 hatte 255sockets als limit, winNT hatte 65535.

Wie das zZ ist sollte man einfach irgendwo raussuchen statt das hier jeder was anderes postet

Also hier steht was von 100k in der 32 Bit Version und 1m in der 64 Bit Version. Beides > 64k.

http://download.microsoft.com/download/5/8/7/587312a9-d421-4f07-9d9e-b6515720082b/perfscal.doc

schaut wie Marketing BS aus.
man sollte man-pages oder msdn bevorzugen. siehe: http://msdn2.microsoft.com/en-us/library/ms739169.aspx

Wieso Marketing BS? Ich finde die Grenze 100k bzw. 1m ist lächerlich niedrig, auf jeden Fall niedrig genug um glaubhaft zu sein.

In dem von dir verlinkten Artikel steht nur "The maximum number of sockets supported by a particular Windows Sockets service provider is implementation specific. "

Und das Makro FD_SETSIZE beeinflusst nur wie gross man ein "fd_set" mit den Berkeley kompatiblen Makros (FD_ZERO, FD_SET, ...) machen kann. Wenn man die Werte selbst in ein int/LONG/ULONG Array schreibt muss man FD_SETSIZE nicht definieren (kann aber trotzdem > 64 Sockets in einem select verwenden). Genauso wenn man select() nicht verwendet sondern WSAAsyncSelect/WSAEventSelect oder IO completion ports.

Hat auf jeden Fall nichts damit zu tun wieviel Sockets das OS wirklich unterstützt.