0
Webメソッドは、フィールドの1つがストリームである単純な構造を受け取ります。このコードは、クライアント側でエラーが発生しストリーミングメッセージ(Mtom)を使用してWCFサービスのストリームフィールドでEndOfStreamを検出します
[MessageContract]
public class MyFile:IDisposable
{
Stream _stream;
[MessageBodyMember]
public Stream stream
{
get { return _stream; }
set { _stream= value; }
}
String _Name;
[MessageHeader]
public String Name
{
get { return _Name; }
set { _Name = value; }
}
}
#region IDisposable Support
private bool disposedValue = false; // To detect redundant calls
protected virtual void Dispose(bool disposing)
{
if (!disposedValue)
{
if (disposing)
{
// TODO: dispose managed state (managed objects).
_File.Dispose();
}
// TODO: free unmanaged resources (unmanaged objects) and override a finalizer below.
// TODO: set large fields to null.
disposedValue = true;
}
}
public void submitFile(MyFile file)
{
using (var fs = File.Create(@"d:\temp\" + file + ".pdf"))
{
int len;
byte[] buffer = new byte[1024];
do
{
len = file.stream.Read(buffer,0,buffer.Length);
fs.Write(buffer, 0, len);
} while (len != 0);
}
}
: それはこのようなものです。クライアントは、クライアントがまだストリームを介してデータを送信しているときに、ストリームがサーバーによって閉じられたというエラーを中止します。
問題はストリームの終わりをどのように検出するのですか?
私は、通信が中断される可能性があることを知っています。または、サーバーがクライアントより高速に処理できるため、読み取るデータがないとクライアントがすべてのデータを送信したわけではありません。 HTTP POSTには、サーバーに要求が終了したことを示すタグが最後に付いている必要があります。その情報を取得するには、WCFの簡単な方法が必要です。
ファイルの最後にマークを付けることは、私が避けようとしていることです。
はい、動作します。しかし、それを実現するには、サーバはすべてのデータをメモリに保持しなければなりません。 – ByteArtisan
いいえ、そうではありません。内部バッファがいっぱいになると、ファイルストリームがディスクにフラッシュされます。また、バッファサイズを指定できるCopyToのオーバーロードもあります。 – gnud
あなたはリグスです。ドキュメントによるとそれはします。 クライアントがメモリ内のすべてのファイルを割り当てようとしているため、まだ6GBファイルを渡すことができませんが、それは別の問題です。ありがとう。 – ByteArtisan