From: Mark Seuffert (Pirates) (captain_at_pirate.de)
Date: 06. Feb 2002
Hai Alexander!
Alexander Holler schrieb am 5 Feb 2002, (you wrote):
> > http://www.gnutellaforums.com/showthread.php?s=&threadid=7723
>
> Wenn ich den Artikel richtig gelesen habe, willst du eher das Pattern
> Proactor anstatt Reactor nehmen.
Ich muss zugeben dass ich beide Designpatterns nicht kenne, ich dachte
Reactor passt besser? Na, muss ich nochmal genauer durchlesen.
> zum Thema Speicherverwaltung kleinerer Blöcke usw. gibt es bereits
> massenweise Literatur, Implementationen dazu findet man z.B. in Loki oder
> in der Boost-Library.
Hast Du ein paar gute Links oder Lust etwas Text zu schreiben dem ich dem
Artikel hinzufügen soll?
> Und zum Thema MTU denke ich irgenwie immer wieder,
> daß der ganze Aufwand vernachläßigbar ist. Und wenn dann noch das Stichwort
> Firewall kommt, erst recht. Denn wenn ne Firewall da ist, die evtl. auch
> noch auf Proxys bzw. Socks basiert, ist der ganze MTU-Krempel eh nur bis
> zur Firewall gültig. Die macht dann wiederum was sie will. ;)
Ja.... ich bin jedoch der Meinung nur ein möglichst guter Eingangszustand
macht einen guten Ausgangszustand. Im Artikel ist nur die ganze Erklärung
der ganzen TCP/IP Hintergründe lang, die Implementierung ist einfach: Es
beschränkt sich auf einen 3*MSS Sendbuffer + Aufruf von Send() mit einer
3*MMS Größe, falls möglich. Aufruf von Receive() natürlich so groß wie
sinnvoll, Richtlinie 1*MMS. Das war's IMHO um TCP/IP möglichst effektiv zu
nutzen. Mir war es wichtig dass man die Hintergründe was passiert genau
kennt und die zugrundeliegenden Mittel (TCP/IP) richtig nutzt.
> Irgendwie denke ich, daß du dein "superpeer" von der falschen Seite
> angehst. Zuerst implementiert man ein gutes, flexibles und solides Konzept,
> und wenn das dann läuft, fängt man an zu optimieren (daher das flexibel).
Ich dachte genau das mach ich: eine sehr lange und ausführliche
Designphase vor der Implementierung. Nach einer stabilen Grundlage für
meine Zielsetzung habe ich versucht alle Schwachstellen zu finden und
Lösungen vorgeschlagen (CPU-Optimierung, Speicher-Optimierung, TCP-
Optimierung, Firewall-Optimierungen). Testimplementationen und Profiling
für die einzelnen Optimierungen stehen noch aus. Ist meine Zielsetzung
oder Vorgehensweise falsch, was kann ich besser machen?
> Im vorliegendem Fall würde ich z.B. ne Klasse fuer das Msg-Handling nehmen,
> der ich später dann anstatt new einen anderen Allocator verpasse (s. z.B.
> SmallObjects von loki).
Sorry, hab ich nicht verstanden, bzw Smallobject kenn ich nicht.
> Mal abgesehen davon, mich würde interesieren für welche Leitungsgrößen bzw.
> Clientanzahl denn dein "superpeer" gedacht ist. Wenn der nur mit
> DSL-Leitungen oder ähnlich "kleinen" Leitungen operiert, ist das der ganze
> Aufwand des Optimierens bei den heutigen Rechnern meiner Meinung nach eh
> nur als "theoretisch interessant" zu betrachten. ;)
Ich dachte an einen Superpeer/Applicationproxy mit einigen hundert Clients.
Ich will das Beste erreichen was möglich ist, mir macht's Spass. Diese P2P
Netzwerke erinnern mich immer an die STartrek Voyager Folge wo 7of9 über
ein chaotisches verteiltes interstellares P2P Satelitten-Netzwerk
Informationen gesaugt hat, Terrabytes, die Sau. :)
-- Mark "Moak" Seuffert, Pirates Technologies, http://www.pirate.de . . . . . . . . . . . . . _.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(._.´(.Wenn Du in ein Kaninchenloch "Ist jemand zu Hause" hineinrufst und eine Stimme "Nein" antwortet, dann bedeudet das wahrscheinlich dass Du nicht willkommen bist. (Pu der Baer)
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET