2017-02-24 3 views
1

Ich musste Android-Server-Anwendung erstellen, die auf eingehende Verbindungen warten musste. Es ist nicht-root-Anwendung und es hört zufällig hohen Port. Der Code ist trivial und funktioniert ausgezeichnet auf dem Desktop-Java, er überwacht nur den Port und bietet ein sehr einfaches benutzerdefiniertes Anfrage/Antwort-Protokoll.Android-Server: warum Timeout eingehende Verbindungen nach dem Zufallsprinzip?

Ich fand jedoch, dass aus irgendeinem Grund sogar Android-Anwendung ist in accept Methode jetzt (d. H. Es soll auf eingehende Verbindungen warten), die Verbindung Zeit oft aus.

Ich habe auch festgestellt, dass manchmal sogar System-Anwendung (ADB-Server zum Beispiel) eingehende Verbindungen regelmäßig ohne Grund abläuft. Siehe zum Beispiel paping Ausgabe:

paping -p 5555 192.168.0.105 
paping v1.5.5 - Copyright (c) 2011 Mike Lovell 

Connecting to 192.168.0.105 on TCP 5555: 

Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connection timed out 
Connected to 192.168.0.105: time=118.02ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=140.02ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=57.01ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=77.51ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=97.01ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=122.02ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=135.52ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=52.01ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=72.51ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=92.51ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=105.51ms protocol=TCP port=5555 
Connected to 192.168.0.105: time=5.50ms protocol=TCP port=5555 

So sieht es aus wie die Geräte mal aus einigen eingehenden Daten und beginnen danach zu akzeptieren, später mal aus Zufall. Und ADB ist eine Systemanwendung, also sollte es allen Richtlinien folgen und vergleichsweise fehlerfrei sein.

Kann jemand das Problem beheben und Android-Gerät für eingehende Verbindungen schnell beantworten? Andernfalls wird jede Anwendung, die eingehenden Datenverkehr benötigt, fehlerhaft und unzuverlässig sein.

+0

'die Verbindungszeit often.' out ?? Welche Verbindung? Der Server hat zugehört, oder? Bitte bereinigen. – greenapps

+0

Ja, der Server hört zu, und aus irgendeinem Grund gibt es eine zufällige Verbindung für eingehende Verbindungen (kann überhaupt keine Verbindung herstellen), selbst Java wartet innerhalb des 'accept' Methodenaufrufs. – Vitaliy

+0

Sie beschuldigen keinen fehlerhaften Router? Versuchte andere Geräte? – greenapps

Antwort

0

Das Android-Betriebssystem schaltet das Wifi-Radio nach einer Weile aus, wenn das Gerät nicht aktiv verwendet wird. Ich bin mir nicht sicher, was es für "im Gebrauch" hält. Vielleicht hat das etwas damit zu tun ...

Von https://developer.android.com/reference/android/net/wifi/WifiManager.WifiLock.html

Normalerweise wird das Wi-Fi-Radio ausschalten kann, wenn der Benutzer das Gerät nicht in einer Zeit lang verwendet wird.

In einigen meiner Anwendungen habe ich das Wifi-Lock verwendet, um das Radio wach zu halten. Etwas wie folgt aus: Hinweis: Die Anwendung sollte fordern Sie die android.permission.WAKE_LOCK

public class MyActivity extends Activity { 
    private WifiManager.WifiLock wifiLock; 

    @Override 
    protected void onResume { 
     super.onResume(); 
     WifiManager wifiManager = (WifiManager) getSystemService(Context.WIFI_SERVICE); 
     wifiLock = wifiManager.createWifiLock(WifiManager.WIFI_MODE_FULL_HIGH_PERF, "SYNCVR"); 
     wifiLock.acquire(); 
    } 

    @Override 
    protected void onPause() { 
     wifiLock.release(); 
    } 
} 

Es gibt ein paar verschiedene Optionen, die Sie angeben können, wenn die Sperre wifi erstellen: Von https://developer.android.com/reference/android/net/wifi/WifiManager.html

WIFI_MODE_FULL

In diesem WLAN-Lock-Modus wird Wi-Fi aktiv gehalten werden, ein d wird sich normal verhalten, d. h. es wird versucht, automatisch eine Verbindung zu einem gemeldeten Zugriffspunkt herzustellen, der innerhalb der Reichweite liegt, und es werden periodische Scans durchgeführt, wenn es Zugriffspunkte gibt, die sich jedoch nicht im Bereich befinden.

-

WIFI_MODE_FULL_HIGH_PERF

In diesem Wi-Fi Lock-Modus, Wi-Fi wird wie im Modus WIFI_MODE_FULL aktiv gehalten werden, aber es arbeitet mit hohen Leistung bei minimalem Paketverlust und niedrigem Paket Latenz, auch wenn der Gerätebildschirm ausgeschaltet ist.

-

WIFI_MODE_SCAN_ONLY

In diesem Wi-Fi Lock-Modus, Wi-Fi wird aktiv gehalten werden, aber der einzige Betrieb, der unterstützt wird, ist die Einleitung von Scans und die anschließende Meldung von Scan-Ergebnissen.

this helps :)

+0

Das Problem der Timeouts für neue eingehende Verbindungsanforderungen wird dadurch nicht gelöst. Wenn die Verbindung bereits hergestellt ist, wird die Verbindung viel stabiler, wenn ich die Wi-Fi-Sperre verwende. Es hat jedoch keinen Einfluss auf neue Verbindungen, die eingerichtet werden müssen. – Vitaliy

Verwandte Themen