UDP
Übersicht

RubberBetreff: UDP |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Hi,
ich hab mal ne Frage zu CreateUDPStream() wenn ich keinen Port angebe sucht sich das programm ja selbst einen ... aber wie kann ich ermitteln, welcher das ist? danke schonmal |
||
![]() |
TimBo |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hi,
CreateUDPStream ![]() Zitat aus Hilfe: Zitat: Dieser Befehl erstellt eine UDP-Netzwerkverbindung. Die Portnummer kann angegeben werden. Falls es weggelassen wurde, dann sucht BlitzBasic nach einem freien Port. Die Nummer des Ports kann mit UDPStreamPort ermittelt werden.
aber dann schaut man mal nach vorne: UDPStreamPort Liefert die Port-Adresse einer UDP-Message (nicht aktivierter Befehl) dieser Befehl ist wohl nicht aktiviert , also wohl garnicht ![]() Viele Grüße TimBo |
||
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10
Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht. |
![]() |
Thorsten |
![]() Antworten mit Zitat ![]() |
---|---|---|
//Edit : okay es gibt keine Funktion den eigenen Port rauszufinden.
Du musst also der Gegenseite eine Nachricht senden, und die gibt dir dann den Port mithilfe von UDPMsgPort ![]() mfG, Thorsten |
||
![]() |
TimBo |
![]() Antworten mit Zitat ![]() |
---|---|---|
das wäre eine sehr gute Möglichkeit. Warum brauchst du denn den Port, den du benutzt um rauszusenden ?
Ich würde sowieso immer einen konstanten Port machen, sonst müsste man immer das Portforwarding ändern. Ich habe zwar hier eine Funktionssammlung, die den Port von einem Router umgeht, aber ich muss sie noch mit anderen PC's testen. Viele Grüße TimBo |
||
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10
Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht. |
Rubber |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Eigentlich wollte ich zu Test-Zwecken das Programm auf meinem PC mehrmals laufen lassen.
Deshalb halt am liebsten mit "variablen-Ports" ... aber gut... dann leg ich sie halt fest udn muss bei jedem test-programm nen andern port nehmen. danke |
||
![]() |
TimBo |
![]() Antworten mit Zitat ![]() |
---|---|---|
bleibt dir wohl leider nichts anderes über . Ich mach das auch so . | ||
mfg Tim Borowski // CPU: Ryzen 2700x GPU: Nvidia RTX 2070 OC (Gigabyte) Ram: 16GB DDR4 @ 3000MHz OS: Windows 10
Stolzer Gewinner des BCC 25 & BCC 31 hat einen ersten Preis in der 1. Runde beim BWInf 2010/2011 & 2011/12 mit BlitzBasic erreicht. |
![]() |
Tankbuster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Ehm.... Ich sehe irgendwie keinen Sinn darin, seinen eigenen Port zu wissen.
Könnte mir jemand mal ein Beispiel geben, wofür man das brauchen könnte? Vielleicht bin ich ja einfach nicht kreativ genug.... ![]() |
||
Twitter
Download Jewel Snake! Windows|Android |
Rubber |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
also ich hätte den "empfangs-port" gerne automatisch wählen lassen und dann diesen port an den server senden, dort mit der ip speichern und zum kommunizierne nutzen.
weil der server kommt ja nur an den "sende-port" -> es macht sinn den eigenen port zu wissen um diesen dem server mitzuteilen. ein wenig so, als würdest du mcih fragen, obc ih meine hausnummer kennen muss. nö - nur dmait ich sie jemandem sagen kann, damit er mcih findet. |
||
Wenn Gott mich schon liebt, dann dich erstrecht... |
![]() |
HolzchopfMeisterpacker |
![]() Antworten mit Zitat ![]() |
---|---|---|
Es reicht durchaus, nur einen Stream zu haben, der fürs Senden und Empfangen gebraucht werden kann. Ist sogar vorzuziehen:
1. Ist dann Sende-Port = Empfangs-Port und der Server schickt einfach an diesen zurück 2. Weiss dann der Router beim Clienten bestimmt auch, wohin er die einkommende Nachricht weiterleiten muss. mfG |
||
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm |
![]() |
Tankbuster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Zitat: weil der server kommt ja nur an den "sende-port"
-> es macht sinn den eigenen port zu wissen um diesen dem server mitzuteilen. ein wenig so, als würdest du mcih fragen, obc ih meine hausnummer kennen muss. nö - nur dmait ich sie jemandem sagen kann, damit er mcih findet. Aber wenn du jemandem einen Brief mit Absender schickst, dann weiß er, wohin er zurückschreiben muss. Und UDPMsgPort ![]() ![]() |
||
Twitter
Download Jewel Snake! Windows|Android |
BIG BUG |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Genau genommen MUSS man beim Host sogar UDPMsgPort(und auch UDPMsgIP) verwenden um überhaupt feststellen zu können von welchem Port das Paket kam, da sich dieser mit hoher Wahrscheinlichkeit geändert hat. An diesen Port muss dann natürlich auch zurück gesendet werden...
Ein "Stream" pro Instanz ist nicht nur ausreichend, sondern schlicht die einzig vernünftige Lösung. Hintergrund ist wie Holzchopf schon angedeutet hat, dass sich Router und Firewalls merken, von welchem Port ein Paket abgesendet wurde und etwaige Antworten genau an diese IP/Port hinrouten bzw. diesen offen halten. Auf diese Weise muss nur der Host seinen Router richtig konfiguriert haben. Hierfür muss natürlich der genutzte Port bekannt und fest definiert sein, sonst wissen die Clients ja nicht wohin sie connecten müssen. -> Host - Port fest vorgeben -> Clients - Port automatisch festlegen Generell unterscheidet man zwischen "Server - Client" und einer sog. "Peer to Peer" Architektur. Mit UDP geht beides (bei TCP macht nur Server - Client Sinn) Server - Client: Die IP-Adresse inkl. Port des Servers muss bekannt sein. Der Server merkt sich dann von jedem ankommenden Spieler(Client) mittels UDPMsgIP und UDPMsgPort die Verbindungsdaten und schickt hier auch seine Nachrichten zurück. Alle Clienten schicken ihre Daten ausschließlich an den Server und bekommen auch nur vom Server Daten zurück. Der Server routet dann die Daten ggf. an die anderen Clienten weiter. Diese Logik ist für Internet-Spiele sinnvoll, da hier nur die Server Ports konfiguriert werden müssen. Die meiste Netzlast hat dann natürlich der Server zu verkraften, die Clients können ggf. reduzierte Paket erhalten. Der Server bildet den einzig gültigen Spielstand ab und hat somit immer recht. Somit kann ein Spiel leicht synchron gehalten und mit entsprechenden Prüfungen auch Cheats vorgebeugt werden. Eine Schließung des Servers bedeutet, dass das Spiel abgebrochen wird. Peer to Peer: Hier spricht man nicht von einem Server, sondern von einem Host. Die IP-Adresse inkl. Port des Hosts muss bekannt sein. Der Host merkt sich dann von jedem neuen Spieler mittels UDPMsgIP und UDPMsgPort die Verbindungsdaten und leitet diese dann an alle anderen Spieler weiter. Jeder Spieler ist ein Client(oder auch Peer), inklusive Host und kommuniziert selbst mit allen anderen Clienten. Der Host hat also nur die Aufgabe, die Spieleinstellungen zu verwalten und eben Ansprechpartner für neue Verbindungen zu dienen. Prinzipiell könnte man aber auch auf jeden beliebigen Client joinen um in das Spiel einzusteigen. Der Client muss nur den neuen Spieler allen anderen bekannt geben. Diese Logik ist für LAN Spiele sinnvoll, da hier die Netzlast gleichmäßig verteilt wird und im Gegensatz zu einer Server - Client Logik kein Spieler bevorzugt behandelt wird. Allerdings gibt es keinen Referenzspielstand, sondern jeder Client hat seinen eigenen. Dadurch wird die Synchronisation und Verhinderung von Cheats schwieriger. Wird der Host geschlossen, kann ein anderer Spieler als Host fungieren, das Spiel muss nicht abgebrochen werden. Der Begriff "Stream" in Zusammenhang mit UDP ist übrigens reiner Blitzbasic Sprachgebrauch, da das Auslesen eines Pakets ja auch mit den Stream-Befehlen erfolgt. Einen echten Stream gibt es nur bei TCP. Bei UDP hingegen werden nur einzelne, unabhängige Pakete, sog. Datagramme durch die Weltgeschichte geschickt. Daher auch der Name: User Datagram Protocol Ich glaube jemand sollte mal ein kleines UDP-Tutorial "UDP, so geht es richtig" machen. Das Rob-Tutorial ist hier ja nicht so der Brüller. |
||
B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final) |
Rubber |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Tankbuster hat Folgendes geschrieben: Aber wenn du jemandem einen Brief mit Absender schickst, dann weiß er, wohin er zurückschreiben muss. Und UDPMsgPort ![]() ![]() ja ... aber was bringt mir der sende port? der server muss doch an den empfangsport antworten ... BIG BUG hat Folgendes geschrieben: Genau genommen MUSS man beim Host sogar UDPMsgPort(und auch UDPMsgIP) verwenden um überhaupt feststellen zu können von welchem Port das Paket kam, da sich dieser mit hoher Wahrscheinlichkeit geändert hat. An diesen Port muss dann natürlich auch zurück gesendet werden... hm... wieso muss an den sende port geantwortet werden? hab cih da was falsch verstanden? soweit ich weis, ist es doch nötig einen stream zum senden dun einen zum empfangen zu haben ... aber ... moment ... gedanke: muss jeder stream einen eigenen port haben? wobei. selbst wenn nicht. dann muss ich ja immernoch den port festlegen, weil sonst wird der sende stream einen anderen ahben als der empfangsstream. oder? (ok - jetzt bin ich glaub cih gerade etwas durcheinander) |
||
Wenn Gott mich schon liebt, dann dich erstrecht... |
![]() |
Tankbuster |
![]() Antworten mit Zitat ![]() |
---|---|---|
Zitat: wieso muss an den sende port geantwortet werden?
Weil man normalerweise auf einem Port sendet UND empfängt. 2 Ports ist schwerer zu verwalten, darum nimmt man eigentlich immernur einen. Außerdem wartet die Firewall sowieso noch auf eine Antwort zu diesem Port, daher passt das auch ganz gut. So muss nur der Server seine Ports öffnen. Edit: Zitat: P2P: Hier spricht man nicht von einem Server, sondern von einem Host. Die IP-Adresse inkl. Port des Hosts muss bekannt sein. Der Host merkt sich dann von jedem neuen Spieler mittels UDPMsgIP und UDPMsgPort die Verbindungsdaten und leitet diese dann an alle anderen Spieler weiter. Jeder Spieler ist ein Client(oder auch Peer), inklusive Host und kommuniziert selbst mit allen anderen Clienten. Der Host hat also nur die Aufgabe, die Spieleinstellungen zu verwalten und eben Ansprechpartner für neue Verbindungen zu dienen. Prinzipiell könnte man aber auch auf jeden beliebigen Client joinen um in das Spiel einzusteigen. Der Client muss nur den neuen Spieler allen anderen bekannt geben. Das ist nur ein beispiel für P2P, bei dem es einen zentralen Server gibt, der die Verbindungsdaten den Clienten zurückschickt, damit diese eine Verbindung aufbauen können. Dann gibt es aber noch dezentrale Netzwerke, in denen jeder Client auch gleichzeitig Host ist. Dann erreichen sich die Clienten mittels Broadcast, oder ähnlichen Mitteln. Das ist sinnvoll, weil es ohne Server funktioniert, und dadurch kann z.B. nicht so leicht überwacht werden, wer mit wem eine Verbindung aufbaut. |
||
Twitter
Download Jewel Snake! Windows|Android |
Rubber |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Tankbuster hat Folgendes geschrieben: Weil man normalerweise auf einem Port sendet UND empfängt. 2 Ports ist schwerer zu verwalten, darum nimmt man eigentlich immernur einen. Außerdem wartet die Firewall sowieso noch auf eine Antwort zu diesem Port, daher passt das auch ganz gut. So muss nur der Server seine Ports öffnen.
ok - ich ging bisher davon aus, das man für jeden stream einen extra port braucht Robs Tut hat Folgendes geschrieben: ;Die Streams erstellen
sende_stream = CreateUDPStream(8001) empfangs_stream = CreateUDPStream(8000) wenn dem aber nicht so ist finde ich BIG BUGs idee echt gut BIG BUG hat Folgendes geschrieben: Ich glaube jemand sollte mal ein kleines UDP-Tutorial "UDP, so geht es richtig" machen. Das Rob-Tutorial ist hier ja nicht so der Brüller.
|
||
Wenn Gott mich schon liebt, dann dich erstrecht... |
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group