CODEWITHSUNDEEP
c#wcfhttpwebrequestbasichttpbinding
jamespconnor
jamespconnor

Reputation: 1422

Packet fragmentation in the WCF stack using BasicHttpBinding, http header and soap envelope always split by a packet boundary?

I have a problem whereby I have lots of very small web service calls to a Java endpoint (hosted on Oracle GlassFish 3.1.X). I added this service as a Service Reference (using the remote wsdl file) and use a BasicHttpBinding to reach it.

Since the service is located half the world away plus going across the internet, we frequently experience some packet loss when reaching the destination. We are looking at any way possible to reduce the impact of these occurrences. We have been using Wireshark to give us detailed knowledge of what is going across the wire to our destination, and back again. I was curious to see that for every single request we generate, we are sending 2 packets. The packet boundary is always between the HTTP header and the <s:Envelope> tag. To me this is a big overhead, particularly in my environment where I want to minimise the amount of packets sent (to reduce overall packetloss).

In most cases (99% of our calls), the HTTP header packet is 210 bytes followed by a SOAP envelope packet of 291 bytes (excluding the 54 bytes of TCP/IP overhead for each packet). Totalling these gives 501 bytes - just over a third of our Max Segment Size of 1460 bytes. Why isn't WCF sending this HTTP POST request as a single packet of 501 bytes (555 bytes if you include the 54 bytes of TCP/IP overhead)?

Wireshark reassembly screenshot

Does anyone know why it does this? It almost seems as if the HttpWebRequest object is calling .Flush() on the stream after writing it's headers but I'm not sure why it would do this?

I've tried different combinations on these:

ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false;

With no effect.

EDIT

Wrong: I've investigated a bit further and when a HttpWebRequest.GetRequestStream() is called, it does write the headers to the stream immediately. At some stage before you write to the Stream that is given back to you, the network would Flush these (I guess? Unless a deliberate flush is happening somewhere). When you finally start writing to the stream, it has already sent the header packet. Not sure how to prevent this, it seems a very hard assertion inside the HttpWebRequest code that called GetRequestStream() will write the headers. For my small requests, I want nothing to be written until I have closed the stream but that goes against the streaming nature of it.

Upvotes: 4

Views: 1095

Answers (1)

jamespconnor
jamespconnor

Reputation: 1422

And the answer is - Can't be done with WebHttpRequest (and hence BasicHttpBinding)

http://us.generation-nt.com/answer/too-packets-httpwebrequest-help-23298102.html

Upvotes: 1

Related Questions