Y at-il une alternative à System.IO.BufferedStream en C #?

Question

Je reçois l'exception suivante:

System.NotSupportedException : This stream does not support seek operations.
   at System.Net.Sockets.NetworkStream.Seek(Int64 offset, SeekOrigin origin)
   at System.IO.BufferedStream.FlushRead()
   at System.IO.BufferedStream.WriteByte(Byte value)

Le spectacle de lien de suivi que ce problème est connu pour Microsoft. http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback. aspx? FeedbackID = 273186

Cette stacktrace montre 2 choses:

1. Le System.IO.BufferedStream faire une opération de déplacement de pointeur absurde. Un BufferedStream doit tamponner le flux sous-jacent et pas plus. La qualité de tampon sera mauvais s'il y a cette opération de recherche.
2. Il ne fonctionnera jamais stable avec un flux qui ne supporte Seek.

Y a-t-il des alternatives? Est-ce que je besoin d'un tampon avec un NetworkStream en C # ou est-ce déjà tamponnés.

Modifier. Je veux simplement réduire le nombre de lecture / écriture des appels vers le flux de socket sous-jacente

Answer 1

La solution consiste à utiliser deux BufferedStreams indépendants, l'un pour la réception et un pour l'envoi. Et ne pas oublier de rincer le BufferedStream envoyer correctement.

---

Depuis même en 2018, il semble difficile d'obtenir une réponse satisfaisante à cette question, pour le bien de l'humanité, voici mes deux cents:

Le NetworkStream est tamponné sur le côté du système d'exploitation. Toutefois, cela ne signifie pas qu'il n'y a aucune raison de tampons du côté .net. TCP se comporte bien sur Write-Read (répétition), mais tombe en panne sur Write-écriture Lire en raison de ack retardé, etc, etc.

Si vous, comme moi, vous avez un tas de code de protocole sous-par prendre dans le vingt et unième siècle, vous voulez tampon.

Alternativement , si vous vous en tenez à ce qui précède, vous pouvez tamponner également lit uniquement / RCVS ou seulement écrit / Sends, et utiliser directement les NetworkStream pour l'autre côté, selon la façon dont rompu ce code est . Vous devez juste être cohérent!

Qu'est-ce que BufferedStream docs ne parviennent pas à faire très clair est que vous devez uniquement passer la lecture et l'écriture si votre flux est adressable . En effet, il tamponne lit et écrit dans le même tampon. BufferedStream simplement ne fonctionne pas bien pour NetworkStream.

Comme Marc l'a souligné, la cause de cette boiterie est la confusion entre deux cours d'eau dans un NetworkStream qui n'est pas une des plus grandes décisions de conception de .net.

Answer 2

Le NetworkStream est déjà en mémoire tampon. Toutes les données reçues sont conservées dans un tampon vous attend de le lire. Les appels à lire sera soit très rapide, ou se bloque en attendant que les données soient reçues de l'autre par les pairs sur le réseau, un BufferedStream ne sera pas utile dans les deux cas.

Si vous êtes préoccupé par le blocage alors vous pouvez regarder passer la prise sous-jacente en mode non-bloquant.

Answer 3

BufferedStream agit simplement de réduire le nombre d'appels de lecture / écriture au flux sous-jacent (qui peut être IO / matériel lié). Il ne peut pas fournir chercher la capacité (et en effet, mise en mémoire tampon et la recherche sont à bien des égards contraire à eachother).

Pourquoi avez-vous besoin de chercher? Peut-être copier le flux à quelque chose adressable d'abord - un MemoryStream ou FileStream -. puis faites votre travail réel de cette seconde, flux adressable

Avez-vous un objectif précis en tête? Je peux être en mesure de proposer des options plus appropriées avec plus de détails ...

En particulier: noter que NetworkStream est une curiosité - avec la plupart des cours d'eau, lecture / écriture se rapportent au même flux physique; cependant, un NetworkStream représente en fait deux tuyaux complètement indépendants; lecture et écriture sont sans aucun rapport. De même, vous ne pouvez pas rechercher en octets qui ont déjà zippé après vous ... vous pouvez saut données, mais qui est mieux fait en faisant quelques opdrations de Read et à rejeter les données.