Warum geht das bei CSS aber bei meinem Blitzprog nicht ?

Übersicht

BlitzBasic

Allgemein

	flashmaxel Betreff: Warum geht das bei CSS aber bei meinem Blitzprog nicht ?	Do, Jul 06, 2006 21:36 Antworten mit Zitat
Erstmal Hallo ! ... ...Und dann das Problem, Ich habe einen UDP-Server geschrieben. Wenn jetzt ein Client connecten will sendet dieser eine Anfrage. Der Server schickt dem Client dann einen Port als Integer zu - über UDP. Diese Nachricht wird an den Port des Clients geschickt wo auch die anfrage herkam ! Jetzt ist es leider so das wenn ich der Client bin meinen Routerport forwarden muss, damit die Nachricht des Servers auch wieder zu meinem PC kommt. Eigentlich absolut verständlich das es nicht ohne das geht ! Das blöde ist bloß das die meisten (auch viele meiner Freunde) einfach nur zocken und keinen schimmer vom Portforwaden oder freischalten haben ... . Was ich jetzt nicht verstehe ,dass ich(und meine Freunde) bei Counterstrike Source um im Internet zu spielen keine Ports freischalten/forwaden musste(n). Ich weiß auch das neuere Router speichern von welcher internen IP sie eine Nachricht gesendet haben und bei einkommender Nachricht automatisch an den richtigen PC weiterleiten. Bloß warum geht das bei CSS und bei Blitz nicht ? Gibts da irgendeinen Trick ? Wenn mir da irgendjemand sagen könnte warum das so ist oder ob Valve zaubern kann wäre ich ihm sehr verbunden Max
Real C programmers never die; they cast to void.

flashmaxel

Betreff: Warum geht das bei CSS aber bei meinem Blitzprog nicht ?

Do, Jul 06, 2006 21:36
Antworten mit Zitat

Erstmal Hallo ! ...

...Und dann das Problem,
Ich habe einen UDP-Server geschrieben. Wenn jetzt ein Client connecten will sendet dieser eine Anfrage. Der Server schickt dem Client dann einen Port als Integer zu - über UDP. Diese Nachricht wird an den Port des Clients geschickt wo auch die anfrage herkam ! Jetzt ist es leider so das wenn ich der Client bin meinen Routerport forwarden muss, damit die Nachricht des Servers auch wieder zu meinem PC kommt.
Eigentlich absolut verständlich das es nicht ohne das geht ! Das blöde ist bloß das die meisten (auch viele meiner Freunde) einfach nur zocken und keinen schimmer vom Portforwaden oder freischalten haben ... .
Was ich jetzt nicht verstehe ,dass ich(und meine Freunde) bei Counterstrike Source um im Internet zu spielen keine Ports freischalten/forwaden musste(n). Question

Ich weiß auch das neuere Router speichern von welcher internen IP sie eine Nachricht gesendet haben und bei einkommender Nachricht automatisch an den richtigen PC weiterleiten.
Bloß warum geht das bei CSS und bei Blitz nicht ? Gibts da irgendeinen Trick ?

Wenn mir da irgendjemand sagen könnte warum das so ist oder ob Valve zaubern kann wäre ich ihm sehr verbunden Very Happy

Max

Real C programmers never die; they cast to void.

	Hummelpups	Fr, Jul 07, 2006 0:25 Antworten mit Zitat
Also erst mal: Es reicht wenn du die Ports eine Short versendest, also nur die Hälfte an Bytes. Nun ist das Problem bei servern: Wenn deine Kollegen einen Server Kontaktieren, senden sie dazu eine Nachricht von Innen nach Außen. Das merkt sich der Router, von welcher IP das Paket kam mit Source und Destination Port. Sendet einer der CS Server nun ein Paket zurück an die Router IP Adresse, sieht der Router, aha, das Paket soll an die und die Port Addresse. Er kann nun also via NAT erkennen, zu welcher IP Adresse das Paket hingeroutet werden soll. Ist es anders rum. Du erstellst einen Server und hast keinen Netzwerkverkehr, und ein Client versucht Port 1337 von außen auf deinem Rechner zu erreichen, weiß der Router nicht, wo er das Paket weiter routen soll. Dafür braucht er das Forwarding indem dann steht, das alle Anfragen, TCP an Port 1337 an Eth0/0 weiter geleitet werden soll. Darum brauchst du als ServerApp ein Forwarding das CLienten auf deinen Server zugreifen können und deine Kumpels nicht weil der Router des CS Spieler das Forwarding mit NAT aktiviert hat. IMurDOOM
blucode - webdesign - Ressource - NetzwerkSim BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

Hummelpups

Fr, Jul 07, 2006 0:25
Antworten mit Zitat

Also erst mal: Es reicht wenn du die Ports eine Short versendest, also
nur die Hälfte an Bytes.

Nun ist das Problem bei servern: Wenn deine Kollegen einen Server Kontaktieren,
senden sie dazu eine Nachricht von Innen nach Außen. Das merkt sich der
Router, von welcher IP das Paket kam mit Source und Destination Port.

Sendet einer der CS Server nun ein Paket zurück an die Router IP Adresse,
sieht der Router, aha, das Paket soll an die und die Port Addresse.
Er kann nun also via NAT erkennen, zu welcher IP Adresse das Paket
hingeroutet werden soll.

Ist es anders rum. Du erstellst einen Server und hast keinen Netzwerkverkehr,
und ein Client versucht Port 1337 von außen auf deinem Rechner zu erreichen,
weiß der Router nicht, wo er das Paket weiter routen soll. Dafür braucht
er das Forwarding indem dann steht, das alle Anfragen, TCP an Port 1337
an Eth0/0 weiter geleitet werden soll.

Darum brauchst du als ServerApp ein Forwarding das CLienten auf deinen
Server zugreifen können und deine Kumpels nicht weil der Router
des CS Spieler das Forwarding mit NAT aktiviert hat.

IMurDOOM

blucode - webdesign - Ressource - NetzwerkSim
BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

	Jolinah	Fr, Jul 07, 2006 8:30 Antworten mit Zitat
Hat dein Server auch einen festen Port, oder benutzt du irgendwie mehrere? Oder wozu sendest du den Port zum Clienten? In der Regel hat der Server nämlich einen festen Port, und der Client kennt diesen Port schon von Beginn an. Du sendest nun mit dem Client direkt an diesen Port und der Server antwortet einfach. So müsste das auch ohne Port Forwarding klappen (beim Clienten, beim Server braucht es dieses Port Forwarding, wie IMurDOOM schon sagte)

Jolinah

Fr, Jul 07, 2006 8:30
Antworten mit Zitat

Hat dein Server auch einen festen Port, oder benutzt du irgendwie mehrere? Oder wozu sendest du den Port zum Clienten?

In der Regel hat der Server nämlich einen festen Port, und der Client kennt diesen Port schon von Beginn an. Du sendest nun mit dem Client direkt an diesen Port und der Server antwortet einfach. So müsste das auch ohne Port Forwarding klappen (beim Clienten, beim Server braucht es dieses Port Forwarding, wie IMurDOOM schon sagte)

	flashmaxel	Sa, Jul 08, 2006 0:38 Antworten mit Zitat
Erstmal Danke für die Antworten IMurDOOM und Jolinah ! So wie IMurDOOM das erklärt hat hab ich mir das auch ungefähr gedacht und mein Server hat auch feste Ports und ist geforwardet ... Der Server Antwortet auf anfrage eines Clienten indem er ihm eine Nachricht an den ClientPort schickt wo die Anfrage herkam. Allerdings passiert eben genau das nicht - das NAT das wieder an den richtigen PC leitet !? Deswegen hab ich als erstes gedacht das läge am Router aber das kann nicht sein weil es ja bei CSS funktioniert. Ich bin leider immernoch ratlos woran das liegen könnte, hat jemand von euch schonmal sowas mit UDP gemacht und hat es bei dem Client ohne forwaden funktioniert ? Würde mich weiterhin über jegliche Ratschläge freuen ! Max
Real C programmers never die; they cast to void.

flashmaxel

Sa, Jul 08, 2006 0:38
Antworten mit Zitat

Erstmal Danke für die Antworten IMurDOOM und Jolinah !

So wie IMurDOOM das erklärt hat hab ich mir das auch ungefähr gedacht und mein Server hat auch feste Ports und ist geforwardet ...
Der Server Antwortet auf anfrage eines Clienten indem er ihm eine Nachricht an den ClientPort schickt wo die Anfrage herkam. Allerdings passiert eben genau das nicht - das NAT das wieder an den richtigen PC leitet !?
Deswegen hab ich als erstes gedacht das läge am Router aber das kann nicht sein weil es ja bei CSS funktioniert.

Ich bin leider immernoch ratlos woran das liegen könnte, hat jemand von euch
schonmal sowas mit UDP gemacht und hat es bei dem Client ohne forwaden funktioniert ? Würde mich weiterhin über jegliche Ratschläge freuen !

Max

Real C programmers never die; they cast to void.

	Nox	Sa, Jul 08, 2006 1:29 Antworten mit Zitat
Hi Flashmaxel. Da du UDP als Protokoll verwendest, gibt's einige Schwierigkeiten, was NAT betrifft: UDP ist verbindungslos, d.h. dein Router merkt sich NICHT, von wo was kam und wohin es ging, um ein Antwortpaket dann entsprechend korrekt zu dir zustellen zu können. Beim Öffnen einer UDP- oder TCP-Verbindung (d.h. beim Erstellen und Konnektieren eines Sockets) bekommt der entspr. Socket den Zielport und Quellport zugewiesen. Beim Zielport handelt es sich um den Serverport und beim Quellport um einen (sofern nicht anders festgelegt) willkürlich gewählten. UDP gibz aber keinen fest definierten DAtentransfer vor. D.h. der Programmierer muss Sorge tragen, wie Daten vom Server wieder zurück zum Client gelangen. Dazu teilt vorher der Client i.d.R. dem Server mit, unter welchem Port er dies zu tun hat - genau so, wie du es momentan implementiert hast. Da aber genau diese Vorhaben nicht vorher ersichtlich ist, wird dein Router UDP-Pakete ohne feste Regeln nicht durchrouten können. Anders ist das bei TCP. Wird damit eine Verbindung initiiert, sind von Vorneherein alle Quell- und Zieldaten bekannt und werden während der Verbindung auch ausschließlich genutzt. Das kann der Router wissen und ist deshalb auch im Stande, zurückkommende Pakete einer vom Client aufgebauten Verbindung richtig durchzurouten. Wie das nun bei CS:S funktioniert, kann ich nur erahnen: Ich tippe mal, dass der Client einen UDP-Stream zum Server offen hat, der für Positionsupdates usw. genutzt wird. Parallel allerdings existiert eine TCP-Verbindung, über die dann die einzig relevanten Daten über die Leitung gehen. Nämliche tatsächlich wichtige Positionsupdates anderer Spieler usw. Wie du siehst, existiert der UDP-Stream nur einseitig, also Client->Server. Der TCP-Stream allerdings wird beidseitig genutzt, auch wenn nur der Client ihn aufgebaut hat. Hoffe, ich konnt's einigermaßen gut rüberbringen. Und bitte keine Gewähr auf die CS:S-Geschichte, ich kann's mir nur so vorstellen.

Nox

Sa, Jul 08, 2006 1:29
Antworten mit Zitat

Hi Flashmaxel.
Da du UDP als Protokoll verwendest, gibt's einige Schwierigkeiten, was NAT betrifft: UDP ist verbindungslos, d.h. dein Router merkt sich NICHT, von wo was kam und wohin es ging, um ein Antwortpaket dann entsprechend korrekt zu dir zustellen zu können.
Beim Öffnen einer UDP- oder TCP-Verbindung (d.h. beim Erstellen und Konnektieren eines Sockets) bekommt der entspr. Socket den Zielport und Quellport zugewiesen. Beim Zielport handelt es sich um den Serverport und beim Quellport um einen (sofern nicht anders festgelegt) willkürlich gewählten. UDP gibz aber keinen fest definierten DAtentransfer vor. D.h. der Programmierer muss Sorge tragen, wie Daten vom Server wieder zurück zum Client gelangen. Dazu teilt vorher der Client i.d.R. dem Server mit, unter welchem Port er dies zu tun hat - genau so, wie du es momentan implementiert hast. Da aber genau diese Vorhaben nicht vorher ersichtlich ist, wird dein Router UDP-Pakete ohne feste Regeln nicht durchrouten können.
Anders ist das bei TCP. Wird damit eine Verbindung initiiert, sind von Vorneherein alle Quell- und Zieldaten bekannt und werden während der Verbindung auch ausschließlich genutzt. Das kann der Router wissen und ist deshalb auch im Stande, zurückkommende Pakete einer vom Client aufgebauten Verbindung richtig durchzurouten.

Wie das nun bei CS:S funktioniert, kann ich nur erahnen: Ich tippe mal, dass der Client einen UDP-Stream zum Server offen hat, der für Positionsupdates usw. genutzt wird. Parallel allerdings existiert eine TCP-Verbindung, über die dann die einzig relevanten Daten über die Leitung gehen. Nämliche tatsächlich wichtige Positionsupdates anderer Spieler usw. Wie du siehst, existiert der UDP-Stream nur einseitig, also Client->Server. Der TCP-Stream allerdings wird beidseitig genutzt, auch wenn nur der Client ihn aufgebaut hat.

Hoffe, ich konnt's einigermaßen gut rüberbringen. Wink

Und bitte keine Gewähr auf die CS:S-Geschichte, ich kann's mir nur so vorstellen.

	flashmaxel	Sa, Jul 08, 2006 12:19 Antworten mit Zitat
Vielen Dank Nox ! Hätte nicht gedacht das es eine logische erklärung gibt . Aber anscheinend lag ich da falsch. Deine Lösung wie CSS funktionieren könnte, scheint mir sehr logisch zu sein und wird fast dadurch bestätigt das ich auch TCP-Ports forwarden/freischalten muss wenn ich einen CSS-Server laufen lassen will ! Ich denk mal, da ich es nicht jedem zumuten kann Ports zu forwarden/freizuschalten, werde ich auch einen Mix aus TCP und UDP verwenden. Dankeschön für die gute Lösung !
Real C programmers never die; they cast to void.

flashmaxel

Sa, Jul 08, 2006 12:19
Antworten mit Zitat

Vielen Dank Nox !

Hätte nicht gedacht das es eine logische erklärung gibt Very Happy

. Aber anscheinend lag ich da falsch. Deine Lösung wie CSS funktionieren könnte, scheint mir sehr logisch zu sein und wird fast dadurch bestätigt das ich auch TCP-Ports forwarden/freischalten muss wenn ich einen CSS-Server laufen lassen will !

Ich denk mal, da ich es nicht jedem zumuten kann Ports zu forwarden/freizuschalten, werde ich auch einen Mix aus TCP und UDP verwenden.

Dankeschön für die gute Lösung !

Real C programmers never die; they cast to void.

	BtbN	Sa, Jul 08, 2006 17:04 Antworten mit Zitat
Also bei meinem Spiel ging es NUR mit UDP, komplett ohne TCP und das auch durch router. Dabei habe ich dem Clienten einen Random-Port zugewiesen und dem Server einen Festen. Dabei war nur wichtig, dass das erste Datenpaket vom Client gesendet wird, sonst kamen die Server-Pakete nicht an. Also kannst du z.B. ein Willkommens-Paket senden(1 Byte oder sowas). Wie gesagt, bei mir ging es.

BtbN

Sa, Jul 08, 2006 17:04
Antworten mit Zitat

Also bei meinem Spiel ging es NUR mit UDP, komplett ohne TCP und das auch durch router.
Dabei habe ich dem Clienten einen Random-Port zugewiesen und dem Server einen Festen.
Dabei war nur wichtig, dass das erste Datenpaket vom Client gesendet wird, sonst kamen die Server-Pakete nicht an.
Also kannst du z.B. ein Willkommens-Paket senden(1 Byte oder sowas).
Wie gesagt, bei mir ging es.

	flashmaxel	So, Jul 09, 2006 18:15 Antworten mit Zitat
Mhh ok danke BtbN also ich hab eigentlich auch das erste Datenpaket vom Client aus gesendet. Allerdings hab ich fast alle tests nur Lokal bei mir durchgeführt ... ich muss das unbedingt nocheinmal übers Internet testen, damit ich den TCP-UDP Mixserver nicht umsonst schreibe ! Max
Real C programmers never die; they cast to void.

flashmaxel

So, Jul 09, 2006 18:15
Antworten mit Zitat

Mhh ok danke BtbN also ich hab eigentlich auch das erste Datenpaket vom Client aus gesendet. Allerdings hab ich fast alle tests nur Lokal bei mir durchgeführt ... ich muss das unbedingt nocheinmal übers Internet testen, damit ich den TCP-UDP Mixserver nicht umsonst schreibe !
Max

Real C programmers never die; they cast to void.

	Hummelpups	So, Jul 09, 2006 18:59 Antworten mit Zitat
Es ist vollkommen egal ob UDP oder TCP. Beides muss geforwarded werden! Sonst könnte man bei Routern nicht auswählen, ob die TCP oder UDP Ports geforwarded werden sollen. Außerdem arbeitet ein Router auf der Schicht 3 des OSI Modells und nur solche mit Forwarding Funktion ziehen auch höhere Schichten in Betracht sprich 4 ggf auch 5. Wenn das Netz so aufgebaut ist: Code: [AUSKLAPPEN] [EINKLAPPEN] PC1 - Internet - Router2 - PC2 Muss die kommunikation IMMER von PC2 ausgehen wenn kein Forwarding aktiviert ist. In allen anderen Fällen muss forwarding aktiviert sein damit Router2 erkennt, wenn ein Paket nach Port 80 soll, das er es zu PC2 routen muss. Ist das Netz folgendermaßen aufgebaut (eher der Fall) Code: [AUSKLAPPEN] [EINKLAPPEN] PC1 - Router1 - Internet - Router2 - PC2 muss auf einem Router forwarding aktiviert sein, oder eine Default Route zu irgendeinem PC, das wird wahrscheinlich immer das erste Routerport sein wenn es keine Einstellung dafür gibt es aber erwähnt wird. Sonst wird wie auch bei den Cisco ACLs immer ein "deny any" am Ende jeder Access Liste erstellt. Nicht ganz so leicht der Kram. EDIT: Nox hat Folgendes geschrieben: UDP gibz aber keinen fest definierten DAtentransfer vor. D.h. der Programmierer muss Sorge tragen, wie Daten vom Server wieder zurück zum Client gelangen. Dazu teilt vorher der Client i.d.R. dem Server mit, unter welchem Port er dies zu tun hat - genau so, wie du es momentan implementiert hast. Da aber genau diese Vorhaben nicht vorher ersichtlich ist, wird dein Router UDP-Pakete ohne feste Regeln nicht durchrouten können. Anders ist das bei TCP. Wird damit eine Verbindung initiiert, sind von Vorneherein alle Quell- und Zieldaten bekannt und werden während der Verbindung auch ausschließlich genutzt. Das kann der Router wissen und ist deshalb auch im Stande, zurückkommende Pakete einer vom Client aufgebauten Verbindung richtig durchzurouten. Ist übrigens, so hart es auch klingt, schwachsinn. Auch ein UDP Header enthält einen Source sowie DEst Port. Daran solls also nicht scheitern. IMurDOOM
blucode - webdesign - Ressource - NetzwerkSim BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

Hummelpups

So, Jul 09, 2006 18:59
Antworten mit Zitat

Es ist vollkommen egal ob UDP oder TCP. Beides muss geforwarded werden!
Sonst könnte man bei Routern nicht auswählen, ob die TCP oder UDP
Ports geforwarded werden sollen.

Außerdem arbeitet ein Router auf der Schicht 3 des OSI Modells und nur
solche mit Forwarding Funktion ziehen auch höhere Schichten in Betracht
sprich 4 ggf auch 5.

Wenn das Netz so aufgebaut ist:

Code: [AUSKLAPPEN]

PC1 - Internet - Router2 - PC2

Muss die kommunikation IMMER von PC2 ausgehen wenn kein Forwarding
aktiviert ist. In allen anderen Fällen muss forwarding aktiviert sein damit
Router2 erkennt, wenn ein Paket nach Port 80 soll, das er es zu PC2
routen muss.

Ist das Netz folgendermaßen aufgebaut (eher der Fall)

Code: [AUSKLAPPEN]

PC1 - Router1 - Internet - Router2 - PC2

muss auf einem Router forwarding aktiviert sein, oder eine Default Route
zu irgendeinem PC, das wird wahrscheinlich immer das erste Routerport
sein wenn es keine Einstellung dafür gibt es aber erwähnt wird.

Sonst wird wie auch bei den Cisco ACLs immer ein "deny any" am Ende
jeder Access Liste erstellt.

Nicht ganz so leicht der Kram.

EDIT:
Nox hat Folgendes geschrieben:

UDP gibz aber keinen fest definierten DAtentransfer vor. D.h. der Programmierer muss Sorge tragen, wie Daten vom Server wieder zurück zum Client gelangen. Dazu teilt vorher der Client i.d.R. dem Server mit, unter welchem Port er dies zu tun hat - genau so, wie du es momentan implementiert hast. Da aber genau diese Vorhaben nicht vorher ersichtlich ist, wird dein Router UDP-Pakete ohne feste Regeln nicht durchrouten können.
Anders ist das bei TCP. Wird damit eine Verbindung initiiert, sind von Vorneherein alle Quell- und Zieldaten bekannt und werden während der Verbindung auch ausschließlich genutzt. Das kann der Router wissen und ist deshalb auch im Stande, zurückkommende Pakete einer vom Client aufgebauten Verbindung richtig durchzurouten.

Ist übrigens, so hart es auch klingt, schwachsinn. Auch ein UDP Header
enthält einen Source sowie DEst Port. Daran solls also nicht scheitern.

IMurDOOM

blucode - webdesign - Ressource - NetzwerkSim
BlitzBasic 2D - BlitzMax - MaxGUI - Monkey - BlitzPlus

	BtbN	So, Jul 09, 2006 20:40 Antworten mit Zitat
Ich kann nur berichten was ich erlebt habe. Es ging nur mit UDP ohne forwarding auf Client-Seite und mit auf Server-Seite durch einen Router. Vorraussetzung hierfür war jedoch, dass der Client einen Random-Port hatte.

BtbN

So, Jul 09, 2006 20:40
Antworten mit Zitat

Ich kann nur berichten was ich erlebt habe.
Es ging nur mit UDP ohne forwarding auf Client-Seite und mit auf Server-Seite durch einen Router.
Vorraussetzung hierfür war jedoch, dass der Client einen Random-Port hatte.

	Nox	Mo, Jul 10, 2006 1:07 Antworten mit Zitat
IMurDOOM hat Folgendes geschrieben: Ist übrigens, so hart es auch klingt, schwachsinn. Kein Problem, ist ja schließlich nen Diskussionsforum hier. Tatsächlich steht der Quellport auch im Header - was mich schon immer gewundert hat, wieso sich mein Router nicht die Route gemerkt hat, wenn ich als Client eine UDP-Session initiiert habe. Vll liegt's echt an nem schrottigen Modell. Aber gut, dass du das geklärt hast, man will ja nicht mit Falschinformationen um sich werfen.

Nox

Mo, Jul 10, 2006 1:07
Antworten mit Zitat

IMurDOOM hat Folgendes geschrieben:

Ist übrigens, so hart es auch klingt, schwachsinn.

Kein Problem, ist ja schließlich nen Diskussionsforum hier. Smile

Tatsächlich steht der Quellport auch im Header - was mich schon immer gewundert hat, wieso sich mein Router nicht die Route gemerkt hat, wenn ich als Client eine UDP-Session initiiert habe. Vll liegt's echt an nem schrottigen Modell. Wink

Aber gut, dass du das geklärt hast, man will ja nicht mit Falschinformationen um sich werfen.

	Dreamora	Mo, Jul 10, 2006 7:33 Antworten mit Zitat
Kann auch sein, dass der Router auf einer zu hohen Standardsicherheitsstufe (2 bzw 3 von 3 - sowas hat zumindest ZyXEL) läuft, wo du manuell das Forwarding einrichten musst, oder du dynamisches Forwarding deaktiviert hast (default bei vielen Routern, warum auch immer, denn viele wissen nicht das es benötigt wird).
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mo, Jul 10, 2006 7:33
Antworten mit Zitat

Kann auch sein, dass der Router auf einer zu hohen Standardsicherheitsstufe (2 bzw 3 von 3 - sowas hat zumindest ZyXEL) läuft, wo du manuell das Forwarding einrichten musst, oder du dynamisches Forwarding deaktiviert hast (default bei vielen Routern, warum auch immer, denn viele wissen nicht das es benötigt wird).

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

Warum geht das bei CSS aber bei meinem Blitzprog nicht ?

Betreff: Warum geht das bei CSS aber bei meinem Blitzprog nicht ?