Ich versuche, ein einfaches Beispiel zu bekommen, das mit GCDAsyncSocket arbeitet, und entdecke, dass mir bestimmte Teile des Verständnisses fehlen, und hoffe, dass Sie mit guten Leuten dazu beitragen können, dies zu erklären.
Ich habe das GCDAsyncSocket-Zeug unten eingerichtet:
%Vor%Und meine Socket-Test-Server-App kann die Zeichenfolge
empfangen"Testen ... 123 ... \ r \ n"
Aber wenn ich dann meinen Socket-Testserver eine Zeichenfolge zurücksende, erwartete ich naiv, dass der didReadData Delegat ausgeführt wird
%Vor%Aber die kalte, harte Realität zwang mich, das zu lernen, bis ich anrufe
%Vor%... der didReadData Delegat wird nicht aufgerufen.
OK, das ist in Ordnung. Ich verstehe es.
Lesen Sie auf der Dokumentation noch einmal, dass
eindeutig angegeben istAsyncSocket ist eine RunLoop-basierte TCP-Socket-Bibliothek.
Nun schaue ich mir also dieses RunLoop Ding an, das meiner Ansicht nach wie das Nachrichtenschleife in Microsoft Windows . Da iOS eine Event / msg-gesteuerte Architektur ist (genau wie Win32), hat der Standard-Haupt-Thread, in dem ich mich gerade befinde, offensichtlich eine eigene msg-Schleife, um mit Ereignissen umzugehen.
Meine Verwirrung ist jetzt, dass iOS RunLoop wie eine separate Entität erscheint, mit der ich arbeiten muss, damit GCDAsyncSocket richtig funktioniert.
Wenn angegeben wird, dass der Standardlaufmodus für die Ausführungsschleife NSDefaultRunLoopMode ist, der sich im Hauptthread befindet.
Verwirrt noch?
Unter Win32 würde mein COM-Ereignisbehandlungscode so aussehen:
%Vor%Es wäre natürlich in einem eigenen Thread (habe noch nicht mit GCDAsyncSocket dorthin gekommen), aber das wäre in gewisser Weise sein eigener "RunLoop".
Wie mache ich das Gleiche mit GCDAsyncSocket , damit ich nicht in einer Abfrageschleife stehe, die die Warteschlange mit [asyncSocket readDataWithTimeout] Aufrufen füllt?
Ich denke, wir brauchen bessere Beispiele für die Verwendung dieser Bibliothek.
Ok, ich habe das irgendwie funktioniert.
Lassen Sie mich wissen, ob dies bestimmten "Best Practices" widerspricht.
%Vor%Dann ... wenn Daten reinkommen ...
%Vor%Damit erhalten Sie den RunLoop-Vorgang, ohne Timer oder andere Konstrukte zu verwenden. Und kann in einem eigenen Thread enthalten sein. (das ist immer noch TBD)
Ich weiß, dass dies eine alte Frage ist und habe bereits eine akzeptierte Antwort, aber hier ist meine Lösung, die ich bereits in einer meiner Apps verwendet habe:
Nach dem Verbinden mit einem Host führen Sie die folgende Dispatch-Warteschlange aus:
%Vor%Sie könnten dieselbe Warteschlange verwenden, um eine Heartbeat-Anforderung zu senden, nur um die Verbindung aufrechtzuerhalten.
Tags und Links cocoaasyncsocket runloop