I know, my question is kinda wishy washy, but what would you say are "optimal" settings for WCF quotas, e.g. MaxReceivedMessageSize etc.?
My service mostly returns small values, but sometimes the return values exceed the default quotas. There are even larger return values, which I return as streams at a second endpoint.
Now the default value for MaxReceivedMessageSize (no question, the streamed endpoint uses higher values; my question concerns buffered communication) of 65536 bytes is quite low, I think. There are tons of "tutorials" which just set this value to Int32.MaxValue, which isn't a good idea at all ;)
Well what do you think? Which values are viable but are also safe enough not to make your service vulnerable for DoS and other stuff?
Regards
Vialbe value really depends on the size of data you are expecting. If you know that sometimes you can get up to 256KB then set the value to 256KB. In case of internal service the limit can be probably set to Int32.MaxValue but I think it is much more about lazyness of making the assumtion about transferred data. For a public web service you will hardly set the value to Int32.MaxValue because anybody will be able to blow up your server.
Btw. if we are talking about data returned from the service then this decission is on the client - both quotas and MaxReceiveMessageSize target receiving message not sending message so if your service returns data in response to client's requests the limit will be set on the client side. For example in case of public web service you don't have all clients under your control so you must also consider how much data do you want to return.
A separate endpoint is separate configuration on both client and server sides.
Related
Is there any effective ways to prevent message size quota exceeded for NetTCP service that returns an undetermined-sized collection? Example I have the following service:
public List<string> GetDirInfo(string path)
{
List<string> result;
result = new List<string>(Directory.EnumerateDirectories(path));
result.AddRange(new List<string>(Directory.EnumerateFiles(path)));
return result;
}
which basically just returns a list of directories and files in that given path. At times, I will reached the message size quota, e.g. return C:\Windows\System32.
Without changing message size quota, what is the best way to handle or prevent this sort of service call? A few ways that I can think of:
Convert to Stream service call
Implement Pagination
As a prevention, always check the size of result prior to returning.
Implement Callback mechanism where service will return a series of fixed sized result back to the client.
Is there any WCF configuration where the returned message will be split into multiple packets and reconstruct back by CLR while confining to the message size quota.
Edit:
I saw several postings on similar subject matter, but it all involved in changing the message size. I do not want to change the default message size to minimized DOS attacks.
I want to get some advise on the best practices and how you guys are handling/implementing such a case where the returning result might exceed the message size quota.
I did a test against a WCF server where the response from the server exceeds the MaxRecievedMessageSize property defined in the client-side binding object, resulting in a CommunicationException. I examined request and response using Fiddler. Despite exceeding the MaxRecievedMessageSize, the entirety of the response is sent to the client.
I believe I am missing the point of this behavior. As I see it, no bandwidth is saved as the data has already been received. The client application could have processed the data but the client binding has discarded before it is given to the application.
If saving bandwidth is not the purpose of the MaxReceivedMessageSize on the client-side, what is it for?
The answer is simple: security.
It would indeed be better for the bandwidth if your client could say to the server: "oh, by the way, don't bother sending me replies bigger than X bytes", but that is something they didn't implement :-)
And even if it was, what if the server has a bug, or is intentionally misbehaving...
What if the server returned a 2 TB string? Your client would then try to allocate a 2TB buffer to receive the request and will probably get a OutOfMemoryException. That would bring your client down.
First, I'd like to ask for the theory, because I didn't find any related documentation: We have a Silverlight client and a WCF service. The communication between them is through a pollingDuplexHttpBinding.
Suppose the server wants to sent to the client a message which its size is larger than the set MaxBufferSize and MaxReceivedMessageSize. What is going behind the scenes in that case?
Now, here is my actual experience with this issue:
The binding configuration on the server-side:
<binding name="eventServiceBinding" sendTimeout="00:00:10" inactivityTimeout="24:00:00" receiveTimeout="24:00:00" serverPollTimeout = "00:01:00"/>
Send a large (i.e. larger than the value set in client's binding's properties as described above) message from the server to the client. Then, send a second (not large) message => I got a send timeout for the second message (I don't know if the client ever got the first message).
I've tried to search for some helpful logging in order to see what happens with the first message. Done it both in the server side (by activating the WCF logger) and on the client side (by using Fidler). I've found nothing really interesting in the log (but maybe I didn't search in the correct places).
Moreover - when sendTimeout is set to large value (say 10 minutes), it looks like all additional messages sent from server to client are "stuck" - never received by the client and no exceptions are thrown until the send timeout is reached. In addition, I experience a strange phenomenon in which no communication between any client and any service exposed by the hosting IIS application is working - until I reset IIS. I am not 100% sure though that this is related to the previous problem described here.
Setting the MaxBufferSize and MaxReceivedMessageSize properties in the client side's binding seems to resolve both issues.
Please let me know if you have any experience with such issue and whether you can tell what's actually is going behind the scenes within WCF here.
I have run into the exception below a few times in the past and each time I just change the configuration to allow a bigger object graph.
"Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota."
However I was speaking to a colleague and he said that WCF should not be used to send large amounts of data, instead the data should be bite sized.
So what is the general consensus about large amounts of data being returned?
In my experience using synchronous web service operations to transmit large data sets or files leads to many different problems.
Firstly, you have performance related issues - serialization time at the service boundary. Then you have availability issues. Incoming requests can time out waiting for a response, or may be rejected because there is no dispatcher thread to service the request.
It is much better to delegate large data transfer and processing to some offline asynchronous process.
For example, in your situation, you send a request and the service returns a URI to the eventual resource you want. You may have to wait for the resource to become available, but you can code your consumer appropriately.
I haven't got any concrete examples but this article seems to point to WCF being used for large data sets, and I am aware of people using it for images.
Personally, I have always had to increase this property for any real world data.
I don't expect anyone to be able to help out with this but let's give it a go.
I have a WinForms app that uses a WCF service to pull down a rather large JSON document serialised into a string. I have changed the client's Reader Quota on strings to 8192000 (arbitrary but suitable for most cases) and put the service onto a custom binding with an explicit readerquota of 8192000
checking the service reference in Notepad by eye the quota in the .svcinfo files is set to 8192 although this could be a red herring.
I'm at the end of my tether, I've followed every piece of advice I can find on Google:
http://www.haveyougotwoods.com/archive/2008/03/29/wcf-and-large-messages.aspx
http://msdn.microsoft.com/en-us/magazine/cc163394.aspx
to name but two and all the suggested answers I could find on here i.e.
WCF service The maximum array length quota (16384) has been exceeded
WCF Maximum Message Size Quota
Maximum array length quota
and I looked at this:
http://wildermuth.com/2009/09/10/Using_Large_Message_Requests_in_Silverlight_with_WCF
which was a response to one of the above or one of the many other things I have looked at that I have not retrieved from my "Recently Closed Tabs" list.
Basically I can't think of anything else to do to increase this limit and yet it still insists upon first encountering a string longer than 64k in length that the limits have not been altered at all.
So could anyone just give me a really basic step-by-step to altering this one setting for a WinForms app serialising and then deserialising JSON data as a string on either end of the transaction? A lot of the other advice has been about silverlight or some other scenario and for whatever reason it just fails to affect this case.
I tried the solution as shown in the last article I linked to again, just to go over my previous work. This time instead of preventing the WCF services from working at all (which is what had happened previously) it instead started to work and upped the limits.
I don't know what I was doing wrong the first time or what I did right this time... one of those things I guess.