none
WCF 4.5 gzip compression, net.tcp binding and maxReceivedMessageSize RRS feed

  • Question

  • I have successfully configured WCF gzip compression using net.tcp binding wrapped around custombinding.

    However the whole idea for me to go this route was to transport compressed data across the wire; which I think is working based on my WCF tracing output and fiddler intercept. However, if I sent or receive a data load of greater that 64KB I still hit the maxmessageexceeded issue. I know that I can increase that value by setting the “maxReceivedMessageSize” at both the client and server end; however I thought that with gzip compression in WCF 4.5 I will not hit that default maximum limit of 64KB with the same data (not the data without gzip compression is around 70KB). So in a nutshell I am still having the same issue that I was trying to avoid with using compression. Can someone help me understand why this is happening. I think what is happening is that the “maxReceivedMessageSize” is checked after the message is de-compressed; can someone throw some light here.

    Appreciate your help.

    Wednesday, August 28, 2013 1:07 AM

All replies

  • Hi,
    From your description, it seems that your message size is bigger than the original size after using the WCF 4.5 gzip compression.
    Here is a test result by using GzipMessageEncoder in wcf in this article:

    Original size: 751
    Compressed size: 1024

    Original size: 426
    Compressed size: 512

    Original size: 2714
    Compressed size: 1024

    Original size: 2382
    Compressed size: 1024

    From the result, it looks like small messages actually get bigger after compressing.

    And this article already tells how to fix this question, please try to refer to:
    #Compressing messages in WCF part one - Fixing the GZipMessageEncoder:
    http://blogs.msdn.com/b/dmetzgar/archive/2011/03/10/compressing-messages-in-wcf-part-one-fixing-the-gzipmessageencoder-bug.aspx .

    Best Regards,
    Amy Peng


    <THE CONTENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED>
    Thanks
    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.


    Wednesday, August 28, 2013 7:04 AM
    Moderator
  • Amy

    Thanks for responding. I am not using the custom GZip encoder that we were forced to use before WCF 4.5. WCF 4.5 supports through custom binding gzip  out of the box (however, the sample GZipEncoder that we have from msdn also has that same issue, my original message is greater than 64KB, all I am doing to simulate this problem is send a string that’s greater than 64KB across)

          <customBinding>

            <binding name="BinaryCompressionBindingServerSide" >

              <binaryMessageEncoding  compressionFormat ="GZip"/>

              <httpTransport />

              </binding>

           

          </customBinding>

     

    Here is my server side custombinding for WCF4.5. FYI: In prod I have <tcpTransport />.

    My original message is bigger not smaller (the way I can tell is via fiddler, and I control the size of the message using the string technique that I explained before, I just assign a bigger size to my string variable to break the 64KB barrier). The WCF service is hosted on IIS and I have gzip encryption enabled. I am able to see through fiddler that my data is getting compressed while in transit (Or at least that’s what I see when I trap the WCF service request from my client (I am using Fiddler as a reverse proxy middleman).

    Can you help? I can upload the sample if there is a way to do that in this forum. But the code is pretty straight forward. I use custom binding at both ends with GZip enabled on client as well as server end. Since I am running it from VS2012, I have enabled gzip on IIS express (that’s pretty straight forward, all you need to do is change the applicationhost file)

     

    Any help/pointers. Once again thanks for responding


    Wednesday, August 28, 2013 10:35 AM