2010-09-17 4 views
0

Est-il possible d'utiliser GZipStream en passant un SslStream en C#? dire pouvez-vous faireC# SslStream avec GZipStream


GZipStream stream = new GZipStream(sslStream, CompressionMode.Compress); 
stream.Write(...); 

... 

GZipStream stream = new GZipStream(sslStream, CompressionMode.Decompress); 
stream.Read(...); 

Si cela est possible, est le SslStream toujours dans un état utilisable après ou doit-il être fermé?

Merci.

Répondre

1

Je ne peux pas penser pourquoi pas; le flux SSL sera juste donné octets, mais c'est ce qu'il attendait quand même. L'important est de fermer le GZipStream correctement, car même Flush() ne se vide pas toujours vraiment (en raison de devoir conserver un tampon en cours de compression). Alors:

using(GZipStream stream = new GZipStream(sslStream, CompressionMode.Compress)) { 
    stream.Write(...); 
    stream.Close(); // arguably overkill; the Dispose() from "using" should be enough 
} 

Je suis aussi en supposant que vous n'êtes pas lire et d'écrire le même flux SSL (ie qui est deux séparés exemples, pas un seul exemple), comme cela ne semble pas susceptible de travailler.

+0

Oui, désolé l'exemple était destiné à être les côtés client/serveur. Si je dispose du GZipStream, ne ferme-t-il pas mon flux sous-jacent? J'ai semblé obtenir des exceptions ObjectDisposed quand il était enveloppé dans une instruction using ... –

+0

@qmunke qui est optionnel; voir le ctor à gzipstream. Il faut un iirc de bool. –

0

C'est possible et peut parfois fonctionner, mais il peut aussi parfois échouer. Cela devrait fonctionner si votre protocole vous permet toujours de "fermer proprement" le GZipStream avant la fermeture de SSLStream. Par "cleanly close", je veux dire que les effets de fermeture de GZipStream (le rinçage du tampon de compression) peuvent se produire et se propager à l'homologue. Il peut échouer car Ssl permet une sémantique de fermeture plutôt drastique. Voir la section 7.2.1 de RFC 2246.

Questions connexes