Umgang mit WinRT StreamSocket trennt (beide server-und client-Seite)
Ich habe eine Anwendung, die ich Schreibe, für Windows 8/WinRT verwendet, die StreamSocket-API zu tun, eine streaming-Verbindung zu einem server. Das heißt, streamt der server Daten an den client, manchmal mit meta-tags, und die Verbindung trennen können Sie jederzeit.
Das problem das ich habe ist, dass ich keine Ahnung habe, wie zu erkennen, wenn die server getrennt wurde. Dort nicht erscheinen zu sein irgendwelche Ereignisse oder Eigenschaften auf das StreamSocket-Klasse, entweder die input-oder output-Ströme, oder auf dem DataReader - /data-Writer-Klassen, die nichts zu tun mit Verbindung, status.
Oben auf, dass das DataReader-ReadAsync-Methode ist nicht zu Versagen, nachdem der server-Seite trennt die Verbindung zum client. Stattdessen wird der Vorgang erfolgreich ausgeführt, so weit ich erzählen kann, und die Daten, die er füllt in seinem Puffer wird nur die Letzte Sache, die dem server gesendet werden (D. H. es ist nicht-clearing-internen Puffer, auch wenn ich sehe, dass es "verbraucht" jedes mal in den Puffer nenne ich ReadByte). Das macht es bei jedem nachfolgenden Aufruf von ReadAsync - Auffüllen des Puffers mit dem, was der server gesendet die Letzte, bevor es getrennt wird. Hier ist eine vereinfachte version des Codes:
public async Task TestSocketConnectionAsync()
{
var socket = new StreamSocket();
await socket.ConnectAsync(new HostName(Host), Port.ToString(),
SocketProtectionLevel.PlainSocket);
var dr = new DataReader(socket.InputStream);
dr.InputStreamOptions = InputStreamOptions.Partial;
this.cts = new CancellationTokenSource();
this.listenerOperation = StartListeningAsync(dr, cts);
}
public async Task StartListeningAsync(DataReader dr, CancellationTokenSource cts)
{
var token = cts.Token;
while (true)
{
token.ThrowIfCancellationRequested();
var readOperation = dr.LoadAsync(1024);
var result = await readOperation;
if (result <= 0 || readOperation.Status != Windows.Foundation.AsyncStatus.Completed)
{
cts.Cancel(); //never gets called, status is always Completed, result always > 0
}
else
{
while (dr.UnconsumedBufferLength > 0)
{
byte nextByte = dr.ReadByte();
//DriveStateMachine(nextByte);
}
}
}
}
Du musst angemeldet sein, um einen Kommentar abzugeben.
Einen "graceful" - Buchse kann ein Verschluss erkannt werden, die von der anderen Seite als eine 0-Länge gelesen. Das heißt, es fungiert einfach wie eine normale end-of-stream.
Einen "Abbrechen" - Buchse Verschluss ist schwierig. Sie haben, die Daten zu senden zu erkennen, dass die andere Seite geschlossen hat, und wenn das schreiben fehlschlägt, wird jedes weitere lese-oder Schreibvorgänge fehlschlagen sollte (mit einer Ausnahme). Wenn Ihr Protokoll erlaubt es Ihnen nicht, Daten zu senden, dann müssen Sie davon ausgehen, die Verbindung ist schlecht, nach einem timeout abläuft, und schließen Sie es. 🙁
Je nach Anwendung "Abbrechen" - Buchse Verschluss kann normalen - insbesondere sehr ausgelasteten Servern können geschrieben werden, die Klemme schließen Ihre verbindungen, weil Sie Ihnen erlaubt, um Ressourcen freizugeben schneller (Vermeidung der vier-Schritt-socket shutdown-handshake).
DataReader
/DataWriter
geht es nicht um "verbindungen". Sie sind wirklich nurBitConverter
, nur besser dieses mal.Ich würde vermuten, dass der Grund
StreamSocket
nicht "angeschlossen" - Eigenschaft ist, weilSocket.Verbunden
ist nahezu nutzlos und auf jeden Fall irreführend.Ich würde versuchen, mit
StreamSocket.InputStream.ReadAsync
direkt anstattDataReader
, da Sie nur bytes zu Lesen, sowieso. Es klingt wie Sie möglicherweise aufgedeckt zu haben, einen Fehler inDataReader
, die Sie sollten Informationen über Microsoft Connect wennInputStream.ReadAsync
funktioniert wie erwartet. Siehe auch im entsprechenden forum posten.InputStream.ReadAsync
? Ist es mittlerweile gelöst? Ich auch zu haben scheinen seltsames Verhalten auf meinem input-stream, dass es häuft sich die Antworten vom server, die nicht da sein sollte. Ich möchte zum Lesen der Daten aus der Steckdose, bevor ich neue Daten senden an den server. Siehe stackoverflow.com/questions/27533703/...