<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>SuchtSim schrieb am 04.02.2004 19:04
die aktuelle beta ist aber 0.3.4<hr></blockquote></p>
Ähm ja, du hast natürlich recht, irgendwie scheint das mangels Ankündigungen auf der Hauptseite bzw. Auflistung in der Downloadsection ziemlich an mir vorübergangen zu sein.
Die Updates inzwischen waren aber auch eher kosmetischer Qualität, glaub ich, aber ich werds auch mal testen in den nächsten Tagen

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>SuchtSim schrieb am 04.02.2004 19:04
könnte höchstens am schlechten ip-management von windows liegen. das ist nämlich alles andere als fürs internet optimiert. (so sind z.b. die packete viel zu gross dafür).
aber soweit hat das kaum einfluss...ausserdem hat bei mir ja zumindest die eine seite auch windows am laufen.<hr></blockquote></p>
Naja, die voreingestellten Settings verwende ich seit ~5 Minuten nach der Installation nicht mehr
Hab mit diversen MTUs etc. experimentiert, Veränderungen gabs keine wesentlichen.

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>SuchtSim schrieb am 04.02.2004 19:04ihr habt doch auch alle anderen netzwerkaktivitäten eingestellt, oder? (die frage ist so blöd/rethorisch, dass ich mich fast gar nicht traute, sie zu stellen )<hr></blockquote></p>
*g*
Aber die Frage is schon berechtigt, irgendwie

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>SuchtSim schrieb am 04.02.2004 19:04
die warppipe-fuzzies sollen das teil gefälligst unter die gpl schmeissen. dann könnten wir viel einfacher prüfen, woran die lags genau liegen und auch selbst individuelle optimierungen implementieren...<hr></blockquote></p>
Naja, früher liefs ja über SourceForge, dann gabs allerdings Probleme mit den Entwicklern dieser Lan-&gt;Online-Software für die XBOX (mein Namensgedächtnis ist suboptimal, ja) und auch SourceForge selbst, glaub ich, wg. der Verwendung der Server zum Verbreiten der Files.
Naja, solang die Devs was machen und das Ding nix kostet, kann ich einigermaßen damit leben. Den Source freizugeben wäre aber sicher ein netter Schritt, wo man sich doch eh schon ziemlich als Pionier etabliert hat.

das dachte ich mir schon.

es ist ja auch nicht so, dass eine optimierung der sockets gleich eine offenbarung wäre. aber dass windows standardmässig eben nicht optimal eingestellt ist, will trotzdem mal gesagt sein. nämlich weil ich nach einer erklärung suche

afaik ist die 0.3.4 dasselbe wie 0.3.3 mit einigen bugfixes und dem feature, dass kein udp-forwarding mehr nötig ist.

was soll es da für probleme mit opensource gegeben haben? wenn die xlink-entwickler denselben code weiterverwenden (und ihn selbst unter die gpl stellen), dann ist das sowohl legal wie auch im sinne von open source. das ist ja (unter anderem) der sinn der gpl.
und sourceforge sollte eigentlich auch keinen stress machen, wenn man diese server für die verbreitung von gpl-files verwendet. dazu sind die schliesslich da.
ich glaube, ich muss mal im warppipe-forum rumstöbern...

Hmm ja, stimmt schon.

Die Probs mit den xlink-Typen (Danke ;)) waren afaik, dass diese _angeblich_ Sources von den Warppipe-Devs verwendet, für eigenen ausgegeben und nicht weiter veröffentlicht haben, was ja nicht den Vorstellungen der GPL entspricht.
Nach diversen 'Diskussionen' mit den Leuten von xlink würde das Projekt eben von Sourceforge genommen, ohne jedoch die Downloadmöglichkeiten über die SF-Server zu unterbinden, was wiederum Probs mit den Betreibern ebendieser Server brachte.

Soweit halt mein Wissensstand.

das problem ist natürlich, dass es sich ohne irgendwelche gerichtsbeschlüsse kaum beweisen lässt, dass jemand opensource-code in seinem closed-source-projekt verwendet. ausserdem wird effizienter code eines projektes, das sich noch in einem relativ simplen anfangsstadium befindet, sich schon von natur aus nicht grossartig vom quelltext einer opensource-alternative unterscheiden.

es gibt ja auch vermutungen, dass nintendo selbst gegen die gpl verstösst: der nes-emulator für die gba-e-cards in japan hat nämlich eine bis ins detail gehende auffällige ähnlichkeit mit dem nes-emulator für gba-flashcards.
unmöglich zu beweisen, denn wenn man das gerichtlich durchsetzen will, muss man selbst erstmal glaubwürdig darlegen können, dass diese gpl-software lediglich für nes-homebrew-spiele /-programme verwendet wird.

angeblich haben sich die warppipe-entwickler aus "diversen gründen" für closed-source entschieden. mehr konnte ich nicht rausfinden, die threads scheinen schon recht verschollen zu sein und gerne wird auch nicht darüber gesprochen, weshalb es kaum informative threads aus jüngerer zeit gibt.
ein argument sei die effizenz. diese entscheidung liegt natürlich bei den entwicklern, aber ganz allgemein gesagt halte ich dieses argument für unhaltbar. meiner erfahrung nach entwickeln sich gpl-programme nämlich bedeutend schneller, effizenter und vielseitiger als closed-source-geschichten, wo jeder auf den guten willen der wenigen entwickler angewiesen ist und nix selbst in die hand nehmen kann. (man betrachte nur mal die rasante entwicklung des mplayers, wo es zeitweise täglich mehrere neue cvs-versionen gab und man nach dem melden eines nicht funktionierenden codex sicher sein konnte, dass noch am selben abend das problem behoben sein würde *schwärm*)

Klar, lässt sich das kaum beweisen. Im Endeffekt waren auch keine gerichtlichen Entscheide oder juristische Spitzfindigkeiten ausschlaggebend, sondern diverse Anfeindungen der Entwickler in den Foren des jeweils andren Teams (-&gt; 'diverse Gründe').
Dass einiges an Threadmaterial diesbezüglich gelöscht wurde, davon gehe ich aus

Diese Begründung, von wegen höherer Effizienz etc., kann ich auch nicht nachvollziehen, zumindest für die Entwickler selbst ergibt sich dadurch ja kein Mehraufwand, aber man wird wohl vorerst damit zufrieden sein müssen.

warppipe 0.3.5 ist seit gestern verfügbar.
hat es schon jemand getestet?

soweit ich gelesen habe, soll inzwischen so ziemlich das maximum an geschwindigkeitsoptimierung erreicht worden sein.
die entwickler haben auch damit experimentiert, einige packete zu droppen und am anderen ende wieder "hinzuzufaken" - müsste bei leicht schlechterer genauigkeit (abfragen "nur" noch in 33milisekunden-abständen) einen enormen speedzuwachs ergeben (meinen berechnungen zufolge müsste dann ein 120er-ping für fullspeed reichen). leider verlieren die cubes dann sofort ihre synchronisation mit dem ergebnis, dass das testspiel bei dem einen cube auf einer anderen strecke ablief als auf dem anderen.
sieht leider so aus, als hätten sie diesen sehr vielversprechenden ansatz nun begraben. es müsste doch eigentlich möglich sein, das protokoll auf sync-informationen hin zu untersuchen und diese entsprechend zu simulieren. mit einem gemeinsamen ntp-server dürfte das hinzukriegen sein...

ich würde mich wirklich gerne selbst reinhängen...aber eben...