Cross-Platform Netzwerkbibliotek C(++) geeignet für Spiele

Gast++

Artchi schrieb:

XML-RPC, SOAP usw. sind aber nicht garade für Realtime-Online-Games geeignet. Für rundenbasierte Games aber sicherlich denkbar. Bei Corba kann ich mir das aber schon eher vorstellen, für Realtime-Games zu nutzen.

ACK

Artchi schrieb:

Aber am Ende haben die ganzen Games meistens eh ihr eigenes Protokoll.

Da liegt aber ein Problem das nicht nur auf Spiele beschränkt ist. Wenn ich hier mitkriege wie oft direkt mit sockets gearbeitet wird frage ich mich immer warum höherwertige Technologien offenbar so unattraktiv sind.
Wenn's um Performance geht - die Performance von z.B. mico muss man erst mal selbst mit sockets bei gleicher Qualität (z.B. Fehlerbehandlung) hinkriegen.

Trotzdem wird im Zweifel imho eher zu sockets gegriffen.

Grüsse

*this

Artchi

Hast du Erfahrung mit Mico? Geht das ab wie schmidts Katze? Da es ja binärbasiert ist, hat es logischerweise eher keinen Overhead a la XML. Ich habe mir auch so ein paar Videos auf der Mico-Website angeschaut. Sah ja beeindruckend aus, auch wenn ich nicht wirklich mitbekommen habe, wann und wo Mico aktiv war.

Gast++

Artchi schrieb:

Hast du Erfahrung mit Mico? Geht das ab wie schmidts Katze?

Na ja:

class Cat {

  public:
    void meow(void) {
    }
};

class Person {

  private:
    Cat* pCat; // Aus Grüden des Tierschutzes NICHT per value !
    std::string strName; 
  public:

    Person(const char* pszName, Cat* pCat) {
        this->pCat = pCat;
        this->strName = pszName;
    }

    void feed_cat(void) {
        this->pCat->meow();
    }
};

int main() {
    Cat tom;
    Person schmidt("Schmidt",&tom);

    schmidt.feed_cat();
    return 42;
}

wird wohl schneller sein...

Aber ich hab mit mico selber mal rumgespielt und es für eines von 2.5 CORBA-Projekten benchmarken müssen.
(Das .5 deshalb da am Ende Cross-Platform wegfiel und dann DCOM eingesetzt wurde.)

Ich erinnere es als sehr schnell; Visibroker war ein anderer Kandidat und den liess es im Schrank stehen.
MICO ist aber langsamer als DCOM was mich auch nicht wundert.

Hast Du jetzt konkret damit zu tun? Ich hab den alten Source bestimmt noch auf Tape und würd's ggf. raussuchen.

Artchi schrieb:

Da es ja binärbasiert ist, hat es logischerweise eher keinen Overhead a la XML.

Deshalb mein ACK für Realtime vs. Round-based.

Grüsse

*this

P.S.: @Artchie Krieg ich noch mail von Dir?

darthdespotism

ok meine Antwort bezog sich jetzt auf boost::asio, mal sehn wie CORBA aussieht

EDIT://
Ist MICO jetzt LGPL oder GPL? Ist irgendwie nicht ersichtlich

EDIT://
Es wird ein Echtzeit-Spiel werden

Gast++

darthdespotism schrieb:

Ist MICO jetzt LGPL oder GPL? Ist irgendwie nicht ersichtlich

In der Datei ".\LICENSE" im Paket findet sich

This file contains the license conditions for MICO. All libraries
are covered by the GNU Library General Public License (LGPL), code
generated by the IDL compiler is not copyrighted, everything else
is covered by the GNU General Public License (GPL).

The idea behind this is that MICO can be used for developing
commercial applications without requiring the manufacturer of the
commercial application to put the application under (L)GPL.
On the other hand it is not possible to derive commercial applications
from MICO without putting that application under (L)GPL.

File LICENSE-LGPL contains terms and conditions of the LGPL, LICENSE-GPL
contains terms and conditions of the GPL.

share and enjoy!

Das versteh ich so dass man mico in kommerziellen Anwendungen einsetzen darf, aber keinen eigenen kommerziellen ORB draus machen darf.

Grüsse

*this

darthdespotism

ok thx.

rüdiger

darthdespotism schrieb:

ok meine Antwort bezog sich jetzt auf boost::asio, mal sehn wie CORBA aussieht

EDIT://
Ist MICO jetzt LGPL oder GPL? Ist irgendwie nicht ersichtlich

EDIT://
Es wird ein Echtzeit-Spiel werden

Vergiss CORBA und alles was Gast++ dir vorgeschlagen hat. Das ist für deinen Zweck einfach absolut das falsche (du würdest ja auch nicht ein Sportauto bauen und dann auf die Idee kommen die zweite hälfte des Gehäuses von einem Wohnmobil zu nehmen, nur weil zufällig von dem Gehäuse schon eine hälfte existiert :)).

Gerade bei Spielen ist die Geschwindigkeit beim Transport der Daten wichtig.

darthdespotism

rüdiger schrieb:

Vergiss CORBA und alles was Gast++ dir vorgeschlagen hat. Das ist für deinen Zweck einfach absolut das falsche (du würdest ja auch nicht ein Sportauto bauen und dann auf die Idee kommen die zweite hälfte des Gehäuses von einem Wohnmobil zu nehmen, nur weil zufällig von dem Gehäuse schon eine hälfte existiert :)).

Gerade bei Spielen ist die Geschwindigkeit beim Transport der Daten wichtig.

Ich wollte gerade anmerken dass asio::ip:: warscheinlich genau das ist was ich suche

Gibts dazu irgendwo noch ein oder zwei gute Tutorials (die beiliegenden habe ich mir bereits angesehen )

hustbaer

Falls performance gefragt ist (-> reliable UDP) wäre vielleicht die RakNet was.

Die RakNet ist zwar nicht ganz gratis, dafür läuft die auf Windows, Linux und Konsolen. Für "non-profit applications or engines" kann man die RakNet unter der " Creative Commons Attribution - NonCommercial 2.5" Lizenz verwenden, kommerzielle Lizenzen gehen ab 100$ los (für ein Produkt). Eine "Site-License" kostet 5000$.

Verglichen mit dem was z.B. Quazal für die NetZ verlangt ist das geschenkt
(OK, die Quazal kann mehr, bloss ist die wirklich nicht gerade das Gelbe vom Ei, auch wenn sie so beworben wird und scheissteuer ist.)

Ahja, Open Source ist das Teil auch, also die RakNet, nicht die Quazal natürlich.

http://www.rakkarsoft.com/

Gast++

Gerade bei Spielen ist die Geschwindigkeit beim Transport der Daten wichtig.

Was bringt der im Prinzip schnellste Transport wenn man es dann selbst erstmal in 1001 Schicht einpacken muss?
Ich hab mit CORBA und DCOM schon reichlich grosse Datenmengen über's Netz geschoben und das ging ganz hervorragend!

Der eigentliche Flaschenhals ist das Netz selbsr, da sind wir uns doch wohl einig, oder?

Grüsse

*this

P.S.:

rüdiger schrieb:

Vergiss CORBA und alles was Gast++ dir vorgeschlagen hat.

Rüdiger, Du musst mich nicht mögen, aber das könntest Du sicher besser formulieren.

darthdespotism

hustbaer schrieb:

http://www.rakkarsoft.com/

Die Seite hab ich schonmal gesehen, keine Ahnung in welchem Zusammenhang ich das gefunden habe.

Wäre dann Möglichkeit 2

Meinst du die ist deutlich schneller/besser als ein asio::ip::udp mit entsprechenden abfragen (->relieable)?

rüdiger

Gast++ schrieb:

Gerade bei Spielen ist die Geschwindigkeit beim Transport der Daten wichtig.

Was bringt der im Prinzip schnellste Transport wenn man es dann selbst erstmal in 1001 Schicht einpacken muss?
Ich hab mit CORBA und DCOM schon reichlich grosse Datenmengen über's Netz geschoben und das ging ganz hervorragend!

Der eigentliche Flaschenhals ist das Netz selbsr, da sind wir uns doch wohl einig, oder?

Bei einem Protokoll für Spiele wird man nicht sehr viele Schichten beim Packen haben. Natürlich ist das Netz der größte Flaschenhals. Aber du wirst nicht abstreiten können, das CORBA einen gewissen Overhead mitbringt. CORBA ist einfach für andere Aufgaben entworfen worden.

P.S.:

rüdiger schrieb:

Vergiss CORBA und alles was Gast++ dir vorgeschlagen hat.

Rüdiger, Du musst mich nicht mögen, aber das könntest Du sicher besser formulieren.

Das ist nicht persönlich gemeint. Ich habe absolut gar nichts gegen dich. Es tut mir leid, wenn das so rüber gekommen ist. Aber die Vorschläge von dir sind für sein Projekt nun einmal überhaupt nicht nützlich imho.

Gast++

rüdiger schrieb:

Bei einem Protokoll für Spiele wird man nicht sehr viele Schichten beim Packen haben.

ACK; aber wieviele Schichten hat man denn bei CORBA?

Eine Indirektion hat man zugegebenermassen bei CORBA immer; sei es bei C++ via VMT oder bei C via callback.
=> "Messunschärfe" im Vergleich zu den Systemrufen auf den Socket und dessen Latenz.

Es ist doch eher so dass man einerseits Sockets direkt verwendet um "teures" Marshalling auszuschliessen aber dann selber das Marshalling/De-Marshalling mindestens genauso teuer selbst aufbaut.

Bei CORBA ist die initiale Instanziieung/Lokation des Objektes zugegebermassen teuer; aber dem kann man entgegenwirken indem man Remote-Objekte als Fassaden benutzt die v.a. möglichst breite Daten"ströme" ausliefern.
Dann nutzt man die Implementierung der Marshaller effizient.
Ein einzelnes int sollte man weder per sockets noch per CORBA durch's Netz schicken wenn man's schnell braucht.

rüdiger schrieb:

Natürlich ist das Netz der größte Flaschenhals. Aber du wirst nicht abstreiten können, das CORBA einen gewissen Overhead mitbringt.

Ja, tut es. Nur zwingt es, richtig eingesetzt, Applikationskernen kein Programmiermodell auf und wird nicht viel grösser als eigenes Customizing von Socket-Kommunikation.

Grüsse

*this

P.S.:

rüdiger schrieb:

Das ist nicht persönlich gemeint. Ich habe absolut gar nichts gegen dich. Es tut mir leid, wenn das so rüber gekommen ist. Aber die Vorschläge von dir sind für sein Projekt nun einmal überhaupt nicht nützlich imho.

Und ich dachte schon Du hättest mir mein Emacs-Gelästere übel genommen.
Im Ernst; ich mag den Emacs eigentlich nur k**** mich das Customizing an.
N.P.

hustbaer

z.T. RakNet...

Meinst du die ist deutlich schneller/besser als ein asio::ip::udp mit entsprechenden abfragen

Ja, ich denke die RakNet müsste schneller sein. Ich weiss dass die Boost.Asio aufgrund des Designs gezwungen ist haufenweise new/delete zu machen und oft zu locken, was beides Zeit kostet. Die RakNet hab' ich mir diesbezüglich nie angesehen, kann aber nur hoffen dass sie es besser machen kann (und es auch tut), da sie viel spezialisierter ist als die Boost.Asio.

Ich schätze aber dass bei der (geringen) Anzahl an Packets/Sekunde das nicht weiter ins Gewicht fallen sollte.

Was ich für wichtiger halte: bei der RakNet bekommst du eine fertige, funktionierende und schnelle "reliable UDP" Implementierung. Sowas selbst zu schreiben ist keine kleine Sache, und die Boost.Asio bietet dahingehend was ich weiss nix an.

Davon abgesehen lies dir einfach mal die Featureliste auf der Homepage durch. Dann schreib dir das raus was du brauchen kannst/wirst, und überleg dir wieviel Arbeit es wäre das selbst zu einer eigenen Implementierung dazuzustricken.

Sieh' dir die Library einfach mal an, der Download (mit Source!) ist gratis, ist ein direkter Link auf der HP. Brauchst nix registrieren oder sonstwas.

darthdespotism

So der erste Versuch die Biblioteken zu bauen ist gescheitert ...

Linux 2.6.20 / Ubuntu 7.04

make beendet sich immer mit der Meldung

darthdespotism@akazieLX:~/dev/RakNet$ make
make -C Source "BASE_DIR=/home/darthdespotism/dev/RakNet" static
make[1]: Betrete Verzeichnis '/home/darthdespotism/dev/RakNet/Source'
make[1]: *** Keine Regel, um »static« zu erstellen.  Schluss.
make[1]: Verlasse Verzeichnis '/home/darthdespotism/dev/RakNet/Source'
make: *** [static] Fehler 2
darthdespotism@akazieLX:~/dev/RakNet$

gcc - Problem oder ien Problem mit den Sourcen?
____________
das CodeBlocks - Projekt liefert, nachdem ich das compilerflag -mthreds auf -pthread geändert habe eine ladung *.dll s, die aber uU Linux - Biblioteken sind.

darthdespotism@akazieLX:~/dev/RakNet/Lib$ file *
dll:                      directory
DLL:                      directory
LibStatic:                directory
RakNetDebug.dll:          MS-DOS executable PE  for MS Windows (DLL) (GUI) Intel 80386 32-bit
RakNet.dll:               MS-DOS executable PE  for MS Windows (DLL) (GUI) Intel 80386 32-bit
RakNetDLLDebug.lib:       current ar archive
RakNetDLL.lib:            current ar archive
RakNetLibStaticDebug.lib: current ar archive
RakNetLibStatic.lib:      current ar archive

hustbaer

Äh.
Guck dir die ersten beiden Bytes der DLLs an, vielleicht heissen die nur .dll. Wenns wirklich PE Images (Windows Zeugs halt) sind müssen sie mit "MZ" anfangen.
Würde mich aber wundern wenn CodeBlocks unter Linux dir Windows DLLs erstellen würde...

darthdespotism

Ich bin mittlerweile fast davon überzeugt dass die dlls so dabei waren.

Im Forum habe ich dann letzten Endes eine Automake - Version gefunden, die mir das ganze dann auch funktionierend kompiliert hat. Bis ich das Linux-Beispiel zum Laufen gebracht habe wars wieder einiges zu tun aber letzten Endes läuft das jetzt, ich werd dann wohl mal ein bischen mit rumexperimentieren.

Btw: Mein Code::Blocks unter Linux erzeugt immer wieder tatsächlich Win-exe und Win-dll, da ich da den MinGW-Crosscompiler eingerichtet habe.
(Nächstes Projekt in die richtung ist dann der VC8 mit wine eher Spaßeshalber