Donnerstag, 1. Januar 2009

Netzwerk - Reconnect, Client-seitiger Ping, erweiterte Netzwerkphysik-klasse, ...

Heute wurden wieder einmal einige Bugfixes behoben...Schön langsam sollten der Mist bugfrei werden? Threads unter C++ sind verdammt aufwändig und man muss verdammt genau und gewissenhaft programmieren! Ein Client-seitiger Ping wurde implementiert, bei einer 3-fachen Übertretung dieser Zeit wird wieder in das Hauptmenü gewechselt. Ein Problem besteht weiters und muss noch gefixed werden: Ein reconnect dauert im Extremfall (kein Netzwerkkabel) zu lange und Program befindet sich im Prinzip in einem temporären Deadlock. Timeouts lassen sich leider keine neuen setzen, also muss eine Alternativlösung mit einem eigenen Timer gefunden werden. To be continued...

4 Kommentare:

  1. Bei der Socket-Kommunikation sollte man beim Empfang immer select (nicht SQL) verwenden. Mit select kann man Sockets mit Timeout pollen. Mehrere sockets gleichzeitig.
    select sollte m.E. auch unter Windows funktionnieren (sicher bin ich aber nicht).

    AntwortenLöschen
  2. Danke, select funktioniert. Mittlerweile wird der Netzwerkverkehr über select (bei send und recv) durchgeführt. Ein connect erlaubt aber leider kein select und das Timeout lässt sich auch nicht verstellen.

    AntwortenLöschen
  3. Da muss man vielleicht in der Low-Level-Trickkiste kramen. Es gibt doch Jede Menge Programme, die offene Ports scannen. Wenn man so eines nimmt (den Source Code) und adaptiert, müsste man eine Art "Ping" machen können, mit dem man vor dem connect prüfen kann, ob's überhaupt geht. Diese Tools arbeiten schnell, d.h. man hat nur kleine Wartezeiten. Wenn dieser Ping funktioniert, dann erst connect machen. Das connect würde nur dann hängen, wenn der entsprechende Server hängt.

    ...googlen nach Netwerk Scanner, Security Tools usw.

    Tools: strobe, natcat (nc), nmap ... von denen sollte man auch die Sourcen/Doku bekommen

    AntwortenLöschen
  4. Danke, nach längerer Suche bin ich von einer (mehr oder weniger) plattformunabhängigen und aufwändigeren Lösung (würde unter anderen Betriebssystemen ähnlich funktionieren) zu der icmp-api von windows gestoßen. Später habe ich die Funktion IcmpSendEcho der WinSock-API eingesetzt, da wir sowieso gerne die plattformunabhängige Entwicklung ausgeschlossen hätten. GamePad-Support, Joystick-Support, Shader, Threads, Synchronisation, Sockets, diverse Texturunterstützungen, etc. müssten sowieso neu implementiert werden. Aufgrund der Tatsache, dass das Spiel mittlerweile schon bei jedem ca. 400h verbraucht hat, hätten wir uns einmal primär auf Windows konzentriert und das Thema Plattformunabhängigkeit auf die Nachfolgephase der Diplomarbeit verschoben. Diverse Zwischen-Klassen müssten geschaffen werden, die je nach Betriebssystem die zugehörigen OS-spezifischen Funktionen aufrufen.

    AntwortenLöschen