WCF streaming inside data contracts

Makale
03/25/2011

(A small break from the current WCF extensibility series, as I faced this issue helping a customer this week and I thought it would be worth sharing)

In order to support transferring of large messages (e.g., uploading or downloading a large file), WCF added support (since its first version) to streaming message transfer – unlike the default behavior, which is to buffer the entire message prior to sending it to the wire (or delivering it to the application layer, in the receiving end). Buffering has lots of advantages – it is faster, it allows for operations such as signing the body (which needs the whole content), reliable messaging (which may need to retransmit a message, and streams can often be read only once). However, there are situations, such as uploading a 1GB file to a server, when buffering the message would be too memory-intensive, if at all possible. For these cases streaming can be used.

Enabling streaming is simply a matter of setting the appropriate transfer mode in the binding. BasicHttpBinding, NetTcpBinding and NetNamedPipeBinding expose that property directly. For other binding types, you’ll need to convert them to a custom binding and set that property on the transport binding element itself. But to really get the benefits of streamed transfer, you need to use some data types which don’t need to buffer all the information prior to being serialized. Using a Message object directly (untyped message programming) certainly can be done, as you control the whole message layout, and it can be created based on classes which can emit the message parts on the fly (such as a XmlReader or a BodyWriter), but that’s too low-level for most applications (you need essentially to created the request / parse the response almost “from scratch” – just a little above dealing with raw bytes).

Another parameter type which is naturally “suited” for streaming scenarios are types which implement IXmlSerializable. The contract for such types is that they essentially control their whole serialization / deserialization. On serialization, the class WriteXml method is called, receiving a XmlWriter positioned at the wrapping element. At that point, the class can write as much information as needed, without needing to buffer anything in memory. On the ReadXml method, the class receives a XmlReader positioned again at the wrapping element, and the class can read as much information can consume it without having to buffer it all (but it should only read information pertaining to itself). Below is a simple example of an IXmlSerializable type which produces / consumes 10000 elements in the message, without having to buffer it.

public class MyXmlSerializable : IXmlSerializable
{
int total;
public XmlSchema GetSchema()
{
return null;
}
public void ReadXml(XmlReader reader)
{
reader.ReadStartElement();
for (int i = 0; i < 10000; i++)
{
this.total += reader.ReadElementContentAsInt();
}
reader.ReadEndElement();
}
public void WriteXml(XmlWriter writer)
{
for (int i = 0; i < 10000; i++)
{
writer.WriteStartElement("item_" + i);
writer.WriteValue(i);
writer.WriteEndElement();
}
}
}

IXmlSerializable types aren’t very friendly for simple operations, as the user still has to write code to handle all the serialization. For simple scenarios such as uploading / downloading files, for example, it would be cumbersome to have to write the code to read from the stream / write to the stream and convert it into XML. To make those scenarios easier to implement, WCF exposes on the service model a few capabilities to help with streaming. For operation or message contracts, if you define a single body parameter of type System.IO.Stream, WCF will map it to the whole message body, and the operation can be defined fairly simply, like in the example below. As far as a WCF operation is concerned, a Stream type is equivalent to a byte[] operation (they both map to the XML schema type xs:base64Binary directly). Notice that the type needs to be Stream, not any of its subclasses (MemoryStream, FileStream, etc). When writing the message to the wire, WCF will read the stream passed by the user, and write its bytes out. When reading the message, WCF will create its own read-only stream, and pass it to the user.

[MessageContract]
public class UploadFileRequest
{
[MessageHeader]
public string fileName;
[MessageBodyMember]
public Stream fileContents;
}
[ServiceContract]
public interface IFileDownloader
{
[OperationContract]
Stream DownloadFile(string fileName);
[OperationContract]
void UploadFile(UploadFileRequest request);
}

Notice the restriction of one single body parameter, of type Stream – that’s when WCF will map the entire message body to the stream parameter. For most of the cases, this can be resolved by simply changing the operation signature and moving some parameters from the operation signature to the message header, which is the case of the UploadFile above – the operation would normally be defined as “void UploadFile(string fileName, Stream fileContents)”, but at that point both there are two parameters mapped to the body and the default (easy) mapping falls apart. But changing the operation to a MessageContract-based one is quite straightforward, and it solves most of the problems.

Interoperability issues

But the recommendation of changing the operation contract to make it WCF-happy many times doesn’t work with interoperability scenarios. In such cases, we want to consume an existing service provided by a 3rd party which we have no control over. At that point, we’re stuck with creating a message in the exact format as requested by the service. If the service expects the file contents (or any large binary data, for that matter) to be sent as part of a data contract graph, the proxy generated by svcutil / add service reference will contain such data contracts or types decorated with XML attributes (e.g., XmlType, XmlRoot, etc) and one of those types will contain a byte[] member. Byte arrays are buffered by nature (the array is stored in memory), and switching it to a Stream type won’t work – in the middle of the data contracts the control is handled to the serializers, and they don’t know how to handle Stream parameters like the WCF service model.

So we’re back to the no-Stream support case. Again, we can handcraft the message ourselves, but that usually requires a lot of effort (creating the XML “by hand”). The other alternative, IXmlSerializable is recognized by the serializers (both the DataContractSerializer, and the XmlSerializer, the two “default” serializers for WCF), so that’s where we can go. The main advantage of going the IXmlSerializable way is that we only need to change the class which contains the byte[] field, while the others (any wrapping types) can be left untouched. The task now is to implement the WriteXml and ReadXml methods in a way that they reflect the same contract as the “default” behavior for those classes.

To explain how to change one such class, I’ll define a simple service which contains a binary (byte[]) member nested in a data contract. I’ll use the XmlSerializer ([XmlSerializerFormat]) since that’s the serializer mostly used in interop scenarios, but the steps should be the same for DataContractSerializer types as well. Here’s the service:

[XmlRoot(Namespace = "https://my.namespace.com/data")]
public class RequestClass
{
[XmlAttribute]
public string id;
[XmlElement]
public string token;
[XmlElement]
public Content content;
}
[XmlType(Namespace = "https://my.namespace.com/data")]
public class Content
{
[XmlElement]
public string name;
[XmlElement]
public string extension;
[XmlElement]
public byte[] data;
}
[ServiceContract(Namespace = "https://my.namespace.com/service")]
[XmlSerializerFormat]
public interface ISomeService
{
[OperationContract]
void SendRequest(RequestClass request);
}
public class SomeServiceImpl : ISomeService
{
public void SendRequest(RequestClass request)
{
Console.WriteLine(
"Received request for {0}.{1}, with {2} bytes",
request.content.name,
request.content.extension,
request.content.data.Length);
}
}

After running the service, I can point add service reference or svcutil to it to generate my proxy code:

svcutil https://localhost:8000/Service

This generates the following proxy code:

//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:4.0.30319.1
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
[System.ServiceModel.ServiceContractAttribute(Namespace="https://my.namespace.com/service", ConfigurationName="ISomeService")]
public interface ISomeService
{
[System.ServiceModel.OperationContractAttribute(Action="https://my.namespace.com/service/ISomeService/SendRequest", ReplyAction="https://my.namespace.com/service/ISomeService/SendRequestResponse")]
[System.ServiceModel.XmlSerializerFormatAttribute()]
void SendRequest(RequestClass request);
}
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "4.0.30319.1")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="https://my.namespace.com/data")]
public partial class RequestClass
{
private string tokenField;
private Content contentField;
private string idField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=0)]
public string token
{
get
{
return this.tokenField;
}
set
{
this.tokenField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=1)]
public Content content
{
get
{
return this.contentField;
}
set
{
this.contentField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlAttributeAttribute()]
public string id
{
get
{
return this.idField;
}
set
{
this.idField = value;
}
}
}
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "4.0.30319.1")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(Namespace="https://my.namespace.com/data")]
public partial class Content
{
private string nameField;
private string extensionField;
private byte[] dataField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=0)]
public string name
{
get
{
return this.nameField;
}
set
{
this.nameField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Order=1)]
public string extension
{
get
{
return this.extensionField;
}
set
{
this.extensionField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(DataType="base64Binary", Order=2)]
public byte[] data
{
get
{
return this.dataField;
}
set
{
this.dataField = value;
}
}
}
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
public interface ISomeServiceChannel : ISomeService, System.ServiceModel.IClientChannel
{
}
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute("System.ServiceModel", "4.0.0.0")]
public partial class SomeServiceClient : System.ServiceModel.ClientBase<ISomeService>, ISomeService
{
public SomeServiceClient()
{
}
public SomeServiceClient(string endpointConfigurationName) :
base(endpointConfigurationName)
{
}
public SomeServiceClient(string endpointConfigurationName, string remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}
public SomeServiceClient(string endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) :
base(endpointConfigurationName, remoteAddress)
{
}
public SomeServiceClient(System.ServiceModel.Channels.Binding binding, System.ServiceModel.EndpointAddress remoteAddress) :
base(binding, remoteAddress)
{
}
public void SendRequest(RequestClass request)
{
base.Channel.SendRequest(request);
}
}

Now, to the conversion. Unfortunately, there’s no automated way (AFAIK) to do the conversion, so we have to do it “by hand”. For me, the easiest way is to actually call the method once (using a small byte array value which shouldn’t have any memory issues) while monitoring the request on Fiddler (my favorite HTTP monitoring tool), and see what WCF actually wrote. By doing that we’ll see what the service expects:

static void Main(string[] args)
{
SomeServiceClient c = new SomeServiceClient();
byte[] fileContents = new byte[10];
for (int i = 0; i < fileContents.Length; i++)
{
fileContents[i] = (byte)'a';
}
RequestClass request = new RequestClass
{
id = "id",
token = "token",
content = new Content
{
name = "file",
extension = "ext",
data = fileContents,
},
};
c.SendRequest(request);
}

And that request shown in fiddler is the following:

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
<s:Body xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
<SendRequest xmlns="https://my.namespace.com/service">
<request id="id">
<token xmlns="https://my.namespace.com/data">token</token>
<content xmlns="https://my.namespace.com/data">
<name>file</name>
<extension>ext</extension>
<data>YWFhYWFhYWFhYQ==</data>
</content>
</request>
</SendRequest>
</s:Body>
</s:Envelope>

Now that we know what the request looks like, we can start converting the Content class to IXmlSerializable. The generated proxy classes are marked as partial, which will actually help us isolate the IXmlSerializable code in a separate file (it’s a matter of personal preference, but I prefer to keep the generated proxy as unchanged as possible, in case I need to regenerate it). Let’s focus first on write (sending byte[] / Stream parameters to the server). Most data types are written to XmlWriter using its WriteValue method (it has many overloads), while binary data is written using the WriteBase64 method. Here’s a first attempt of implementing IXmlSerializable on that type:

using System;
using System.Xml;
using System.Xml.Schema;
using System.Xml.Serialization;
public partial class Content : IXmlSerializable
{
public XmlSchema GetSchema()
{
return null;
}
public void ReadXml(XmlReader reader)
{
throw new NotImplementedException();
}
public void WriteXml(XmlWriter writer)
{
writer.WriteStartElement("name");
writer.WriteValue(this.name);
writer.WriteEndElement();
writer.WriteStartElement("extension");
writer.WriteValue(this.extension);
writer.WriteEndElement();
writer.WriteStartElement("data");
writer.WriteBase64(this.data, 0, this.data.Length);
writer.WriteEndElement();
}
}

It builds fine. But when I try to run it, it fails with the exception below:

System.InvalidOperationException: There was an error reflecting type 'RequestClass'.
---> System.InvalidOperationException: There was an error reflecting property 'content'.
---> System.InvalidOperationException: There was an error reflecting type 'Content'.
---> System.InvalidOperationException: Only XmlRoot attribute may be specified for the type Content. Please use XmlSchemaProviderAttribute to specify schema type.

The problem is that the attribute [XmlType] applied to the type Content in the generated file is conflicting with the IXmlSerializable implementation. XmlType is used to control the XML schema of a type, and IXmlSerializable has its own way of providing schema. This can be fixed by commenting out the attribute on the generated file:

/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("svcutil", "4.0.30319.1")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
//[System.Xml.Serialization.XmlTypeAttribute(Namespace="https://my.namespace.com/data")]
public partial class Content
{

Now it builds fine, it runs fine. Looking at the request in Fiddler, it is exactly the same as the previous one, so we’re in the right track. It’s possible that it had some differences (mostly likely due to things such as XML namespaces), in this case we’d have to go back and update the writing logic. We haven’t changed anything yet, but now we can move on to adding a stream parameter. First, let’s define a Stream property which will be used instead of the byte[] one:

public partial class Content : IXmlSerializable
{
private Stream stream;
public Stream DataStream
{
set { this.stream = value; }
}
// rest of class ommitted
}

Now we can change the WriteXml implementation. We can still use a small buffer to avoid writing bytes 1-1, but it will certainly be smaller than many MBs of large files.

public void WriteXml(XmlWriter writer)
{
writer.WriteStartElement("name");
writer.WriteValue(this.name);
writer.WriteEndElement();
writer.WriteStartElement("extension");
writer.WriteValue(this.extension);
writer.WriteEndElement();
writer.WriteStartElement("data");
byte[] buffer = new byte[1000];
int bytesRead;
do
{
bytesRead = this.stream.Read(buffer, 0, buffer.Length);
if (bytesRead > 0)
{
writer.WriteBase64(buffer, 0, bytesRead);
}
} while (bytesRead > 0);
writer.WriteEndElement();
}

And the Write part is done.

MTOM considerations

Before we move on to the Read part, let me just spend some time discussing about MTOM. MTOM is a W3C recommendation which defines an optimization for transmitting binary data in SOAP messages. Typically, binary data is base64-encoded and written inline in the SOAP body. This is fine for many scenarios, but it has the drawback that base64-encoding increases the data size by ~33%. MTOM optimizes that by sending large binary data not inlined in the message, but as MIME attachments instead. They have a small overhead for some MIME headers, but the binary data is sent as-is, without any encoding, so the message doesn’t have the 33% size penalty.

In WCF, MTOM is implemented by an implementation of the XmlWriter abstract class (the internal class XmlMtomWriter). Whenever the user (or WCF code itself) writes binary data (WriteBase64), the MTOM writer will hold on to the data written and emit it as attachments after the whole message body has been written. By holding on to the data, the writer is essentially buffering it (since it needs to do it, as it needs to finish writing the message prior to writing the attachments), so the code above for WriteXml won’t do what we want in MTOM – it will still buffer the stream contents!

The solution for this problem is to hand over the Stream itself to the MTOM writer, and let it hold on to it until it’s ready to consume it. This is done via the IStreamProvider interface, and the XmlDictionaryWriter (a class derived from XmlWriter which is used internally in WCF) adds a new overload to WriteValue which takes an IStreamProvider parameter. In normal (i.e., non-MTOM) writers, this implementation simply copies the stream to the writer by calling WriteBase64 (as we did in our initial WriteXml implementation). The MTOM writer, however, holds on to the stream and will only consume it when it needs to.

This is the MTOM-aware version of the WriteXml method now:

public void WriteXml(XmlWriter writer)
{
writer.WriteStartElement("name");
writer.WriteValue(this.name);
writer.WriteEndElement();
writer.WriteStartElement("extension");
writer.WriteValue(this.extension);
writer.WriteEndElement();
writer.WriteStartElement("data");
XmlDictionaryWriter dictWriter = writer as XmlDictionaryWriter;
bool isMtom = dictWriter != null && dictWriter is IXmlMtomWriterInitializer;
if (isMtom)
{
dictWriter.WriteValue(new MyStreamProvider(this.stream));
}
else
{
// fall back to the original behavior
byte[] buffer = new byte[1000];
int bytesRead;
do
{
bytesRead = this.stream.Read(buffer, 0, buffer.Length);
if (bytesRead > 0)
{
writer.WriteBase64(buffer, 0, bytesRead);
}
} while (bytesRead > 0);
}
writer.WriteEndElement();
}
class MyStreamProvider : IStreamProvider
{
Stream stream;
public MyStreamProvider(Stream stream)
{
this.stream = stream;
}
public Stream GetStream()
{
return this.stream;
}
public void ReleaseStream(Stream stream)
{
}
}

And now the Write part is really done.

Reading

In order to test the reading part I’ll update the test server with an extra operation which returns a byte[] field nested inside a data contract graph.

[XmlRoot(Namespace = "https://my.namespace.com/data")]
public class ResponseClass
{
[XmlAttribute]
public string id;
[XmlElement]
public string token;
[XmlElement]
public Content content;
}
[ServiceContract(Namespace = "https://my.namespace.com/service")]
[XmlSerializerFormat]
public interface ISomeService
{
[OperationContract]
void SendRequest(RequestClass request);
[OperationContract]
ResponseClass GetResponse(int dataSize);
}
public class SomeServiceImpl : ISomeService
{
public void SendRequest(RequestClass request)
{
Console.WriteLine(
"Received request for {0}.{1}, with {2} bytes",
request.content.name,
request.content.extension,
request.content.data.Length);
}
public ResponseClass GetResponse(int dataSize)
{
byte[] data = new byte[dataSize];
for (int i = 0; i < dataSize; i++) data[i] = (byte)'b';
return new ResponseClass
{
id = "resp",
token = "tkn",
content = new Content
{
name = "resp",
extension = "txt",
data = data,
},
};
}
}

Updating the client to use it: re-generated the proxy with svcutil/ASR, comment out the [XmlType] attribute on the Content class, and update the Main method:

static void Main(string[] args)
{
SomeServiceClient c = new SomeServiceClient();
c.GetResponse(20);
}

And it fails when run:

System.ServiceModel.CommunicationException: Error in deserializing body of reply message for operation 'GetResponse'.
---> System.InvalidOperationException: There is an error in XML document (1, 363).
---> System.NotImplementedException: The method or operation is not implemented.
at Content.ReadXml(XmlReader reader)

Now we need to implement ReadXml. The idea is similar to the WriteXml: look at the response on fiddler

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
<s:Body xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
<GetResponseResponse xmlns="https://my.namespace.com/service">
<GetResponseResult id="resp">
<token xmlns="https://my.namespace.com/data">tkn</token>
<content xmlns="https://my.namespace.com/data">
<name>resp</name>
<extension>txt</extension>
<data>YmJiYmJiYmJiYmJiYmJiYmJiYmI=</data>
</content>
</GetResponseResult>
</GetResponseResponse>
</s:Body>
</s:Envelope>

And start reading from the XmlReader into the class. Notice that the reader is positioned at the wrapping element (<content>), so to access the fields we need first to read past it. After that we can start reading the data fields themselves:

public void ReadXml(XmlReader reader)
{
reader.ReadStartElement(); //wrapping element
this.name = reader.ReadElementContentAsString();
this.extension = reader.ReadElementContentAsString();
MemoryStream ms = new MemoryStream();
byte[] buffer = new byte[1000];
int bytesRead;
reader.ReadStartElement();
do
{
bytesRead = reader.ReadContentAsBase64(buffer, 0, buffer.Length);
ms.Write(buffer, 0, bytesRead);
} while (bytesRead > 0);
this.data = ms.ToArray();
reader.ReadEndElement();
reader.ReadEndElement(); //wrapping element
}

This works fine, but at that point we’re still buffering the response. Unfortunately we can’t avoid it – since it’s in the middle of the body (not the whole body), WCF needs to read all of the content data to be able to finish reading the rest of the message. If this is a problem, however, we can shift the buffering from memory to another location – such as disk – which can hold on to very large structures a lot easier. Here’s the modified code. Notice that I didn’t expose the file stream as a property, but as a method instead, to make it clearer that it’s not just retrieving the value of a field, but it’s doing something else instead.

public partial class Content : IXmlSerializable
{
private Stream stream;
private string streamFileName;
public Stream DataStream
{
set { this.stream = value; }
}
public Stream GetDataStream()
{
return File.OpenRead(this.streamFileName);
}
public void WriteXml(XmlWriter writer)
{
writer.WriteStartElement("name");
writer.WriteValue(this.name);
writer.WriteEndElement();
writer.WriteStartElement("extension");
writer.WriteValue(this.extension);
writer.WriteEndElement();
writer.WriteStartElement("data");
XmlDictionaryWriter dictWriter = writer as XmlDictionaryWriter;
bool isMtom = dictWriter != null && dictWriter is IXmlMtomWriterInitializer;
if (isMtom)
{
dictWriter.WriteValue(new MyStreamProvider(this.stream));
}
else
{
// fall back to the original behavior
byte[] buffer = new byte[1000];
int bytesRead;
do
{
bytesRead = this.stream.Read(buffer, 0, buffer.Length);
if (bytesRead > 0)
{
writer.WriteBase64(buffer, 0, bytesRead);
}
} while (bytesRead > 0);
}
writer.WriteEndElement();
}
public void ReadXml(XmlReader reader)
{
reader.ReadStartElement(); //wrapping element
this.name = reader.ReadElementContentAsString();
this.extension = reader.ReadElementContentAsString();
string tempFileName = Path.GetTempFileName();
using (FileStream fs = File.Create(tempFileName))
{
byte[] buffer = new byte[1000];
int bytesRead;
reader.ReadStartElement();
do
{
bytesRead = reader.ReadContentAsBase64(buffer, 0, buffer.Length);
fs.Write(buffer, 0, bytesRead);
} while (bytesRead > 0);
reader.ReadEndElement();
}
reader.ReadEndElement(); //wrapping element
}
public XmlSchema GetSchema()
{
return null;
}
class MyStreamProvider : IStreamProvider
{
Stream stream;
public MyStreamProvider(Stream stream)
{
this.stream = stream;
}
public Stream GetStream()
{
return this.stream;
}
public void ReleaseStream(Stream stream)
{
}
}
}

Hope this helps!

[Code for this post]

Comments

Anonymous
April 12, 2011
Can you upload the source code example?Thanks a lot, is a great article.
Anonymous
April 13, 2011
Hello OneTx,I updated the post with a link to the source code. It can be found in the MSDN Code Gallery at code.msdn.microsoft.com/Streaming-inside-data-1e855d9a.Thanks!
Anonymous
December 21, 2011
Thanks a lot. A greate article. Helped a lot
Anonymous
December 22, 2011
Hello, I tried running the example. But the request seems to be buffering. The server gives an error "maximum message size needs to be increased'. Any ideas.Thanks
Anonymous
December 23, 2011
If you want to really use streaming, you'll need to update the TransferMode property of the binding to Streamed. The request will still be limited by MaxReceivedMessageSize, but you can increase it to a larger value and the memory shouldn't spike.
Anonymous
December 25, 2011
Hello, Thanks for the suggestion. I have changed the transfermode property to streamed and increased the maxreceivedMessagesize to '1073741824'. The message size error went away and I am able to upload files upto 60MB. But when I upload files of size 100MB, I recieved a new tcp error which says 'A TCP error (10055: An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full) occurred while transmitting data'. Any ideas. And how will I be able to confirm if the request is streaming and not buffering.Thanks
Anonymous
December 26, 2011
Hi Balaji, you can confirm that the request is being streamed if you don't see a huge spike in the memory used by the process. Are both parts (client and server) streaming? If one is streaming but the other is buffering the request, it's possible that you'll get some error like this one.
Anonymous
December 26, 2011
Hello Carlos,Thank you. I compared the memory consumption at the server with the two modes of transfer(streaming and buffering) and confirmed that the service is indeed streaming. You are right about the transfer mode at the client. It is infact buffering at the client side, though I changed the transfer mode to streaming in the client config file. Is there anything else that I can do in the service, that can make the client use streaming. I am passing the file to be uploaded as a bytearray to the service.I tried passing it as a memorystream, but it says that it cannot implicitly convert stream to a byte array. Is this causing the issue at the client? Is there any solution which is interoperable.Thanks
Anonymous
October 09, 2012
Carlos, I am trying to do something similar to this but so far have not been able to get it to work. My messages are rather complex which makes is harder for me to figure out where my errors are coming from. Can I contact you by email to see if you can help me figure this out?Thanks.Miguel.

Aracılığıyla paylaş

WCF streaming inside data contracts

Interoperability issues

MTOM considerations

Reading

Comments

Ek kaynaklar