Sock IP Funktionen kaputt?

[kanonet]

SOCK_TCPACCEPT( sock%, ip% )
ip% = SOCK_GETREMOTEIP( sock% )
In beiden fällen ist ip% immer 0.
Das Netzwerk funktioniert, ich kann empfangen und senden, wie es sein soll, es ist mir lediglich nicht möglich die IP des Clients/Servers zu ermitteln. Betrifft TCP, sowohl wenn sich Client und Server auf einen Rechner befinden, als auch, wenn sie auf verschiedenen laufen. Nicht getestet unter UDP.

EDIT: Auch zum Thema SOCK_...:
Interessanterweise habe ich gerade festgestellt, dass bei Kommunikation zwischen zwei Rechnern meine Firewall (Comodo) verhindert, dass ich feststellen kann, dass die Verbindung abgebrochen ist. Wenn der Client offline gegangen ist, erhält der Server über SOCK_RECV weiterhin -2 als Rückgabewert, statt der erwarteten und gewünschten 0. Irgendeine Idee, wie dies gelöst werden kann, ohne die Firewall zu deaktivieren?

[Kitty Hello]

0 ist OK. Nur -1 wäre ein Fehler. (Steht auch so im Handbuch).

Wenn Du bei SOCK_RECV keine 0 erhältst, ist das schon seltsam.

[kanonet]

0 ist OK. Nur -1 wäre ein Fehler. (Steht auch so im Handbuch).

Beziehst du dich damit auf die IP? Inwiefern ist 0 dann korrekt? Besonders wenn Client und Server sich auf verschiedenen Rechnern befinden? Aber selbst wenn 0 auch mal korrekt sein kann (bei Ausführung auf einem Rechner?), dann ist es doch sicher nicht korrekt, wenn ich immer eine 0 zurück bekomme? Also wie kann ich die IP eines Clients/ des Servers bestimmen (ohne diese an die andere Seite schicken zu müssen)?

Wenn Du bei SOCK_RECV keine 0 erhältst, ist das schon seltsam.

Sehe ich auch so.^^ Aber eine Lösung fällt dir auch nicht ein? Ich meine, ich kann ja nicht von allen meinen Spielern verlangen, dass sie ihre Firewalls deaktivieren.

[Kitty Hello]

nicht IP, sondern ein "Socket" -Wert von 0 ist OK.

[kanonet]

Dass Socket 0 sein kann ist mir klar, jedoch ist dies weder mein Problem, noch meine Frage, bei beiden genannten Funktionen nimmt IP$ immer den Wert 0 an. Daher ja mein Post, also wie kann ich dann die IP der Gegenseite bestimmen?

Hast du einen Vorschlag zu der Sache mit der Firewall?

Funktioniert SOCK_TCPSEND in GLB_ON_QUIT? Ich hatte damit bisher keinen Erfolg, möglicherweise, da der Socket sofort danach geschlossen wird, vielleicht noch bevor tatsächlich gesendet werden konnte?

[Kitty Hello]

aso. Und der sock ist >= 0?
Dann ist's ein Problem. Was sagt er, wenn Du's mit 127.0.0.1 versuchst. Da ist die Firewall ja nicht mit drin. Wenn's nicht geht, bitte kleines Beispiel posten.

[kanonet]

Ja, Socket >= 0, das senden und empfangen funktioniert auch in beide Richtungen, jedoch die IP Ermittlung nicht. Ich habe es mit beiden Instanzen auf einen Rechner (Server mit "" und "127.0.0.1") und auch mit 2 Rechnern im Netzwerk (sowohl mit aktivierter, als auch mit deaktivierter Firewalls) probiert, die Netzwerkkommunikation funktionierte immer, jedoch war ip$ immer 0.
Vielleicht reicht als Beispiel das:
wenn man samples/Netzwerk/TCP um eine Zeile zur Anzeige der IP erweitert, dann kann man sehen, dass immer ip$ = 0 als Ergebnis kommt (mit beiden Ermittlungsmethoden und sowohl am Client, als auch am Server).

[Kitty Hello]

SOCK_GETREMOTEIP war defekt. Sorry.

[kanonet]

Hallo Kitty, danke das du dir das angesehen hast. Zu den Sock-Befehlen habe ich aber noch ein paar Meldungen/Fragen:

1. Mit V10.179 scheint dies nur teilweise behoben zu sein, SOCK_GETREMOTEIP erkennt die IP des Servers immer, jedoch die des Clients nie beim ersten Connect. Wenn ein Client sich mir dem Server verbindet gibt dieser stets 0.0.0.0 als angebliche IP des Clients aus, verbindet sich ein zweiter Client (egal ob der erste beendet wurde, oder nicht), dann wird dessen IP korrekt erkannt, alle weiten Clients ebenfalls. Tritt sowohl lokal auf einen Rechner auf, als auch im Netzwerk.

2. Außerdem wird die IP immer verkehrt herum ausgegeben (Fehler in SOCK_GETIP$ ?), bspw. 101.2.168.192, statt der korrekten 192.168.2.101.

3. Noch eine Frage:
Wenn ich bspw. am Client schreibe:
SOCK_TCPSEND(sock, "AAA")
SOCK_TCPSEND(sock, "BBB")
kann es sein, dass die andere Seite (hier also der Server) statt zwei Nachrichten ("AAA" und "BBB") nur eine Nachricht ("AAABBB") erhält, anscheinend wird also kein Ende der Nachricht übertragen. Ist dies ein Bug, oder beabsichtigt?

4. Zu der Sache mit der Firewall (s.o.), hast du da noch Vorschläge, oder Ideen wie dies behoben werden kann, oder muss es akzeptiert werden?

5. Funktionieren Sock-Befehle in GLB_ON_QUIT?
Kleiner Vermerk zu GLB_ON_QUIT: wenn ich mein (Konsolen-) Programm mittels "Fenster Schließen" oder den Taskmanager beende, dann wird die Sub nicht aufgerufen. Wäre es möglich das zu ändern? (getestet unter Win7 Pro x64)

Vielen Dank.

[Kitty Hello]

1. Muss ich testen. Hast kurzen Beipiel?
2. Bug!!
3. Jo, das ist so. Wenn Du es anders willst, dann trenne nach dem Senden die Verbindung - so macht's ein Webserver.
4. Die Firewall hält die Verbindung aktiv, blockiert aber scheinbar die Daten.
5. Muss ich mal sehen.

[kanonet]

1. Es sollte hier wieder reichen, wenn du das Beispiel samples/network/tcp um eine Zeile zur Anzeige der IP erweiterst.
3. Ähh, sorry... da würde ich kurz deine Hilfe brauchen, wie meinst du das/ wie wäre das umzusetzen? Du meinst ja sicherlich nicht, dass ich den Socket schließen soll, daher wie kann ich die Verbindung beenden? Gibt es ein spezielles Trennungszeichen, dass ich übermitteln kann? Notfalls programmiere ich mir eben selbst einen Trenner, der als letztes Zeichen übermittelt wird.
4. Also keine Lösung möglich? Dann werde ich als Work-around eine "Beendigungsnachricht" per GLB_ON_QUIT übertragen. Dass sollte das Problem in den meisten Fällen lösen. (Wäre das eventuell als generelle Lösung interessant, die du implementieren könntest?)

[Kitty Hello]

Oder Du schickst bei Nachrichten einen header mit. 4 Byte -die Länge der Nachricht. Dann lies diese 4 und dann exakt die Länge.
Webserver machen tatsächlich ein sock_close(), dass dann als "0" zurückkommt.

[kanonet]

@Ocean: ich habe es bereits mit einem "/r/n" am Ende der Nachricht probiert, jedoch scheint dies nicht zu funktionieren; es wird weiterhin als eine Nachricht empfangen. Habe ich etwas falsch verstanden, oder gibt es weiter Vorschläge?

@Kitty: sock_close kann ich mir für mein Projekt gerade nicht vorstellen, scheint mir viel zu umständlich zu sein. Ein Header scheint da schon ehe praktikabel, jedoch glaube ich, dass ein Trennungszeichen am Ende der Nachricht etwas weniger Aufwand wäre.

[kanonet]

Hallo Ocean,

dass der Socket-Standard eingehalten werden muss ist klar, meine Fragen zielten eben darauf ab, zu erfahren, wie dieser aussieht/implementiert ist. Es ist absolut kein Problem einen eigenen Trenner zu programmieren (habe ich ja auch schon geschrieben), ich würde mir lediglich die Arbeit sparen wollen, wäre ein solcher bereits vorgesehen, daher die Fragen. Wenn die Antwort lautet, "nein es gibt keine automatische Trennung, das musst du selbst machen", dann ist meine Frage bereits beantwortet.

@CR/LF: mir ist wahrscheinlich immer noch nicht ganz klar, wie du das meinst, hier ist was ich tue:
Client:
SOCK_TCPSEND(sock, "AAA\r\n")
SOCK_TCPSEND(sock, "BBB\r\n")

Server
SOCK_RECV(sock, msg$, 1024)
Wobei msg$ dann eben den Wert "AAA\r\nBBB\r\n" erhält, statt der erwarteten "AAA". Es macht also keinen Unterschied, dass ich "\r\n" angefügt habe. Hatte ich dich falsch verstanden, dass hier automatisch getrennt wird, oder soll ich das jetzt manuell machen, wie bei jedem beliebigen anderen Trenner auch?

Ich hoffe ich du verstehst jetzt meine Verwirrung, den Grund meiner Fragen: einerseits sagst du, es gibt keine automatische Trennung, das muss ich selbst machen, andererseits wirkte dein Vorschlag CR/LF anzuhängen, als ob dies eben eine automatische Trennung wäre... Sorry, irgendwo muss ich dich falsch verstanden haben, könntest du mir da bitte noch mal Klarheit verschaffen?

Vielen Dank,
Kanonet

[Kitty Hello]

Jo. Lies 1024, dann such nach crlf. Wenn drin, string bis da hin returnen. Rest beim nächsten Aufruf vorne dranpappen und nach crlf suchen