Wenn Dich Englisch nicht schreckt, könnte Dir vielleicht Game Programming with Python eine Hilfe sein. Hier werden viele grundlegende Dinge der Spieleprogrammierung mit Python abgehandelt, u.a. auch Online-Spiele. Es ist zwar nicht ganz billig, bei caiman_amerika aber neu zum halben Preis (28,38 €) erhältlich.
MfG
HWK
Machbarkeitsanfrage Python oder andere Sprache
Von Oktober 2003, ist das noch aktuell genug? War damals nicht Python 2.1 oder sowas? Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk?? Gibt ja noch ein neueres Werk... Beginning Game Development with Python and Pygame: From Novice to Professional (Expert's Voice)
Das hier fand ich ganz toll: Foundations of Python Network ProgrammingYogi hat geschrieben:...Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk??...
MfG
HWK
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ohne das Buch gelesen zu haben würde ich sagen, dass ein Buch zu TCP/IP an sich schon sehr brauchbar sein kann, da Pythons ``socket``-Modul BSD-sockets nachempfunden ist und somit viele Dinge übertragbar sind. Natürlich, es gibt noch Asyncore/Medusa und Twisted, aber so viel tut sich in der Richtung nicht.HWK hat geschrieben:Das hier fand ich ganz toll: Foundations of Python Network ProgrammingYogi hat geschrieben:...Vielleicht bräuchte ich ja mehr so ein generelles Netzwerk Grundlagenwerk??...
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Z.B. damit:gerold hat geschrieben:Man kann auch mehrere Datenbankserver im Multimaster-Betrieb zusammenschließen.
http://bucardo.org/
lg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Hi, ich dachte ich mache keinen neuen Thread auf, sondern ergänze den bestehenden.
Also, ich bin in meinem Ski-Urlaub fleissig gewesen und habe den Prototypen fertig gestellt. Es ist gut zu wissen, dass meine Idee nicht nur spinnert ist, sondern auch tatsächlich funktioniert, auch wenn ich für die visuelle Darstellung für 1000 Clients überdenken muss, da ist dann einfach zu viel los auf dem Screen. Aber das ist ganz gut, dann kann ich mit einem vernünftigen LOD, Ausblendung weiter entfernter oder nicht im Sichtfeld befindlicher Clients auch die Datenmenge schön reduzieren.
Aber jetzt wird echt happig, ich möchte jetzt alles Client-Server mässig in Python umsetzen. Und obwohl ich schon reichlich gelesen habe über Frameworks etc., bin ich kein bisschen schlauer. Immer, wenn ich denke ich habe eine Kombi, dann gibt es Stimmen, die sagen, neeee, bloss das nicht, nimm lieber das und das.... ich blick da nicht mehr durch.
Aus Kostengründen möchte ich gern erst einmal ein Server-System zu Hause aufsetzen, bevor ich einen dedicated miete.
Da wäre also erst einmal die OS Frage zu klären. Ich halte Debian 4 für eine gute Wahl, muss mich da aber erst einmal einlesen. Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.
Als Datenbank MySQL.
Als Server dachte ich an CherryPy, weil das anfangs einfacher einzurichten sein soll und weil ich später Apache vorschalten kann.
Bei Apache habe ich Sorge vor den Konfiguration und den Sicherheitslücken.
Als ORM für die Datenbank dachte ich an SQLAlchemy oder Storm.
Als Templating System dachte ich an Mako oder sogar Cheetah. Da ich anfänglich die Auswertung browserbasiert haben möchte, kann ich mit XML Systemen wie Genshi nichts anfangen.
Tja und was die UDP und TCP betrifft dachte ich erst an Twisted, aber ich habe schon mehrfach lesen müssen, dass das eine ziemlich steile Lernkurve besitzt. Was gibt es noch als Alternative?
Bei allen Paketen sollte gelten, einfach in der Anwendung aber belastbar und bewährt.
Eine weitere Frage ist auch, ist es sinnvoll zwei Server zu benutzen? Der eine für das User-Management etc. und der andere für die Berechnungen und die Übermittlung der Daten für die visuelle Darstellung an die Clients.
Dann könnte ich einen normalen, gewarteten Server nehmen und einen dedicated als zweiten, der dadurch sicherer ist, dass keine Clients darauf zugreifen. Geht das überhaupt? Client sendet und empfängt von Server 1, aber empfängt nur von Server 2. Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?
Was meint ihr dazu?
Also, ich bin in meinem Ski-Urlaub fleissig gewesen und habe den Prototypen fertig gestellt. Es ist gut zu wissen, dass meine Idee nicht nur spinnert ist, sondern auch tatsächlich funktioniert, auch wenn ich für die visuelle Darstellung für 1000 Clients überdenken muss, da ist dann einfach zu viel los auf dem Screen. Aber das ist ganz gut, dann kann ich mit einem vernünftigen LOD, Ausblendung weiter entfernter oder nicht im Sichtfeld befindlicher Clients auch die Datenmenge schön reduzieren.
Aber jetzt wird echt happig, ich möchte jetzt alles Client-Server mässig in Python umsetzen. Und obwohl ich schon reichlich gelesen habe über Frameworks etc., bin ich kein bisschen schlauer. Immer, wenn ich denke ich habe eine Kombi, dann gibt es Stimmen, die sagen, neeee, bloss das nicht, nimm lieber das und das.... ich blick da nicht mehr durch.
Aus Kostengründen möchte ich gern erst einmal ein Server-System zu Hause aufsetzen, bevor ich einen dedicated miete.
Da wäre also erst einmal die OS Frage zu klären. Ich halte Debian 4 für eine gute Wahl, muss mich da aber erst einmal einlesen. Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.
Als Datenbank MySQL.
Als Server dachte ich an CherryPy, weil das anfangs einfacher einzurichten sein soll und weil ich später Apache vorschalten kann.
Bei Apache habe ich Sorge vor den Konfiguration und den Sicherheitslücken.
Als ORM für die Datenbank dachte ich an SQLAlchemy oder Storm.
Als Templating System dachte ich an Mako oder sogar Cheetah. Da ich anfänglich die Auswertung browserbasiert haben möchte, kann ich mit XML Systemen wie Genshi nichts anfangen.
Tja und was die UDP und TCP betrifft dachte ich erst an Twisted, aber ich habe schon mehrfach lesen müssen, dass das eine ziemlich steile Lernkurve besitzt. Was gibt es noch als Alternative?
Bei allen Paketen sollte gelten, einfach in der Anwendung aber belastbar und bewährt.
Eine weitere Frage ist auch, ist es sinnvoll zwei Server zu benutzen? Der eine für das User-Management etc. und der andere für die Berechnungen und die Übermittlung der Daten für die visuelle Darstellung an die Clients.
Dann könnte ich einen normalen, gewarteten Server nehmen und einen dedicated als zweiten, der dadurch sicherer ist, dass keine Clients darauf zugreifen. Geht das überhaupt? Client sendet und empfängt von Server 1, aber empfängt nur von Server 2. Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?
Was meint ihr dazu?
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Jo, aber dann darfst du auch keine besondere Performance erwarten.Yogi hat geschrieben:Da wäre also erst einmal die OS Frage zu klären. Ich halte Debian 4 für eine gute Wahl, muss mich da aber erst einmal einlesen. Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.
Postgres. Spätestens wenn du Tabellen bearbeitest, deine Datenbank replizieren willst etc. wirst du bereuen es nicht zu verwenden.Yogi hat geschrieben:Als Datenbank MySQL.
Und allen bereichten nach skaliert es nicht. Nimm etwas anderes.Yogi hat geschrieben:Als Server dachte ich an CherryPy, weil das anfangs einfacher einzurichten sein soll und weil ich später Apache vorschalten kann.
So schwer ist Apache nicht einzurichten (verglichen etwa mit der ätzenden Konfiguration von Lighty) und auf Debian gibt es Sicherheitsupdates dafür. Die letzte korrigierte Sicherheitslücke in Apache 2 war laut Security Archiv im August 2006, also sogar vor dem Release von Etch.Yogi hat geschrieben:Bei Apache habe ich Sorge vor den Konfiguration und den Sicherheitslücken.
Würde wohl zu SQLAlchemy raten. Es ist sicherlich komplizierter, aber kann auf lange sicht gesehen mehr (u.a. Sharding).Yogi hat geschrieben:Als ORM für die Datenbank dachte ich an SQLAlchemy oder Storm.
Mako, das ist schneller und recht gut betreut, vom gleichen Autor wie SQLAlchemy. Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML?Yogi hat geschrieben:Als Templating System dachte ich an Mako oder sogar Cheetah. Da ich anfänglich die Auswertung browserbasiert haben möchte, kann ich mit XML Systemen wie Genshi nichts anfangen.
asynchat/asyncore, Medusa, Allegra, Kamaelia.Yogi hat geschrieben:Tja und was die UDP und TCP betrifft dachte ich erst an Twisted, aber ich habe schon mehrfach lesen müssen, dass das eine ziemlich steile Lernkurve besitzt. Was gibt es noch als Alternative?
Manchmal muss man eben Kompromisse eingehen.Yogi hat geschrieben:Bei allen Paketen sollte gelten, einfach in der Anwendung aber belastbar und bewährt.
Schätze das hängt von der Netzwerkanbindung zwischen den Servern ab.Yogi hat geschrieben:Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
-
BlackJack
@Yogi: Zu dem "jeder sagt was anderes" würde ich sagen: Fang erst einmal an und geh' davon aus, dass Du eh eine Menge 2 bis 3mal neu schreiben wirst, wenn das alles noch komplettes Neuland für Dich ist.
Du könntest zum Beispiel erst einmal auf CherryPy aufsetzen und das Wissen, dass Du den Server später vielleicht noch einmal wechseln wirst, dazu nutzen die Logik sauber vom Rest zu trennen.
Du könntest zum Beispiel erst einmal auf CherryPy aufsetzen und das Wissen, dass Du den Server später vielleicht noch einmal wechseln wirst, dazu nutzen die Logik sauber vom Rest zu trennen.
@Leonidas:
Bei CherryP habe ich aber den Anfangsvorteil eines schell aufgesetzten Servers und dass ich von da aus immer noch Apache mit ins Boot nehmen kann.
Aber vielleicht nimm ich erst einmal ein WAMP für den Anfang und taste mich langsam vor....?
@BlackJack:
Gerade der Anfang ist ja das schwerste. Ich kann mich vor lauter Angeboten nicht entscheiden und natürlich möchte ich nicht komplett meine Entscheidungen mitten während der Testphase revidieren müssen.
Wenn erst einmal mehrere Leute das System nutzen und ich muss dann alles neu machen bzw. eine längere Auszeit einläuten ist das nicht so optimal.
Ich möchte, glaube ich vor allem keine Sackgassen-Lösung, wenn das überhaupt machbar ist....??
Wie meinst du das?Jo, aber dann darfst du auch keine besondere Performance erwarten.
Ok, werde ich checken.Postgres
Bei CherryP habe ich aber den Anfangsvorteil eines schell aufgesetzten Servers und dass ich von da aus immer noch Apache mit ins Boot nehmen kann.
Aber vielleicht nimm ich erst einmal ein WAMP für den Anfang und taste mich langsam vor....?
Dann ziehe ich mir mal die Doku rein, wenn ich keine Zugang dazu finde, teste ich mal Storm.Würde wohl zu SQLAlchemy raten.
Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann, aber vielleicht irre ich mich da auch.Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML
Checke ich mal durch, gibts da eine besondere Empfehlung?asynchat/asyncore, Medusa, Allegra, Kamaelia.
@BlackJack:
Gerade der Anfang ist ja das schwerste. Ich kann mich vor lauter Angeboten nicht entscheiden und natürlich möchte ich nicht komplett meine Entscheidungen mitten während der Testphase revidieren müssen.
Wenn erst einmal mehrere Leute das System nutzen und ich muss dann alles neu machen bzw. eine längere Auszeit einläuten ist das nicht so optimal.
Ich möchte, glaube ich vor allem keine Sackgassen-Lösung, wenn das überhaupt machbar ist....??
-
gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Yogi!
Das kostet aber auch Rechenleistung und erschwert dir, die volle Performance aus dem Datenbankmanagementsystem raus zu kitzeln. Bei deiner Anwendung empfehle ich dir recht viel (Prozeduren, Trigger, Funktionen,...) direkt auf dem Datenbankserver PostgreSQL zu erledigen.
mfg
Gerold
Du wirst während der Entwicklung keinen Unterschied merken.Leonidas hat geschrieben:Jo, aber dann darfst du auch keine besondere Performance erwarten.Yogi hat geschrieben:Am liebste würde ich gerne während der anfänglichen Entwicklung unter Windows bleiben, sofern das möglich ist.
Postgres!Leonidas hat geschrieben:Yogi hat geschrieben:Als Datenbank MySQL.Leonidas hat geschrieben:Postgres.
CherryPy ist sauschnell, nimmt dir viel Arbeit ab und in Verbindung mit dem Apachen ein absoluter Sprinter. Du wirst nichts besseres finden was so einfach zu verwenden ist.Leonidas hat geschrieben:Und allen bereichten nach skaliert es nicht. Nimm etwas anderes.Yogi hat geschrieben:Als Server dachte ich an CherryPy
ORMs sind eine zusätzliche Schicht zwischen der Datenbank und deinem Programm. Das ist für einfache Programme vielleicht ein Vorteil für Leute, die mit SQL nichts anfangen können.Yogi hat geschrieben:ORM für die Datenbank
Das kostet aber auch Rechenleistung und erschwert dir, die volle Performance aus dem Datenbankmanagementsystem raus zu kitzeln. Bei deiner Anwendung empfehle ich dir recht viel (Prozeduren, Trigger, Funktionen,...) direkt auf dem Datenbankserver PostgreSQL zu erledigen.
Daten übertragen dauert immer seine Zeit. Aber auch das Raussuchen der Daten aus der Datenbank. Noch dazu greift der Computer dafür auf die Festplatten zu. Und Prozessorleistung wird auch verbraten. All das kannst du damit auslagern und die Rechenzeit in der Zwischenzeit für andere Anfragen verwenden. Und sobald die Daten vom Datenbankserver angekommen sind, schickst du sie zum Client.Yogi hat geschrieben:Die Daten von Server2 nach Server1 und dann zum Client dürfte wohl zu lange dauern, oder?
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo Yogi!
Trenne die Darstellung vom Programm!!!
Nimm auf jeden Fall eine Vorlagensprache. Welche, ist ziemlich egal. Hauptsache ist, dass du so gut wie keine Logik in die Darstellung verlagerst. So etwas **galt** vor einigen Jahren mit "Active Server Pages" noch als schick. Inzwischen hat man größtenteils eingesehen (sogar PHP-Entwickler haben sich weiterentwickelt), dass sich solche Programme sehr schwer erweitern/verbessern lassen. Von meinen ASP-Programmen existiert kein einziges mehr.
http://sqlmanager.net/products/postgresql/manager/
Die kostenlose LITE-Version kann zwar nicht so viel wie die Vollversion -- aber immer noch besser als nur mit PgAdmin arbeiten zu müssen.
mfg
Gerold
Und genau damit würdest du in eine Sackgasse fahren.Yogi hat geschrieben:Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann
[...]
Ich möchte, glaube ich vor allem keine Sackgassen-Lösung
Trenne die Darstellung vom Programm!!!
Nimm auf jeden Fall eine Vorlagensprache. Welche, ist ziemlich egal. Hauptsache ist, dass du so gut wie keine Logik in die Darstellung verlagerst. So etwas **galt** vor einigen Jahren mit "Active Server Pages" noch als schick. Inzwischen hat man größtenteils eingesehen (sogar PHP-Entwickler haben sich weiterentwickelt), dass sich solche Programme sehr schwer erweitern/verbessern lassen. Von meinen ASP-Programmen existiert kein einziges mehr.
Ich verwende unter Windows den SQL-Manager um PostgreSQL-Datenbanken zu entwickeln.gerold hat geschrieben:Bei deiner Anwendung empfehle ich dir recht viel (Prozeduren, Trigger, Funktionen,...) direkt auf dem Datenbankserver PostgreSQL zu erledigen.
http://sqlmanager.net/products/postgresql/manager/
Die kostenlose LITE-Version kann zwar nicht so viel wie die Vollversion -- aber immer noch besser als nur mit PgAdmin arbeiten zu müssen.
mfg
Gerold
Zuletzt geändert von gerold am Montag 24. März 2008, 17:02, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Ein Apache/Lighty/nginx/* wird ohnehin nur interessant, um der Python-Applikation selbst das Ausliefern von statischen Daten (Bilder, Videos usw.) abzunehmen, da Erstere darin entsprechend schnell sind.Yogi hat geschrieben:Bei CherryP habe ich aber den Anfangsvorteil eines schell aufgesetzten Servers und dass ich von da aus immer noch Apache mit ins Boot nehmen kann.
Ein einfacher Python-HTTP-Server (wsgilib, Paste, CherryPy, ...) reicht für den Anfang und läuft auf den gängigen Betriebssystemen. Später kannst du da nach Belieben etwas vorschalten und, im Falle einer WSGI-Anwendung, den Unterbau austauschen.Yogi hat geschrieben:Aber vielleicht nimm ich erst einmal ein WAMP für den Anfang und taste mich langsam vor....?
Ich dir auch. Rein mit SQL gegen ein spezielles DBMS zu programmieren, wäre mir sowohl zu umständlich als auch zu unflexibel. Optimieren kann man dann immer noch, und bzgl. der Erzeugung von angepassten Queries ist man mit SA auch sehr flexibel.Würde wohl zu SQLAlchemy raten.
Mir scheint, du verwechselst da was. Template Engines sollen primär die Präsentation auslagern, Code hat da im reinsten Sinne nichts drin verloren. Und ja, gerade wenn du Websites erstellen willst (sowohl mit XHTML als auch mit XML-gefütterten Flash-Applets) bietet sich Genshi aufgrund der XML-Orientierung an. Mako ist dennoch keine schlechte Wahl. Musst du selbst rausfinden, was dir besser gefällt (und ggf. eben später wechseln, das ist ja keine Schande, im Gegenteil).Yogi hat geschrieben:Ich denke, dass es in meinem Fall besser ist Python Code direkt eingebaut zu haben, da ich so eher so eine Art Browsergame realisieren kann, aber vielleicht irre ich mich da auch.Ich sehe allerdings dein Problem mit Genshi nicht, an welche Stelle stört dich XML
Dann habe ich ja für den Anfang eine vernünftige Basis:
Windows (später Debian) mit CherrPy, PostgreSQL, SQLAlchemy und Mako bzw. Genshi (da werde ich erst einmal das nehmen, wo ich mich wohler fühle und mal sehen).
Einzig was den Ersatz für Twisted betrifft (ist das wirklich overkill und so komplex? ) bin ich mir noch nicht sicher. Kamaelia ist wies aussieht nur für Linux, Allegra blicke ich noch nicht durch, Medusa wurde schon seit 2003 nicht mehr angepackt, und zu asyncore habe ich zumindest ein nettes Tut gefunden (asyncore Tut). Aber wo finde ich was zu der Verwendung der Protokolle UDP und TCP? Ich konnte nicht erkennen, dass die direkt in diesen Paketen unterstützt werden.
Windows (später Debian) mit CherrPy, PostgreSQL, SQLAlchemy und Mako bzw. Genshi (da werde ich erst einmal das nehmen, wo ich mich wohler fühle und mal sehen).
Einzig was den Ersatz für Twisted betrifft (ist das wirklich overkill und so komplex? ) bin ich mir noch nicht sicher. Kamaelia ist wies aussieht nur für Linux, Allegra blicke ich noch nicht durch, Medusa wurde schon seit 2003 nicht mehr angepackt, und zu asyncore habe ich zumindest ein nettes Tut gefunden (asyncore Tut). Aber wo finde ich was zu der Verwendung der Protokolle UDP und TCP? Ich konnte nicht erkennen, dass die direkt in diesen Paketen unterstützt werden.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Vor allem bei Mako solltest du dabei achten - und das haben Gerold und Y0Gi schon gemeint - dass du dort so wenig Python-Code wie möglichst einbaust. Das ist auch so schon eine gute Idee, da Templates mit eingebettetem Python-Code in den meisten Editoren absolut ätzend zu bearbeiten ist.Yogi hat geschrieben:Windows (später Debian) mit CherrPy, PostgreSQL, SQLAlchemy und Mako bzw. Genshi (da werde ich erst einmal das nehmen, wo ich mich wohler fühle und mal sehen).
Genshi hat den Nachteil das es langsamer ist und dass es (hauptsächlich) XML ist. Wobei letzteres je nach Anforderungen auch ein Vorteil sein kann. Ich nutze sowohl Genshi als auch andere, nicht-XML-basierte Templatesprachen und bin eigentlich mit beidem Recht zufrieden. Genshi ist besonders anfangs etwas ungewohnt.
Twisted ist gar nicht so schwer finde ich. Erfordert nur anfangs etwas Einarbeitungszeit, aber das ist es wohl auch Wert. asnycore ist der Teil von Medusa der es in die Stdlib geschafft hat, also solltest du dort mal reingucken. Medusa ist dann "the real thing" und da es nur das Grundgerüst bietet ist es auch nicht mehr nötig dort Sachen zu ändern (aber ich gebe zu, es wird nur von wenigen verwendet, Teils auch weil asyncore schon reicht). Allegra ist eine Art aufgebohrtes Medusa, von einem der gemeint hat Twisted gehe den falschen Weg.Yogi hat geschrieben:Einzig was den Ersatz für Twisted betrifft (ist das wirklich overkill und so komplex? ) bin ich mir noch nicht sicher. Kamaelia ist wies aussieht nur für Linux, Allegra blicke ich noch nicht durch, Medusa wurde schon seit 2003 nicht mehr angepackt, und zu asyncore habe ich zumindest ein nettes Tut gefunden (asyncore Tut). Aber wo finde ich was zu der Verwendung der Protokolle UDP und TCP? Ich konnte nicht erkennen, dass die direkt in diesen Paketen unterstützt werden.
Und die Protokollunterstützung für TCP und UDP (aber noch nicht SCTP *g*) kommt aus dem `sockets` modul. Das ist eine Ebene tiefer und wird von Python bereitgestellt und von allen aufgeführten Modulen im Kern benutzt. Da brauchst du dich auch nicht drum kümmern.
Also wenn ich so etwas machen sollte, würde ich mal sehen was für Anforderungen da sind. Wenn es einfach nur funktionieren soll, dann asyncore. Wenn es hingegen viele Features haben soll und auf einer stabilen Basis stehen soll dann Twisted. Wenn ich neue Wege ausprobieren wollte dann würde ich Kamaelia nehmen (mir persönlich ist Windows-Unterstützung in dem Fall ziemlich egal und auch dann könnte man einen Client für Windows schreiben der asyncore oder Twisted nutzt, wenn die Leistung von kamaelia auf dem Server stimmt).
Wie BlackJack sagte: erwarte nicht dass es beim ersten mal hinhaut. Manchmal ist es nötig Komponenten neu zu schreiben, weil man das inzwischen besser versteht, es neue Möglichkeiten gibt, weil die Wege die man eingeschlagen hat für die Tonne sind oder weil der ursprüngliche Code nicht wartbar ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ok, ich glaube jetzt komme ich erst einmal weiter. Ich muss mir noch überlegen, ob ich mir direkt Twisted antue, oder erst einmal den sanfteren Weg gehe um etwas mehr Übung zu bekommen.
Ihr hab mir schon mal sehr geholfen. Ich halte euch auf den laufenden, auch wenn alles bei mir etwas länger dauert, da ich nur abends nach Kinderjob und total erschöpft arbeiten kann, aber wofür gibt es denn Urlaub
Ihr hab mir schon mal sehr geholfen. Ich halte euch auf den laufenden, auch wenn alles bei mir etwas länger dauert, da ich nur abends nach Kinderjob und total erschöpft arbeiten kann, aber wofür gibt es denn Urlaub
Round and round and round we go.... warum gibt es in Python immer so viele Möglichkeiten? Ich kann doch nicht erst einmal alles jahrelang durchtesten??
Aber gut, teste ich auch mal an oder haben da schon andere Erfahrungswerte damit??
Aber gut, teste ich auch mal an
oder haben da schon andere Erfahrungswerte damit??