tags:

views:

1873

answers:

5

I'm working on a web app that passes data to a custom client app.

I'm getting exceptions when the data is over some "small" size. Since the end users will likely be using increasingly larger data sizes, I switched the return from the WCF function to be the ID of the data set.

Next, I converted the client to use the ID to retrieve the data from some simple ASPX page. This works fine, but means an inconsistency in the interface.

  1. Edit: I'm not sure how I missed returning a Stream, but I did. Does anyone have problems with Streams over WCF?

  2. Other than a dropped connection, are there any issues in reading files via HTTP streams from an ASPX page?

I would presume that I'm missing a capability of WCF (like oob data). But then, the C#/.NET on-line help is either pretty poor or else seriously broken as installed on my machine.

Thanks.

[Edit] By the way, in my case the "large amount of data" is user-input driven, but will need to be at least 20MiB.

A: 

What's the exception you are seeing? Can you not read the XML because the reader quota is exceeded?

If so, I think I know what might fix it. See below for a sample wsHttpBinding. Your exception should help you to determine which parameter needs to be fixed. You can maxReceivedMessageSize and quotas for the reader. Let me know if this doesn't work and please provide more data.

<wsHttpBinding>
    <binding name="bindingName" closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00" bypassProxyOnLocal="false" maxBufferPoolSize="524288" maxReceivedMessageSize="65536">
      <readerQuotas maxDepth="32" maxStringContentLength="3145728" maxArrayLength="16384" maxBytesPerRead="4096" maxNameTableCharCount="16384" />
    </binding>
</wsHttpBinding>
siz
It was a timeout exception from a message size overflow (forgot the details). It doesn't seem reasonable to return this data as a string (or even byte[]) anyhow, and I wanted to figure out how other people return "LARGE" data values over WCF.
NVRAM
And thanks, your comment may address what I assume the core problem was (mismatched message size on client/server), but I'm not hitting that at the time being.
NVRAM
+3  A: 

See Large Data and Streaming.

eed3si9n
Thanks. I found the following link yesterday, too: http://stackoverflow.com/questions/323585/wcf-chunking-streaming
NVRAM
A: 

you can go to this address http://weblogs.asp.net/cibrax/archive/2008/06/10/streaming-large-content-with-wcf-and-deferred-execution.aspx, I don't it fits to your pb but it's also an idea.

A: 

As I understand the Large Data and Streaming article mentioned by eed3si9n, one must switch transport mode for all communication, meaning it turns off some integrity checks.

Consequently, I ended up with using a semi-custom HTTP client class where:

  • Downloads use ASPX page(s) that return the data and stream it to the client app's disk file,
  • Uploads send the file to an ASPX page that generates a GUID and saves the file to the server's disk with that GUID as part of its name. It then calls a WCF method to pass the other parameters with the GUID in lieu of the file data.

It isn't beautiful but it works. Unfortunately, an IIS or client app crash could leave the temp files on the server hard drive, but they're localized and could be cleaned up on service creation.

NVRAM
A: 

Setting up the maxItemsInObjectGraph in the Client side and Server side worked for me.

(Dont forget the client side.) http://social.msdn.microsoft.com/Forums/en/wcf/thread/0af69654-2d89-44f3-857a-583b57844ca5

franklins