ClientID()/Socket -> Rückgabewert?

[Toshy]

Hi.

Gibt ConnectionID(ClientID) den selben Wert zurück wie socket_()? Ist ConnectionID() also gleich dem "Socket"?
Und was für ein Typ wird da zurück gegeben, ein Word oder ein Long?

In meiner alten Win32.hlp steht bei socket_() nur
"If the function succeeds, socket returns a descriptor referencing the new socket.
"

Gruß
Thorsten

[mk-soft]

Dito Hi,

Wie ich das verstanden habe es nicht mehr wie in PB3.94.
Habe ich mich auch schon gefragt wie man an die socket ID heran kommt.
Verwendet ich habe die Socket ID schon mal um Serverseitig den Client Verbindung zu schliessen.

In den Zusammenhang habe ich auch gleich noch eine frage:

Kann man nicht noch #PB_NetworkEvent_Disconnect in den NetworkClientEvent(Verbindung) einbinden um zu erkennen das der Server die Verbindung beendet hat?

FF

[real]

@Toshy: Keine Ahnung, ob die ConnectionID(ClientID) der Rückgabewert von socket_() ist. Wofür brauchst Du die Information? Und wieso willst Du einen mixed mode von PB-Funktionen und direkter Socket-Programmierung nutzen?
socket_() gibt auf Unix einen int zurück. Unter Windows ist in der winsock.h des C-Compilers meiner Wahl der Typ SOCKET als unsigned int definiert - Du solltest also in PB Long verwenden.

@mk-soft: Welche Sinn sollte es haben festzustellen, ob der Server sich getrennt hat? Du connectest Dich zu einem Server und schickst ihm Daten. Wenn der Server die Verbindung beendet haben sollte, bekommst Du als Ergebnis bei SendNetworkData() -1 und bei SendNetworkFile() 0. Die Feststellung, ob eine Verbindung beenden wurde, bringt also nur bei der Serveranwendung wirklich etwas.

[Toshy]

@real
Das mit der SocketId hat unterschiedliche Gründe. Einer der Gründe ist aber das man durch die Socket soweit ich das gesehen habe besser einen Festen Index errechnen kann. Denn der Socketwert fängt bei "ein wenig über NULL" an und steigt nur jeweils um 4 Byte an. Mit der ClientID läßt sich das leider nicht so gut machen.
Außerdem bereite ich meine Routinen doch so vor, daß ich sie später notfalls durch eine eigene Sockeroutine (oder ne Lib) ersetzen kann, denn noch weiß ich nicht wie die ClientID`S verwaltet werden und was für ein Geschwindigkeitsverlust da (eventl.) auftritt. Bisherige tests bei mir sind für mich aber nicht besonders glücklich abgelaufen.

Und das Problem von mk-soft hat eigendlich jeder. Ich fände es auch gut und sinnvoll wenn es so eine Funktion gäbe. Aber soweit ich weiß sieht TCP/IP nicht vor dem Clienten mitzuteilen das der Server die Verbindung gekappt hat. Man muß wie du es angemerkt hast das selber basteln, aber ein einfacher Wert von "-1" oder "0" bedeutet nicht automatisch das die Verbindung beendet ist. Es kann einfach sein, das der Server einfach noch nicht dazu kam alle Daten zu verarbeiten, was
gerade bei Servern mit hoher Last leicht geschieht. Man muß also eine Art Counter einbauen der die Fehler beim senden loggt und nach einer bestimmten Anzahl an Übertragungsfehlern (seit dem letzten erfolgreichen senden) die Verbindung auf auf Clientseite beenden. Schöner und sicherer wäre es schon wenn man es wie auf der Serverseite machen könnte. Aber wenn dies ginge, hatte Fred das sicher eingebaut. Aber ich habe bisher noch nirgens gesehen oder gelesen das dies geht.

[HeX0R]

... Aber wenn dies ginge, hatte Fred das sicher eingebaut. Aber ich habe bisher noch nirgens gesehen oder gelesen das dies geht....

Wie ?
Du kennst unseren Lars nicht ?

[real]

Das funktionert (leider) nur unter Windows. Dort ist es eine gute Methode, wie ich finde...

Socketprogrammierung unter Windows ist sehr komfortabel, da man über den Aufruf von WSAGetLastError_() sehr umfangreich Auskunft über den aktuellen Status erhält.

[mk-soft]

@real,

ich möchte schon gerne wissen das die Verbingung Serverseitig beendet wurde bevor ich irgendwelche Daten sende.

Siehe Hyerterminal. Dieser geht auch gleich offline wenn der Server beendet wird.

FF

[grapy]

Es kann einfach sein, das der Server einfach noch nicht dazu kam alle Daten zu verarbeiten, was
gerade bei Servern mit hoher Last leicht geschieht.

ich möchte schon gerne wissen das die Verbingung Serverseitig beendet wurde bevor ich irgendwelche Daten sende

Genau deshalb gibt es Netzwerkprotokolle!
Und die muss man sich dann eben selbst programmieren!

Handshake; CRC Überprüfung etc.

der Client wird z.B. selbst als "Server" tätig und merkt dann sofort
wenn der "richtige Server" beendet wird bzw. wenn er von ihm keine
Antwort mehr bekommt (Timeout nach einer bestimmten Zeit).

gruß grapy

[Toshy]

@HeX0R
ne, kenne Lars nicht. Schaue mir das aber mal an.

@all
So ganz verstehe ich den Code noch nicht.
Was ich mich aber grundlegend frage ist, wie kann es unterschiede zwischen Windows und anderen Systemen geben? Ich meine dabei nicht die Art der Aufrufe, Funktionsnamen. Meines Wissens nach kann das TCP/IP-Protokoll entweder ein Serverdisconnect unterstützen oder nicht. Wenn dies aber geht, dann würde es mich fundern, warum Fred das nicht einbaut. Wenn dies nur ein Workaround ist, so bringt es ja nur bedingt etwas. Ich werde zwar erst nur unter Windows programmieren, aber muß für später auch alles so offenhalten, das es auf anderen System laufen könnte. Wenn es also keine Betriebssystemunabhängige möglichkeit gibt (bezogen auf das TCP/IP Protokoll), dann sollte man das lieber mit einem eigenen Protokoll machen. So wie "grapy" es sagt. Zwar erstelle ich eh ein eigenes kleines Protokoll, aber wenn man ein "Serverdisconnect" sicher mitbekommen könnte, dann wäre es schon toll.

Weiß jemand, weshalb der Code von Lars etwas macht und PB dies nicht tut?

Bisher sieht das aber schon mal sehr interessant aus.
Danke und Gruß
Toshy

[HeX0R]

Ich hatte mal im englischen Board einen Beitrag gesehn, wo Fred meinte er würde es als sinnvoll erachten einen Client-Event 4 (also Disconnect) ins Purebasic zu bauen.
Leider finde ich den entsprechenden Thread nicht mehr, aber es ist auf jeden Fall mehrere Jahre her...

Um's anders zu sagen, ich glaube nicht mehr daran.