NSURLConnection und 404

Tom ist ein RunLoop quäler!

Und es ist auch immer die Frage wieviel tausend Connections du gerade hast

und übrigens gibts im Zeitalter der 65536 Core Prozessoren nichts was nicht in einen Thread gehören würde

Wobei mir nicht ganz klar ist, warum weniger gequält wird, wenn man das auf verschiedene Threads und verschiedene Run-Loops verteilt. (Ganz sicher quält man sich damit selber. ;-))

hmmmm, grummel

jo, ich hab die letzte Zeit ziemlich intensiv mit Sockets und Connections gekämpft bzw. gekotzt und probiert.

Aber (ich sprech jetzt von nem Server) ohne Threading hat mein TCP Server den ich von 3 Clients übers Netz gespammt habe maximal 30 sec ohne Klemmer getan. Dabei haben die Clients im abstand von 0.3 - 0.7 Sekunden gefeuert.

Meine jetzige Version mit Threading hatte ich in unserem Schulungsraum von 10 Clients gespammt die in einer Endlosschleife ohne Pause feuerten - lief Sonntag bis Montag durch

Du kannst natürlich client anfragen losschicken wie du willst, wenn du server und client aud der selben Maschine hast, passiert da auch nichts, aber einen Server ohne Threads zu implementieren...

Ich kann das ja wirklich nicht beurteilen. Aber deine Probleme schienen dann doch woanders zu hängen, wie sich später herausstellte?

Ich verstehe ehrlich gesagt wirklich nicht, warum ihr euch von Threads ein besseres Laufzeitverhalten versprecht. Threads sind doch nicht zur Performance-Steigerung, sondern zur Verhinderung von Blocks da. Und angesiichts der Länge der Delegate-Methoden, kann ich die Gefahr nicht erkennen.

Ist der Rechner ausgelastet, so ist er so oder so ausgelastet. Daran ändern Threads doch nichts.

Ok, jetzt verstehe ich das MIssverständnis.

Nein, du schießt die Connections wie blöde, bis die CPU abdampft. Einfach aus dem Code heraus. Hierzu benutzt du jeweils ein eigenes Objekt, welches die Connection verwaltet, die Delegates implementiert und sich ein paar Infos merkt. (Etwa: "Wer bin ich? Was will ich? Muss ein Mann nur ein Buch schreiben oder auch einen Sohn zeugen?")

Irgendwann sind die Daten bei dir vollständig angekommen. Jetzt ist die Connection beendet. *Dann* startest du einen Thread, der den Scan der Seite macht. Das sollte gethreaded sein, weil in der Tat hier ein Block droht, wenn du mal 0,5 Sekunden benötigst um so eine Porno-Seite mit 1000 Links zu scannen. Da muss die CPU ja möglicherweise mal kurz zwischendurch auf Toilette.

Aber das *Abholen* der Daten muss nicht gethreaded werden. Ich sehe jedenfalls nicht, warum. Und du ersparst dir damit die Kombination von Event-Loop und Threads, die nicht einfach ist. Irgendwo schreibt auch Apple, dass man selten eine Event-Loop in einem Thread benötigt. Es sind ja zwei verschiedene System für ein Ziel: Quasiparallelität.

Hmm, hast du eigentlich das mit meinen Cocoa-Sockets noch eingebaut? Habe ich das noch eingebaut? Ist das jedenfalls noch in die Auflage gekommen?

Na, der Kot, den ich damals im Weißbräu geschrieben habe, der Mini-Server.

Das war an dem Tag, an dem du erkältest warst und ich dein Bier mittrinken musste. (Du Schwein, du!)

Genau, das war der Tag, an dem du argv[0] zerschossen hast.

Tssss, tsss,s tssss, wenn man ein Kunstwerk nicht versteht, sollte man es nicht verurteilen.

Ich habe ja einen normalen Socket verwendet, die Routiine zum Anlagen stammte ja sogar von dir, wenn ich mich nicht irre.

Ja, ja, der ist dort erklärt. Aber die erste Auflage hieß ja auch "C und Unix".

Also ich glaube wir reden hier vielleicht etwas aneinander vorbei.

Ich würde auch sagen, das du so viele CLIENT anfragen wie du willst in einen Thread, auf eine Runloop packen kannst. Das habe ich ja auch gemacht, die Stresser die auf den Server ballern Threaden die Anfragen nicht, die werden einfach in einer Schleife erstellt. Ist der Netzwerkstack mal überlastet, halten die einfach an, bis wieder "Luft" ist.

Im SERVERBETRIEB scheint es allerdings sehr Problematisch zu sein alles in eine RL zu plazieren, wo auch noch der Listener deines Sockets drauf ist. Wenn diese RL Blockt, hast man wohl ein kleines Problem. Ob du jetzt jede Connection in einen eigene Thread handelst oder dir einen Thread erzeugst der dann alle Connections handelt dürfte ziemlich egal sein - Hauptsache deine Callbackfunktion bekommt so schnell wie möglich den "Kopf frei".

In der Praxis konnte ich den Server schon zum Absturz bringen, indem ich zwei Clientanfragen, aus einer Anwendung heraus, "gleichzeitig" über einen NSTimer abgefeuert habe.

Aber deine Probleme schienen dann doch woanders zu hängen, wie sich später herausstellte?

Nein. Die Probleme traten auf weil ich die Streams von meinem TCP Server an den Thread übergeben hatte und das dem System wohl garnicht schmeckt (obwohl sie noch nicht in einer RunLoop waren) was dann wohl (unter 10.4) zu diesen satten Abstürzen beim Initialisieren der RunLoop geführt hat. Allerdings lief auch schon diese Variante deutlich stabiler als ohne Threads (was das debuggen etwas zäh machte).

Nachdem ich allerdings den Sockethandler an den Thread übergeben habe und die Streams dann komplett in neuen Thread initialisiert hab, lief die Kiste.

Die frage OB ich Threads nehme war also schnell mit ja beantwortet, lediglich die Frage wie ich die Threads erzeuge hat etwas mehr Arbeit gemacht.

Original von seb2
kressevadder, ich weiß ja nicht, ob Du mal drüber gestolpert bist, aber meiner Meinung nach die beste -- und gleichzeitig noch erfreulich kurze -- Einführung in Sockets ist die hier: beej.us/guide/bgnet/

sieht wirklich super aus, jedenfalls beim ersten überfliegen