Internet Programmierung ohne Internet?

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	sinjin Betreff: Internet Programmierung ohne Internet?	Fr, Mai 20, 2016 19:49 Antworten mit Zitat
Ich programmiere ja recht viel und auch schon sehr lange, aber im Netz bin ich erst seit 5 Jahren(Nicht seit ich 5 bin, das ist 35 Jahre her). Wie progge und teste ich Code, ohne Internet, aber natürlich Internetfähig? Muss man dafür nen Apache-Server oder sowas haben? Und, brauche ich 2 Programme, eines welches als Server dient und das andere als Client? Ich habe mich damit nie auseinandergesetzt. Beispiele wären super.

sinjin

Betreff: Internet Programmierung ohne Internet?

Fr, Mai 20, 2016 19:49
Antworten mit Zitat

Ich programmiere ja recht viel und auch schon sehr lange, aber im Netz bin ich erst seit 5 Jahren(Nicht seit ich 5 bin, das ist 35 Jahre her). Wie progge und teste ich Code, ohne Internet, aber natürlich Internetfähig? Muss man dafür nen Apache-Server oder sowas haben? Und, brauche ich 2 Programme, eines welches als Server dient und das andere als Client? Ich habe mich damit nie auseinandergesetzt. Beispiele wären super.

	DAK	Fr, Mai 20, 2016 20:36 Antworten mit Zitat
Sehr breite Frage, kommt stark drauf an, was du tun willst. Zuerst ist die Frage, machst du das Ganze Peer-To-Peer oder Server-Client? Das sind die beiden wichtigsten Grund-Architekturen. Bei Peer-To-Peer hast du mehrere gleichwertige Partner, die sich die Verbindung untereinander ausmachen. Keiner ist höherrangiger als der Rest. Vorteil: Du brauchst keinen Server Nachteil: Deutlich mehr Aufwand, sobald man mehr als zwei Spieler hat. In diesem Fall kannst du einfach mehrere Instanzen des Spiels auf deinem Computer laufen lassen und als Zieladresse 127.0.0.1 (oder localhost) eingeben. Das leitet einfach auf den eigenen Computer zurück. Für besseres Testen kannst du mehrere Computer in deinem LAN verwenden. Bei Server-Client hast du einen Server, der entweder selbst ein eigener Spieler ist oder nicht selbst am Spiel teilnimmt (=dedicated server). Dieser Server kümmert sich darum, die Spielwelt für die Clients zur Verfügung zu stellen. Die Clients machst du wie gewohnt in Blitz oder so. Beim Server hast du jetzt etwas Auswahl. Den kannst du ohne Weiteres auch in Blitz programmieren, kannst aber auch andere Serversoftware verwenden. Ein Apache-Server z.B. ist ok, wenn das Spiel keine hohe Aktualisierungsgeschwindigkeit braucht (z.B. ist es ok bei einem rundenbasierten Spiel, das das "Zug hochladen" eine Sekunde braucht, bei einem Shooter wäre es katastrophal). Der Vorteil davon wäre, das du das auf einem gratis Webhoster laufen lassen kannst. Ansonsten ist es hier wie bei Peer-To-Peer. Lass den Server auf deinem Computer laufen und verbinde dich von den anderen Instanzen aus nach 127.0.0.1. Für weitere Hilfe müsstest du mal sagen, was du vor hast zu tun.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Fr, Mai 20, 2016 20:36
Antworten mit Zitat

Sehr breite Frage, kommt stark drauf an, was du tun willst.

Zuerst ist die Frage, machst du das Ganze Peer-To-Peer oder Server-Client? Das sind die beiden wichtigsten Grund-Architekturen.

Bei Peer-To-Peer hast du mehrere gleichwertige Partner, die sich die Verbindung untereinander ausmachen. Keiner ist höherrangiger als der Rest.
Vorteil: Du brauchst keinen Server
Nachteil: Deutlich mehr Aufwand, sobald man mehr als zwei Spieler hat.

In diesem Fall kannst du einfach mehrere Instanzen des Spiels auf deinem Computer laufen lassen und als Zieladresse 127.0.0.1 (oder localhost) eingeben. Das leitet einfach auf den eigenen Computer zurück.
Für besseres Testen kannst du mehrere Computer in deinem LAN verwenden.

Bei Server-Client hast du einen Server, der entweder selbst ein eigener Spieler ist oder nicht selbst am Spiel teilnimmt (=dedicated server). Dieser Server kümmert sich darum, die Spielwelt für die Clients zur Verfügung zu stellen. Die Clients machst du wie gewohnt in Blitz oder so. Beim Server hast du jetzt etwas Auswahl. Den kannst du ohne Weiteres auch in Blitz programmieren, kannst aber auch andere Serversoftware verwenden. Ein Apache-Server z.B. ist ok, wenn das Spiel keine hohe Aktualisierungsgeschwindigkeit braucht (z.B. ist es ok bei einem rundenbasierten Spiel, das das "Zug hochladen" eine Sekunde braucht, bei einem Shooter wäre es katastrophal). Der Vorteil davon wäre, das du das auf einem gratis Webhoster laufen lassen kannst.
Ansonsten ist es hier wie bei Peer-To-Peer. Lass den Server auf deinem Computer laufen und verbinde dich von den anderen Instanzen aus nach 127.0.0.1.

Für weitere Hilfe müsstest du mal sagen, was du vor hast zu tun.

Gewinner der 6. und der 68. BlitzCodeCompo

	sinjin	Fr, Mai 20, 2016 20:54 Antworten mit Zitat
Danke für die schnelle und gute Antwort. Letztendlich will ich beides Peer-to-Peer und/oder Server-Client. Ich gehe mal vom ganz Kleinen ins Grosse. Mal angenommen ich gehe davon aus, dass sich nur wenige Spieler einfinden werden...Ist das Peer-to-Peer? Sry, wie gesagt, ich habe vom vom programmiererischen Standpunkt aus NULL Plan im Netz. Aber ich gehe davon aus, selbst wenn das von 3 Usern sich das auf einmal auf 100000 User erhöhen würde, sich das vom Programm kaum ändern wird.... Wie gesagt, ein Beispiel Code würde mich freuen. Dann lieber die Server-Client-Vaiant...ach... Haste nicht Code von beiden Varianten? Sry, ich spreche kein Deutsch, ich spreche nur Code Wie gesagt, ich will es einfach nur testen OHNE Inet. Also bei Peer-to-Peer wüssten ja nur meine "Freunde" von der IP und worum es sich handelt....Den Apache-Server habe ich nur erwähnt, weil ich mal HTTPs erstellen sollte, wo auch PHP ins Spiel kam, und das ging nicht anders zu testen als halt den Apache wo es möglich ist, den auf nem Localhost einzurichten aber mit ner anderen IP.

sinjin

Fr, Mai 20, 2016 20:54
Antworten mit Zitat

Danke für die schnelle und gute Antwort. Letztendlich will ich beides Peer-to-Peer und/oder Server-Client. Ich gehe mal vom ganz Kleinen ins Grosse. Mal angenommen ich gehe davon aus, dass sich nur wenige Spieler einfinden werden...Ist das Peer-to-Peer? Sry, wie gesagt, ich habe vom vom programmiererischen Standpunkt aus NULL Plan im Netz. Aber ich gehe davon aus, selbst wenn das von 3 Usern sich das auf einmal auf 100000 User erhöhen würde, sich das vom Programm kaum ändern wird.... Wie gesagt, ein Beispiel Code würde mich freuen. Dann lieber die Server-Client-Vaiant...ach... Haste nicht Code von beiden Varianten? Sry, ich spreche kein Deutsch, ich spreche nur Code Very Happy

Wie gesagt, ich will es einfach nur testen OHNE Inet.
Also bei Peer-to-Peer wüssten ja nur meine "Freunde" von der IP und worum es sich handelt....Den Apache-Server habe ich nur erwähnt, weil ich mal HTTPs erstellen sollte, wo auch PHP ins Spiel kam, und das ging nicht anders zu testen als halt den Apache wo es möglich ist, den auf nem Localhost einzurichten aber mit ner anderen IP.

	Thunder	Sa, Mai 21, 2016 0:11 Antworten mit Zitat
Internet ist nicht ohne.. Also da wirst du auch dein Basiswissen etwas erweitern müssen, denke ich Mal. Zumindest war das bei mir der Fall, wie ich mir Gedanken über Internet/Netzwerk machte. zu Server/Client vs. Peer-to-Peer: Das ist nicht so sehr eine Frage von wie groß (aber natürlich auch), aber eher: reden die spieler direkt miteinander (P2P) oder reden alle Spieler mit einem Server und der Server verteilt die Updates als Nachrichten an alle Spieler (Server/Client). Normalerweise möchtest du, wenn du das Spiel nicht nur LAN-fähig, sondern Internet-fähig haben willst, ein Server/Client-Modell. Die Erklärung: Im lokalen Netzwerk (wenn der Switch nicht gerade eine Firewall hat), kann jeder PC auf jeden Port eines anderen PCs zugreifen - in so einem Fall macht Peer-to-Peer keine Schwierigkeiten (es bedeutet ja eigentlich, dass jeder gleichzeitig Server und Client ist). Im Internet ist die Sache anders, weil die meisten PCs über einen Router im Internet hängen, der NAT macht. Ich habe z.B. zuhause die IP-Adresse 10.0.0.1, die gilt aber nur für mein lokales Netzwerk - außerhalb habe ich die von meinem Router. Damit hier P2P funktioniert, müsstest du von deinen Usern verlangen, dass sie in ihrer Router-Konfiguration Ports forwarden (d.h. dass der Router eine Verbindung von außerhalb zu einem Computer innerhalb des lokalen Netzwerks zulässt und den Netzwerkverkehr forwardet). Man kann da glaub ich mit UPnP oder Hole Punching was machen, aber vorsicht: das ist bei mir eher Halbwissen. Außerdem ist es oft ganz sinnvoll einen Server zu haben. Der kann z.B. anti-cheating mechanismen implementieren. Wenn die Clients miteinander kommunizieren, kann jeder irgendwas behaupten. sinjin hat Folgendes geschrieben: Aber ich gehe davon aus, selbst wenn das von 3 Usern sich das auf einmal auf 100000 User erhöhen würde, sich das vom Programm kaum ändern wird Das ist schwer zu sagen, aber ich denke, dass 100.000 zu hoch gegriffen ist. Es wird sich vermutlich von 3 bis 300 nicht sehr ändern. Mehr als 10.000 Spieler auf einem Server ist heftig (imho). Da führt dann vermutlich an multithreading auch kein Weg mehr vorbei, zumindest glaube ich kaum, dass ein BlitzMax-Server das verkraftet. Und 100.000 wird auch für einen nginx viel, denke ich Bzgl. BlitzMax: ich kann BNetEx sehr empfehlen. Eine Lib für BlitzMax mit der du da glaub ich relativ leicht reinkommst. Die Dokumentation ist gut und es sind Beispiele dabei. Link: https://www.blitzforum.de/foru...hp?t=13569 Wegen Apache: Wenn es ein relativ langsames Spiel ist, oder nur ein Online High-Score, dann kannst du theoretisch die Clients in BlitzMax mit einem Apache-Server reden lassen, der die Server-Angelegenheiten per PHP abwickelt. Du müsstest nur die BlitzMax-Programme auf den Server auf Port 80 richten (jedenfalls auf den wo der Apache läuft). Oder einen anderen HTTP-Server deiner Wahl, weil ich denke dass es bessere gibt. Ich hoffe die Antwort ist nicht zu durcheinander
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Sa, Mai 21, 2016 0:11
Antworten mit Zitat

Internet ist nicht ohne.. Also da wirst du auch dein Basiswissen etwas erweitern müssen, denke ich Mal. Zumindest war das bei mir der Fall, wie ich mir Gedanken über Internet/Netzwerk machte.

zu Server/Client vs. Peer-to-Peer: Das ist nicht so sehr eine Frage von wie groß (aber natürlich auch), aber eher: reden die spieler direkt miteinander (P2P) oder reden alle Spieler mit einem Server und der Server verteilt die Updates als Nachrichten an alle Spieler (Server/Client).

Normalerweise möchtest du, wenn du das Spiel nicht nur LAN-fähig, sondern Internet-fähig haben willst, ein Server/Client-Modell.

Die Erklärung: Im lokalen Netzwerk (wenn der Switch nicht gerade eine Firewall hat), kann jeder PC auf jeden Port eines anderen PCs zugreifen - in so einem Fall macht Peer-to-Peer keine Schwierigkeiten (es bedeutet ja eigentlich, dass jeder gleichzeitig Server und Client ist).

Im Internet ist die Sache anders, weil die meisten PCs über einen Router im Internet hängen, der NAT macht. Ich habe z.B. zuhause die IP-Adresse 10.0.0.1, die gilt aber nur für mein lokales Netzwerk - außerhalb habe ich die von meinem Router. Damit hier P2P funktioniert, müsstest du von deinen Usern verlangen, dass sie in ihrer Router-Konfiguration Ports forwarden (d.h. dass der Router eine Verbindung von außerhalb zu einem Computer innerhalb des lokalen Netzwerks zulässt und den Netzwerkverkehr forwardet).
Man kann da glaub ich mit UPnP oder Hole Punching was machen, aber vorsicht: das ist bei mir eher Halbwissen.

Außerdem ist es oft ganz sinnvoll einen Server zu haben. Der kann z.B. anti-cheating mechanismen implementieren. Wenn die Clients miteinander kommunizieren, kann jeder irgendwas behaupten.

sinjin hat Folgendes geschrieben:

Aber ich gehe davon aus, selbst wenn das von 3 Usern sich das auf einmal auf 100000 User erhöhen würde, sich das vom Programm kaum ändern wird

Das ist schwer zu sagen, aber ich denke, dass 100.000 zu hoch gegriffen ist. Es wird sich vermutlich von 3 bis 300 nicht sehr ändern. Mehr als 10.000 Spieler auf einem Server ist heftig (imho). Da führt dann vermutlich an multithreading auch kein Weg mehr vorbei, zumindest glaube ich kaum, dass ein BlitzMax-Server das verkraftet. Und 100.000 wird auch für einen nginx viel, denke ich Very Happy

Bzgl. BlitzMax: ich kann BNetEx sehr empfehlen. Eine Lib für BlitzMax mit der du da glaub ich relativ leicht reinkommst. Die Dokumentation ist gut und es sind Beispiele dabei. Link: https://www.blitzforum.de/foru...hp?t=13569

Wegen Apache: Wenn es ein relativ langsames Spiel ist, oder nur ein Online High-Score, dann kannst du theoretisch die Clients in BlitzMax mit einem Apache-Server reden lassen, der die Server-Angelegenheiten per PHP abwickelt. Du müsstest nur die BlitzMax-Programme auf den Server auf Port 80 richten (jedenfalls auf den wo der Apache läuft). Oder einen anderen HTTP-Server deiner Wahl, weil ich denke dass es bessere gibt.

Ich hoffe die Antwort ist nicht zu durcheinander Confused

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	sinjin	Sa, Mai 21, 2016 8:33 Antworten mit Zitat
Klar ist das viel zu hoch gegriffen Aber danke für den Link, ich werde mich da mal reinlesen.

sinjin

Sa, Mai 21, 2016 8:33
Antworten mit Zitat

Klar ist das viel zu hoch gegriffen Very Happy

Aber danke für den Link, ich werde mich da mal reinlesen.

	DAK	Sa, Mai 21, 2016 22:56 Antworten mit Zitat
Es gibt hald beim Netzwerken ziemlich viele Varianten, Methoden und Entscheidungsmöglichkeiten, die je nach dem was du machen willst, Vor- und Nachteile haben. Willst du schnell mal was hinpfuschen, was halbwegs im LAN funktioniert, dann programmier gleich los. Willst du wirklich was im Internet machen, wo hunderte oder tausende User dranhängen, dann lies dich mal ein. Wichtige Begriffe, nach denen du Wikin solltest wären u.A. Folgende: IP TCP und UDP Delay und Ping NAT In der Theorie macht es keinen Unterschied, ob man lokal an einem Computer über 127.0.0.1 testet, oder über LAN oder Internet spielt. In der Praxis schon. Lokal heißt man hat einen Ping von <1 ms. Jede Nachricht kommt sofort an, alles ist synchron. Auch die Bandbreite ist nur durch die Geschwindigkeit von Prozessor und RAM limitiert, man kann also irre viel Daten pro Sekunde übertragen, ohne das es zu Verzögerungen kommt. Im LAN kriegt man langsam einen schlechteren Ping. Je nach Netzwerkinfrastruktur können hier schon Pings von bis zu 50ms auftreten, im WLAN sogar noch deutlich mehr, wenn der Empfang nicht optimal ist, oder viel Störfunk (z.B. von Mikrowellen oder anderen WLANs) in der Luft ist. Auch ist die Bandbreite hier beschränkt. Im kabelgebundenen LAN sind 100 MBit kein seltenes Limit, im WLAN kommt man oft nur mehr auf effektive 5 MBit. Dazu teilt man sich im WLAN die Bandbreite mit allen anderen Teilnehmern, die irgendein WLAN auf dem gleichen Kanal verwenden. Hier wird es also schon schwieriger. Dadurch, das der Ping größer wird, ist die Verzögerung zwischen Mausklick und Reaktion vom Server schon merkbar. In einem Shooter können 50ms schon dazwischen unterscheiden, ob man einen Gegner trifft oder nicht. Man muss also hier sich schon etwas ausdenken, wie man diese hohe Latenz ausgleicht und vor dem Spieler versteckt. Dazu gibt es ganze Abhandlungen, also schreib ich da jetzt nichts dazu. Allerdings ist die Latenz im LAN meistens gering genug, das man nicht viel (oder gar nichts) machen muss. Dadurch, das die Bandbreite auch geringer ist, muss man auch aufpassen, das man nicht zu viel Daten versendet. Aber das ist hier noch kein großes Problem. Schlimm wird es jetzt, wenn du das Internet betrittst. Je nach Internetzugang sind Pings von mehreren hundert Millisekunden keine Seltenheit mehr. Besonders mobiles Internet aber auch kabelgebundenes Internet kann dir oft Pings von mehreren Sekunden geben. Bei einem schnellen Shooter ist ein Duell in zwei Sekunden vorrüber. So einen langen Ping richtig behandeln ist wirklich schwer. Auch die Bandbreite im Internet ist nicht so hoch. Mit mehr als 10 MBit sollte man hier nicht rechnen, da viele Leute nur so wenig haben. Bei mobilem Internet hat man oft kaum 1 MBit, vor allem in Gebieten mit schlechtem Empfang. Hier muss man sich schon genau überlegen, welches Daten man wie oft verschicken will. Dazu kommt, das es im Internet oft NATs gibt. Die mappen eine globale IP auf viele lokale IPs. Das heißt, das sich mehrere Computer eine Internetverbindung teilen können. Quasi jeder Internetnutzer, der einen Router hat, verwendet NAT. Ein Nebeneffekt von NAT ist, das es die lokalen Computer von außen versteckt. Das heißt, ein Computer im NAT kann eine Verbindung zu einem Computer außerhalb des NATs aufbauen kann, nicht aber anders herum. Als Analogie stell dir vor, ein Mietshaus ohne Gegensprechanlage. Ein Bewohner des Mietshauses kann auf die Straße gehen und jemanden auf der Straße ansprechen, nicht aber anders herum. Das heißt, Peer-To-Peer geht hier nicht, und der Server muss global sichtbar sein. Also mehr Arbeit für das gleiche Ergebnis. Dann noch was zu Peer-To-Peer vs Server-Client: Bei Peer-To-Peer sind nicht nur alle gleichrangig, sondern alle reden mit allen. Bei zwei Clients ist das eine Verbindung, bei 5 sind es 10 Verbindungen und bei 10 Clients brauchst du 45 Verbindungen. Und jeder dieser Clients muss von jedem anderen sichtbar sein, also nicht hinter NATs hängen. Das heißt, mehr als 16 Clients kannst du quasi vergessen und das Internet auch. Alle sind gleichrangig heißt, du kannst keinen sinnvollen Cheatschutz einbauen. Dafür brauchst du keine eigene Serverstruktur. Peer-To-Peer wurde hauptsächlich bei alten Spielen verwendet, gibt es inzwischen aber kaum mehr. Bei Server-Client brauchst du nur eine Verbindung pro Client an den Server. Nur dieser Server muss global sichtbar sein. Diese Architektur hat sich inzwischen beinahe überall durchgesetzt für Spiele.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Sa, Mai 21, 2016 22:56
Antworten mit Zitat

Es gibt hald beim Netzwerken ziemlich viele Varianten, Methoden und Entscheidungsmöglichkeiten, die je nach dem was du machen willst, Vor- und Nachteile haben.

Willst du schnell mal was hinpfuschen, was halbwegs im LAN funktioniert, dann programmier gleich los. Willst du wirklich was im Internet machen, wo hunderte oder tausende User dranhängen, dann lies dich mal ein.

Wichtige Begriffe, nach denen du Wikin solltest wären u.A. Folgende:

IP
TCP und UDP
Delay und Ping
NAT

In der Theorie macht es keinen Unterschied, ob man lokal an einem Computer über 127.0.0.1 testet, oder über LAN oder Internet spielt. In der Praxis schon.

Lokal heißt man hat einen Ping von <1 ms. Jede Nachricht kommt sofort an, alles ist synchron. Auch die Bandbreite ist nur durch die Geschwindigkeit von Prozessor und RAM limitiert, man kann also irre viel Daten pro Sekunde übertragen, ohne das es zu Verzögerungen kommt.

Im LAN kriegt man langsam einen schlechteren Ping. Je nach Netzwerkinfrastruktur können hier schon Pings von bis zu 50ms auftreten, im WLAN sogar noch deutlich mehr, wenn der Empfang nicht optimal ist, oder viel Störfunk (z.B. von Mikrowellen oder anderen WLANs) in der Luft ist. Auch ist die Bandbreite hier beschränkt. Im kabelgebundenen LAN sind 100 MBit kein seltenes Limit, im WLAN kommt man oft nur mehr auf effektive 5 MBit. Dazu teilt man sich im WLAN die Bandbreite mit allen anderen Teilnehmern, die irgendein WLAN auf dem gleichen Kanal verwenden.
Hier wird es also schon schwieriger. Dadurch, das der Ping größer wird, ist die Verzögerung zwischen Mausklick und Reaktion vom Server schon merkbar. In einem Shooter können 50ms schon dazwischen unterscheiden, ob man einen Gegner trifft oder nicht. Man muss also hier sich schon etwas ausdenken, wie man diese hohe Latenz ausgleicht und vor dem Spieler versteckt. Dazu gibt es ganze Abhandlungen, also schreib ich da jetzt nichts dazu. Allerdings ist die Latenz im LAN meistens gering genug, das man nicht viel (oder gar nichts) machen muss.
Dadurch, das die Bandbreite auch geringer ist, muss man auch aufpassen, das man nicht zu viel Daten versendet. Aber das ist hier noch kein großes Problem.

Schlimm wird es jetzt, wenn du das Internet betrittst. Je nach Internetzugang sind Pings von mehreren hundert Millisekunden keine Seltenheit mehr. Besonders mobiles Internet aber auch kabelgebundenes Internet kann dir oft Pings von mehreren Sekunden geben. Bei einem schnellen Shooter ist ein Duell in zwei Sekunden vorrüber. So einen langen Ping richtig behandeln ist wirklich schwer. Auch die Bandbreite im Internet ist nicht so hoch. Mit mehr als 10 MBit sollte man hier nicht rechnen, da viele Leute nur so wenig haben. Bei mobilem Internet hat man oft kaum 1 MBit, vor allem in Gebieten mit schlechtem Empfang.
Hier muss man sich schon genau überlegen, welches Daten man wie oft verschicken will.
Dazu kommt, das es im Internet oft NATs gibt. Die mappen eine globale IP auf viele lokale IPs. Das heißt, das sich mehrere Computer eine Internetverbindung teilen können. Quasi jeder Internetnutzer, der einen Router hat, verwendet NAT. Ein Nebeneffekt von NAT ist, das es die lokalen Computer von außen versteckt. Das heißt, ein Computer im NAT kann eine Verbindung zu einem Computer außerhalb des NATs aufbauen kann, nicht aber anders herum. Als Analogie stell dir vor, ein Mietshaus ohne Gegensprechanlage. Ein Bewohner des Mietshauses kann auf die Straße gehen und jemanden auf der Straße ansprechen, nicht aber anders herum.
Das heißt, Peer-To-Peer geht hier nicht, und der Server muss global sichtbar sein.
Also mehr Arbeit für das gleiche Ergebnis.

Dann noch was zu Peer-To-Peer vs Server-Client:

Bei Peer-To-Peer sind nicht nur alle gleichrangig, sondern alle reden mit allen. Bei zwei Clients ist das eine Verbindung, bei 5 sind es 10 Verbindungen und bei 10 Clients brauchst du 45 Verbindungen. Und jeder dieser Clients muss von jedem anderen sichtbar sein, also nicht hinter NATs hängen. Das heißt, mehr als 16 Clients kannst du quasi vergessen und das Internet auch. Alle sind gleichrangig heißt, du kannst keinen sinnvollen Cheatschutz einbauen.
Dafür brauchst du keine eigene Serverstruktur. Peer-To-Peer wurde hauptsächlich bei alten Spielen verwendet, gibt es inzwischen aber kaum mehr.

Bei Server-Client brauchst du nur eine Verbindung pro Client an den Server. Nur dieser Server muss global sichtbar sein. Diese Architektur hat sich inzwischen beinahe überall durchgesetzt für Spiele.

Gewinner der 6. und der 68. BlitzCodeCompo

	Holzchopf Meisterpacker	Mo, Mai 23, 2016 21:22 Antworten mit Zitat
DAK hat Folgendes geschrieben: Willst du schnell mal was hinpfuschen, was halbwegs im LAN funktioniert, dann programmier gleich los Kann ich nur empfehlen. Der einfachste Einstieg - falls es sowas wie einen einfachen Einstieg in Netzwerkprogrammierung gibt - gelingt meiner Meinung nach über ein rudimentäres Daten-Austausch-Programm. Von mir aus auch in zwei teilen, also so, das ein Programm Server und eines Client-Funktionalität aufweist. Das können irgendwelche Daten sein, auf irgend eine Art. Für Spiele empfiehlt sich natürlich in erster Linie UDP. Dann machst du dir über Dinge wie Latenz und Paketverluste erstmal grad gar keine Gedanken, sonst kommst du nie zu einem befriedigenden (Zwischen-)Ergebnis. Kleiner Anstoss: Versuche ein Programm zu schreiben, dass die Mausposition (im Fenster) an den Server überträgt. Der Server stellt bei sich einfach an der empfangenen Position etwas dar, ein weisser Pixel oder ein Oval. Dann spielst du ein wenig damit und wirst von selber ein Problemchen nach dem anderen entdecken. Aber so hast du wenigstens die Möglichkeit, alles Schritt für Schritt selber zu erarbeiten. mfG Holzchopf edit BNetEx wurde zwar schon erwähnt - ich hoffe auch stark, dass du darauf zurückgreifst. Denn in BMax ist das UDP-Zeug leider nicht mehr so dufte implementiert wie in BlitzBasic. Hatte das völlig vergessen Hier übrigens noch ein kleines Beispielprogramm, das ohne BNetEx läuft. Es soll die absoluten Basics vermitteln BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] SuperStrict Rem ================================================== minimales UDP-Beispiel mit BlitzMax-Sockets Dieses Beispiel behandelt nicht: - wie der Server mehrere Clients gleichzeitig verwalten kann - wie andere Nachrichten-Typen versendet werden können - wie der Server merkt - oder wie der Client es ihm mitteilt - dass ein Client die Verbindung trennt - wie verloren gegangene Nachrichten entdeckt werden können und wie darauf reagiert wird - wie Nachrichten in der falschen Reihenfolge korrekt behandelt werden - dass nicht in jedem Hauptschleifendurchgang Daten verschickt werden sollen (und vor allem: wieso nicht) - Latenz / Ping zwischen Client und Server - und die daraus resultierende Enter- und Extra- polation der Spielerkoordinaten ================================================== End Rem Framework brl.glmax2d Import brl.timer Import brl.basic Import brl.retro ' IP-Adresse vom Server als String, 127.0.0.1 ist localhost Global SERVERADRESS:String = "127.0.0.1" ' Port, auf dem der Server hört Const SERVERPORT:Int = 40404 ' Grösse des UDP-Nachrichten-Buffers ' kann hier relativ klein sein, da eh immer nur ' 2-Int grosse Nachrichten verschickt werden Const UDP_BUFFER_SIZE:Int = 8 ' Stati um Rolle im Netzwerk zu definieren Const ROLE_UNDET:Int = 0 Const ROLE_CLIENT:Int = 1 Const ROLE_SERVER:Int = 2 Global role:Int = ROLE_UNDET ' UDP-Socket, über den die Kommunikation stattfinden wird Global udpsocket:TSocket = CreateUDPSocket() ' UDP-Nachrichten-Buffer Global udpbuffer:Int Ptr = Int Ptr(MemAlloc(UDP_BUFFER_SIZE)) ' "remote" IP und Port Global remip:Int, remport:Int ' Framerate-Grenze Global timer:TTimer = CreateTimer(50) ' Mausposition und die des Gegenübers Global mx:Int, my:Int Global ox:Int, oy:Int '------------------------------------------------- ' versuche, den Server-Port anzubinden If udpsocket.Bind(SERVERPORT) Then ' wenn dies klappt, fungiert das Programm als Server role = ROLE_SERVER Print "role: server" AppTitle = "UDP mouse copy SERVER" ' wenn es nicht geklappt hat, ' wird ein beliebiger Port angebunden ElseIf udpsocket.Bind(0) Then ' und dann fungiert das Programm als Client role = ROLE_CLIENT Print "role: client" AppTitle = "UDP mouse copy CLIENT" ' Gegenüber-IP und Port sind bereits bekannt remip = HostIp(SERVERADRESS) remport = SERVERPORT Else End EndIf '------------------------------------------------- Graphics(800,600) ' Hauptschleife While Not AppTerminate() ' empfange UDP-Nachrichten Local rec:Int ' ganz wichtig: nicht If sonder While verwenden, ' weil mehrere Nachrichten gleichzeitig ankommen können ' Also: Während UDP-Daten da sind, auslesen While udpsocket.ReadAvail() ' empfangen der UDP-Nachricht in den UDP-Nachrichten-Buffer, ' in remip und remport wird der Absender gespeichert Rem recvfrom_(socket, buf:Byte Ptr, size, flags, sender_ip Var, sender_port Var) https://msdn.microsoft.com/en-us/library/windows/desktop/ms740120(v=vs.85).aspx End Rem rec = recvfrom_(udpsocket._socket, udpbuffer, UDP_BUFFER_SIZE, 0, remip, remport) ' wenn Daten gelesen werden konnten If rec > 0 Then ' debug-Ausgabe WriteStdout DottedIP(remip) +":" +remport +" > " ' byte-weise Ausgabe der Nachricht Local bptbuff:Byte Ptr = Byte Ptr(udpbuffer) For Local i:Int = 0 Until rec WriteStdout Right(Hex(bptbuff[i]), 2) +" " Next Print " (" +rec +" byte)" ' Nachricht auswerten (Position aus Buffer lesen) If rec = 8 Then ox = udpbuffer[0] oy = udpbuffer[1] EndIf EndIf Wend ' Mausposition holen mx = MouseX() my = MouseY() ' wenn remip gesetzt ist (geschieht beim Server, wenn eine ' Nachricht empfangen wird), wird die Mausposition an ' diese Adresse geschickt If remip <> 0 Then ' Position in Buffer schreiben udpbuffer[0] = mx udpbuffer[1] = my ' senden der UDP-Nachricht an die definierte Adresse Rem Function sendto_(socket, buf:Byte Ptr, size, flags, dest_ip, dest_port) https://msdn.microsoft.com/en-us/library/windows/desktop/ms740148(v=vs.85).aspx End Rem sendto_(udpsocket._socket, udpbuffer, 8, 0, remip, remport) EndIf ' Ausgabe der Positionen Cls SetColor(255,255,255) DrawOval(mx-5,my-5, 11,11) SetColor(255,0,0) DrawOval(ox-5,oy-5, 11,11) Flip 0 WaitTimer(timer) Wend Ich empfehle, das Programm einmal aus der IDE heraus zu starten und einmal die .exe aus dem Explorer heraus. So siehst du die Debug-Nachrichten vom Server.

Holzchopf

Meisterpacker

Mo, Mai 23, 2016 21:22
Antworten mit Zitat

DAK hat Folgendes geschrieben:

Willst du schnell mal was hinpfuschen, was halbwegs im LAN funktioniert, dann programmier gleich los

Kann ich nur empfehlen.

Der einfachste Einstieg - falls es sowas wie einen einfachen Einstieg in Netzwerkprogrammierung gibt - gelingt meiner Meinung nach über ein rudimentäres Daten-Austausch-Programm. Von mir aus auch in zwei teilen, also so, das ein Programm Server und eines Client-Funktionalität aufweist. Das können irgendwelche Daten sein, auf irgend eine Art. Für Spiele empfiehlt sich natürlich in erster Linie UDP. Dann machst du dir über Dinge wie Latenz und Paketverluste erstmal grad gar keine Gedanken, sonst kommst du nie zu einem befriedigenden (Zwischen-)Ergebnis.

Kleiner Anstoss: Versuche ein Programm zu schreiben, dass die Mausposition (im Fenster) an den Server überträgt. Der Server stellt bei sich einfach an der empfangenen Position etwas dar, ein weisser Pixel oder ein Oval. Dann spielst du ein wenig damit und wirst von selber ein Problemchen nach dem anderen entdecken. Aber so hast du wenigstens die Möglichkeit, alles Schritt für Schritt selber zu erarbeiten.

mfG
Holzchopf

edit
BNetEx wurde zwar schon erwähnt - ich hoffe auch stark, dass du darauf zurückgreifst. Denn in BMax ist das UDP-Zeug leider nicht mehr so dufte implementiert wie in BlitzBasic. Hatte das völlig vergessen Embarassed

Hier übrigens noch ein kleines Beispielprogramm, das ohne BNetEx läuft. Es soll die absoluten Basics vermitteln BlitzMax: [AUSKLAPPEN]

SuperStrict

Rem
==================================================

minimales UDP-Beispiel mit BlitzMax-Sockets

Dieses Beispiel behandelt nicht:
- wie der Server mehrere Clients gleichzeitig
  verwalten kann
- wie andere Nachrichten-Typen versendet werden
  können
- wie der Server merkt - oder wie der Client es
  ihm mitteilt - dass ein Client die Verbindung
  trennt
- wie verloren gegangene Nachrichten entdeckt
  werden können und wie darauf reagiert wird
- wie Nachrichten in der falschen Reihenfolge
  korrekt behandelt werden
- dass nicht in jedem Hauptschleifendurchgang
  Daten verschickt werden sollen (und vor allem:
  wieso nicht)
- Latenz / Ping zwischen Client und Server
- und die daraus resultierende Enter- und Extra-
  polation der Spielerkoordinaten

==================================================
End Rem

Framework brl.glmax2d
Import brl.timer
Import brl.basic
Import brl.retro

' IP-Adresse vom Server als String, 127.0.0.1 ist localhost
Global SERVERADRESS:String	 = "127.0.0.1"
' Port, auf dem der Server hört
Const SERVERPORT:Int	= 40404

' Grösse des UDP-Nachrichten-Buffers
' kann hier relativ klein sein, da eh immer nur
' 2-Int grosse Nachrichten verschickt werden
Const UDP_BUFFER_SIZE:Int	= 8

' Stati um Rolle im Netzwerk zu definieren
Const ROLE_UNDET:Int	= 0
Const ROLE_CLIENT:Int	= 1
Const ROLE_SERVER:Int	= 2
Global role:Int = ROLE_UNDET

' UDP-Socket, über den die Kommunikation stattfinden wird
Global udpsocket:TSocket = CreateUDPSocket()
' UDP-Nachrichten-Buffer
Global udpbuffer:Int Ptr = Int Ptr(MemAlloc(UDP_BUFFER_SIZE))
' "remote" IP und Port
Global remip:Int, remport:Int

' Framerate-Grenze
Global timer:TTimer = CreateTimer(50)
' Mausposition und die des Gegenübers
Global mx:Int, my:Int
Global ox:Int, oy:Int

'-------------------------------------------------

' versuche, den Server-Port anzubinden
If udpsocket.Bind(SERVERPORT) Then
	' wenn dies klappt, fungiert das Programm als Server
	role = ROLE_SERVER
	Print "role: server"
	AppTitle = "UDP mouse copy SERVER"
' wenn es nicht geklappt hat,
' wird ein beliebiger Port angebunden
ElseIf udpsocket.Bind(0) Then
	' und dann fungiert das Programm als Client
	role = ROLE_CLIENT
	Print "role: client"
	AppTitle = "UDP mouse copy CLIENT"
	' Gegenüber-IP und Port sind bereits bekannt
	remip = HostIp(SERVERADRESS)
	remport = SERVERPORT
Else
	End
EndIf

'-------------------------------------------------

Graphics(800,600)

' Hauptschleife
While Not AppTerminate()
	' empfange UDP-Nachrichten
	Local rec:Int
	' ganz wichtig: nicht If sonder While verwenden,
	' weil mehrere Nachrichten gleichzeitig ankommen können
	' Also: Während UDP-Daten da sind, auslesen
	While udpsocket.ReadAvail()
		' empfangen der UDP-Nachricht in den UDP-Nachrichten-Buffer,
		' in remip und remport wird der Absender gespeichert
Rem
recvfrom_(socket, buf:Byte Ptr, size, flags, sender_ip Var, sender_port Var)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740120(v=vs.85).aspx	
End Rem
		rec = recvfrom_(udpsocket._socket, udpbuffer, UDP_BUFFER_SIZE, 0, remip, remport)
	
		' wenn Daten gelesen werden konnten
		If rec > 0 Then
			' debug-Ausgabe
			WriteStdout DottedIP(remip) +":" +remport +" > "
			' byte-weise Ausgabe der Nachricht
			Local bptbuff:Byte Ptr = Byte Ptr(udpbuffer)
			For Local i:Int = 0 Until rec
				WriteStdout Right(Hex(bptbuff[i]), 2) +" "
			Next
			Print " (" +rec +" byte)"
			' Nachricht auswerten (Position aus Buffer lesen)
			If rec = 8 Then
				ox = udpbuffer[0]
				oy = udpbuffer[1]
			EndIf
		EndIf
	Wend

	' Mausposition holen
	mx = MouseX()
	my = MouseY()
	
	' wenn remip gesetzt ist (geschieht beim Server, wenn eine
	' Nachricht empfangen wird), wird die Mausposition an
	' diese Adresse geschickt
	If remip <> 0 Then
		' Position in Buffer schreiben
		udpbuffer[0] = mx
		udpbuffer[1] = my
		' senden der UDP-Nachricht an die definierte Adresse
Rem
Function sendto_(socket, buf:Byte Ptr, size, flags, dest_ip, dest_port)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms740148(v=vs.85).aspx
End Rem
		sendto_(udpsocket._socket, udpbuffer, 8, 0, remip, remport)
	EndIf

	' Ausgabe der Positionen
	Cls
	
	SetColor(255,255,255)
	DrawOval(mx-5,my-5, 11,11)
	SetColor(255,0,0)
	DrawOval(ox-5,oy-5, 11,11)
	
	Flip 0
	WaitTimer(timer)
Wend

Ich empfehle, das Programm einmal aus der IDE heraus zu starten und einmal die .exe aus dem Explorer heraus. So siehst du die Debug-Nachrichten vom Server.

	sinjin	Do, Mai 26, 2016 16:57 Antworten mit Zitat
Vielen Dank für den Hinweis. Ja, ich habe mir den kompletten Thread, den Thunder gepostet hatte, durchgelesen und direkt das BnetEx Modul (ist die 1.8) runtergeladen, habe es mir bisher aber noch nicht angeschaut aus Zeit- und Lustgründen.... Wenn ich mal wieder ein grösseres Projekt starte, werde ich aber versuchen das gleich mit zu implementieren. Schönen Gruß

sinjin

Do, Mai 26, 2016 16:57
Antworten mit Zitat

Vielen Dank für den Hinweis. Ja, ich habe mir den kompletten Thread, den Thunder gepostet hatte, durchgelesen und direkt das BnetEx Modul (ist die 1.8) runtergeladen, habe es mir bisher aber noch nicht angeschaut aus Zeit- und Lustgründen.... Wenn ich mal wieder ein grösseres Projekt starte, werde ich aber versuchen das gleich mit zu implementieren.
Schönen Gruß

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Internet Programmierung ohne Internet?

Betreff: Internet Programmierung ohne Internet?