2017-06-20 6 views
1

Ich habe versucht, ein mehrteiliges Formular Daten mit Alamofire zu implementieren. Ich habe einen Code erstellt und er funktioniert hervorragend für Anfragen, die weniger als 60 Sekunden dauern. Wenn jedoch die Anforderung mehr als das nimmt, es endet und der Upload nicht beendet:MultipartFormData Upload mit Alamofire

Variables view

Auch ich bin immer diese Ausgabe (wahrscheinlich bedeutet, dass mein App in einem geschlossenen TCP-Socket zu schreiben versucht,):

2017-06-20 17:22:21.924948 app[4645:1381848] [] nw_endpoint_flow_prepare_output_frames [110.1 10.39.80.102:8550 ready socket-flow (satisfied)] Failed to use 1 frames, marking as failed

2017-06-20 17:22:21.928262 app[4645:1381848] [] nw_endpoint_handler_add_write_request [110.1 10.39.80.102:8550 failed socket-flow (satisfied)] cannot accept write requests

2017-06-20 17:22:21.929278 app[4645:1381027] [] __tcp_connection_write_eof_block_invoke Write close callback received error: [22] Invalid argument

ich habe bereits die URLSessionConfiguration zu ändern versucht, dass ich die Anfrage auszuführen bin mit durch die timeoutIntervalForRequest und timeoutIntervalForResource Parameter ändern:

func initManager(timeoutInterval:Double) { 

    let configuration = URLSessionConfiguration.default 

    configuration.timeoutIntervalForRequest = timeoutInterval 
    configuration.timeoutIntervalForResource = timeoutInterval 

    alamofireManager = Alamofire.SessionManager(configuration: configuration) 
} 

Allerdings bekomme ich immer noch das gleiche Problem. Weiß jemand, wie man das löst? Oder hat jemand das gleiche Problem?

Dank

Antwort

1

Sie können eine maximale Ausführungszeit auf der Server-Seite schlagen werden. Das heißt, ich denke, es gibt auch einen Fehler in iOS 10.0 - 10.2.x, der dieses Fehlverhalten verursachen kann. (Mehr unter https://forums.developer.apple.com/thread/67606.)

Auch wenn Sie die Ursache für dieses spezielle Problem beheben, ist das grundlegende Problem hier ein Design-Problem, kein Problem mit einer Anfrage an sich. Netzwerke sind unzuverlässig und Mobilfunknetze doppelt so. Die Wahrscheinlichkeit, eine Mobilfunkverbindung länger als eine Minute aufrecht zu erhalten, entspricht ungefähr der Wahrscheinlichkeit, im Lotto zu gewinnen. (Ja, das ist Hyperbel, aber Sie bekommen die Idee.)

ich folgende alternativen Ansatz vorschlagen würde:

  • A POST oder PUT-Endpunkt, der einen Dateinamen nimmt, einen Strom von Daten und einen optionalen Offset um die Bytes zu schreiben.
  • Ein separater POST-Endpunkt, der die über den oben genannten Endpunkt hochgeladene Datei verarbeitet.
  • Ein separater GET-Endpunkt, der die aktuelle Größe der angegebenen Upload-Datei zurückgibt.

Dann, auf der Client-Seite, starten Sie den Upload. Wenn der Upload aus irgendeinem Grund fehlschlägt, geben Sie am Endpunkt der Dateigröße ein GET aus und geben ein neues POST mit dem Offset aus, der auf das erste Byte nach der Dateilänge festgelegt ist (und natürlich nur den letzten Teil der Uploaddaten bereitstellt).

Dadurch wird verhindert, dass ein einzelnes Byte des Uploads verloren geht, wenn die Verbindung aufgrund eines Fehlers in iOS, einer Serverfehlkonfiguration oder eines zufälligen Netzwerkfehlers fehlgeschlagen ist. Noch besser, es wird wahrscheinlich auch mit Hintergrund-Upload in NSURLSession akzeptabel funktionieren.

+0

Dank @dgatwood. Ich habe völlig vergessen, dir zu antworten. Du hattest recht, ich habe auf der Serverseite ein Ausführungszeitlimit erreicht (definiert als 60 Sekunden). Außerdem ist Ihr Vorschlag ziemlich gut und ich habe bereits eine Aufgabe definiert, um es zu implementieren (da der Server, den ich verwende, Unterstützung hat, es richtig zu machen). –

Verwandte Themen