Die "richtige" Komponente für TCP unter iOS

[idontknow]

Hallo Community,

ich frage mich gerade, mit welcher Komponente ich von iOS aus auf einen Server zugreifen kann.
Das ganze soll sicher und schnell sein, der Client soll Kommandos an den Server senden können auf die dieser dann mit binären Daten (Jpegs) oder mit Text antwortet.

Wäre es ein Windows-Client würde ich Indy oder ICS nehmen, beides funktioniert prima.

Unter iOS habe ich nun angefangen mich zunächst mit Indy zu beschäftigen.
Indy wird im Embarcadero-WIKI beschrieben, das scheint somit der offizielle Weg zu sein?
Damit OpenSSL unter iOS funktioniert, muss ich offenbar u.a. die Bibliothek libcrypt.a herunterladen und statisch einbinden, das Embarcadero-WIKI verweist hierzu auf https://github.com/st3fan/ios-openssl, wo man mit den Worten

Zitat:

OpenSSL for iOS
I urge you to not use this project"

empfangen wird.
Hm, da wird dann wohl was dran sein, wäre also wohl eine Sackgasse für eine Neuentwicklung.

Was verwendet ihr?

[QuickAndDirty]

Ich nutze die TIDhttp komponente um mit einem Soap server über ssl zu kommunizieren. Funktioniert einwandfrei auf Windows, IOS und Android.
Allerdings habe ich die Kommunikation selbst nicht programmiert... ich lasse den ganzen code von Delphi generieren.

[TurboMagic]

Ist SOAP http oder TCP?

[hoika]

Hallo,
http.

[idontknow]

https wäre schon in Ordnung, vielleicht hätte ich TCP in der Überschrift weglassen sollen... Mir geht es im Moment eigentlich nur darum, daß eine iOS-App auf sichere Art und Weise auf einen Windows-Server zugreifen können soll. Was den Server angeht bin ich ebenfalls vollkommen frei, wie und womit ich ihn realisiere. Da ist noch nix vorhanden...

Zur Antwort: TIdHttp wäre ja Indy, sprich: möglicherweise unsicher, weil von OpenSSL unter iOS vom Entwickler der Lib abgeraten wird und da keine Entwicklung mehr stattfindet?? Funktionieren wird das wohl, aber sollte man damit eine neue Entwicklung anfangen?

Ich habe gestern begonnen, mich mit
- TRESTClient auf iOS-Seite in Verbindung mit
- TSslHttpServer (ICS) auf Windows-Seite auseinanderzusetzen.

TRestClient funktioniert out-of-the-box unter iOS. Allerdings habe ich es mit der Kombination TRestClient/TSslHttpServer noch nicht geschafft, TLS1.3 zu verwenden, obwohl auf beiden Seiten eingestellt (Oh, ich muss einschränken: Bisher nur wegen der schnellen Compiler-Zeiten unter Windows getestet, da ging es nur mit TLS 1.2. Unter iOS kann ich da noch gar keine Aussagen treffen).

Na, Montag probiere ich es weiter... Wenn hier jemand schon eine Idee zu hat, gern her damit :-)

[mjustin]

Es gab neulich einen ähnlichen Thread hier im Forum, dort wurden zwei kommerzielle Lösungen genannt die Indy auch für iOS einsetzbar machen (oder eigene Clients für TLS/SSL enthalten):

https://www.delphipraxis.net/211132-...ohne-indy.html

(Disclaimer: ich habe keines der dort genannten getestet / verwendet, und bin mit den Unternehmen nicht 'verwandt')

[Papaschlumpf73]

Und was ist mit TNetHttpClient?

[mjustin]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1510863)

Und was ist mit TNetHttpClient?

TCP ist ja nicht nur für HTTP gemacht, sobald E-Mails (SMTP, POP, IMAP) oder andere Standard- oder proprietäre Protokolle über TCP eingesetzt werden müssen, ist NetHTTPClient ungeeignet. Dann muss stattdessen oder zusätzlich noch eine TCP Komponente verwendet werden.

[TurboMagic]

Zitat:

Zitat von idontknow (Beitrag 1510837)

Ich habe gestern begonnen, mich mit
- TRESTClient auf iOS-Seite in Verbindung mit
- TSslHttpServer (ICS) auf Windows-Seite auseinanderzusetzen.

TRestClient funktioniert out-of-the-box unter iOS. Allerdings habe ich es mit der Kombination TRestClient/TSslHttpServer noch nicht geschafft, TLS1.3 zu verwenden, obwohl auf beiden Seiten eingestellt (Oh, ich muss einschränken: Bisher nur wegen der schnellen Compiler-Zeiten unter Windows getestet, da ging es nur mit TLS 1.2. Unter iOS kann ich da noch gar keine Aussagen treffen).

Na, Montag probiere ich es weiter... Wenn hier jemand schon eine Idee zu hat, gern her damit :-)

TLS 1.3 kann auch an Windows liegen. Da war zumindest Mal was.

[Papaschlumpf73]

Zitat:

Zitat von mjustin (Beitrag 1510866)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1510863)

Und was ist mit TNetHttpClient?

TCP ist ja nicht nur für HTTP gemacht, sobald E-Mails (SMTP, POP, IMAP) oder andere Standard- oder proprietäre Protokolle über TCP eingesetzt werden müssen, ist NetHTTPClient ungeeignet. Dann muss stattdessen oder zusätzlich noch eine TCP Komponente verwendet werden.

Idontknow schrieb weiter oben, dass https in Ordnung sei und TCP für die Überschrift nicht so geeignet war.