Why is the maxReceivedMessageSize property relevant when implementing WCF Streaming? Since buffering and persistence is handled by the consumer of the stream, why does WCF concern itself with how big or long a single service operation could take?
I’m working on a project which could handle large files from server to client and back. I figured WCF streaming is an excellent choice as it SHOULD allow for theoretically infinite file sizes to be handled. Both my client and server have transportMode (on the binding) set to “Streamed” and messages designed to contain Streams. This is not enough, however, as I get a CommunicationException indicating I need to increase the maxReceivedMessageSize property. Following the exception’s advice, increasing the property magically allows everything to work perfectly.
I’m concerned that WCF is forcing me to “cap” how much my service/client can handle even though streaming is supposed to be “infinite.” If a file comes along that happens to be bigger than my binding’s config, the same CommunicationException will occur. I don’t see why WCF is arbitrarily limiting my capacity to handle large files, “when” and “how” I send and store these files is now “my” business because I have a stream to consume however I wish.
Am I missing something?
According to the documentation (at least what I’ve found), the reason you are “forced” to limit the size of your message is security, mostly to avoid DoS attacks, by sending too large messages and flooding the system.
The max size for maxReceivedMessageSize is 9,223,372,036,854,775,807 bytes.
Hope this helps.