AndroidAsync TCP - richtiger Weg zum Erkennen von Sockets ist nicht mehr verfügbar mit Schreiben?

Ich frage mich, was ist der richtige Weg, um auf der Client-Seite zu überprüfen, dass ein TCP-Socket geöffnet mit der AndroidAsync-Bibliothek nicht mehr verfügbar ist? Dies ist der Fall, wenn der Server (reiner TCP-Server, kein Android-Async-Server) nicht explizit das Schließen des Sockets initiiert hat (der ClosedCallback wird also nicht aufgerufen). Zum Beispiel, wenn der Server kalt neu gestartet wurde.AndroidAsync TCP - richtiger Weg zum Erkennen von Sockets ist nicht mehr verfügbar mit Schreiben?

Es scheint, dass der DataCallback nur verfügbar ist, wenn der Server Daten zurücksendet und nicht zum Empfangen von Fehlermeldungen verwendet werden kann.

Es scheint mir, dass auch

Util.writeAll(socket, (byte[]) payload.array(), new CompletedCallback() 
    { 
     @Override 
     public void onCompleted(Exception ex) 
     { 
      if (ex != null) 
      { 
       Log.e(TAG, "write failed with ex message= " + ex.getMessage()); 
       throw new RuntimeException(ex); 
      } 
     } 
    });

nicht entweder eine Exception wirft.

Also an diesem Punkt bin ich mir nicht sicher, wie der Socket nicht mehr verfügbar ist, selbst wenn der Client Daten in es regelmäßig schreibt.

Quelle

2016-03-28 Objectist

-1

Sie könnten die geschlossenen/Ende Rückrufe

socket.setClosedCallback(new CompletedCallback() 
{ 
      @Override 
      public void onCompleted(Exception ex) 
      { 

      } 
     }); 

socket.setEndCallback(new CompletedCallback() 
{ 
      @Override 
      public void onCompleted(Exception ex) 
      { 

      } 
});

Quelle

2016-05-11 00:22:19 behelit

Leider ist der Server kein AndroidAsync-Server und schließt die Verbindung nicht, sodass die Callbacks aufgerufen werden können. – Objectist

Sorry, was meinst du mit Nicht-AndroidAsync-Server? Selbst mit einem node.js, oder sogar einem benutzerdefinierten C++ TCP-Server, bekomme ich immer noch das Ende und geschlossene Callbacks auf dem Client, wenn der Server stirbt, ich glaube nicht, dass es etwas mit AndroidAsync zu tun hat und es ist mehr von a tcp standard – behelit

In meiner Umgebung gibt es andere Anwendungsfälle neben dem Herunterfahren des Servers (anmutig), wenn die Verbindung aus der Sicht des Clients und des Servers nicht mehr gültig ist. Da der Server kein von mir implementierter/gesteuerter AndroidAsync-Server ist, muss dieser auf der Client-Seite entdeckt werden. – Objectist

verwenden Es wird ein IOexception, wenn Sie genügend Daten senden oder es oft genug nennen werfen. Es wird nicht auf den ersten Anruf wegen TCP-Pufferung an beiden Enden werfen.

Quelle

2016-05-11 00:24:45 EJP

Das macht Sinn. Der Client ist jedoch eine Fernbedienung für den Server mit einem visuellen Frontend. Zu der Zeit, wenn "genügend" Daten/Anrufe gesendet werden, würden die beiden lange nicht synchron sein, was eine schlechte Benutzererfahrung verursachen würde. – Objectist

Ich endete mit der Implementierung einer Art von "Ping" -Alike periodic check. Der Client öffnet und schließt sofort eine TCP-Verbindung zum selben Port mit einem einfachen Java NIO-Socket-Aufruf (ohne AndroidAsync). Wenn dies einmal abgelaufen ist, wird angenommen, dass die Verbindung verloren gegangen ist, und ein Wiederherstellungsversuch wird unternommen, sobald es erneut erfolgreich ist. Diese periodische Prüfung wird nur durchgeführt, wenn die App den Fokus hat oder gerade erwacht ist. Dies ist eindeutig ein weit davon entfernt idealer Workaround, aber es scheint für meine Zwecke zu funktionieren.

Quelle

2016-05-24 20:13:15 Objectist

AndroidAsync TCP - richtiger Weg zum Erkennen von Sockets ist nicht mehr verfügbar mit Schreiben?

Antwort

Verwandte Themen