Can we use net.TCP binding to implement GZip in WCF or it can only be configured with Http and WsHttp bindings.
I don't believe WCF supports GZip encoding using a TCP socket binding, however there is nothing stopping you sending GZiped compressed data over the wire, and manually compressing it using the methods built into the .NET framework: http://msdn.microsoft.com/en-us/library/system.io.compression.gzipstream.aspx.
Before you go down this route however, I would strongly recommend assesing other performance enhancing measures on your TCP services as detailed here: Transmitting the least amount of data over the wire with WCF
Wcf 4.5 RC support message encoder out of box
http://msdn.microsoft.com/en-us/library/aa751889(v=vs.110).aspx
Related
I have read about transport schemes supported by WCF several times. It looks very theoretical.Almost everywhere it is described as:
Following are the transport schemes supported by WCF:
HTTP/HTTPS - http://localhost:8001/MyService
TCP - net.tcp://localhost:8002/MyService
IPC - net.pipe://localhost/MyPipe
Peer network
MSMQ - net.msmq://localhost/private/MyQueue
Service bus - sb://MyNamespace.servicebus.windows.net/
However I could not understand who would require to consume WCF over TCP or IPC or MSMQ. Can anyone give a practical example of who would really need to consume WCF over TCP or any other sceme than HTTP and how would they do so?
Consuming a WCF-Service over TCP is in my case the most common way if you want two or more Programs to communicate. WCF over tcp can easily replace IPC-Communication.
For example:
You have a Windows-Service hosting an WCF-Service. With Vista and later you have to deal with the Session 0 isolation.
You now want to communiacte with that WCF-Service. A common way to achieve that is a tray-application.
Most Anti-Virus programs do it like this.
If you are operating on the same machine, tcp is way faster than HTTP-Binding.
I have found Tim's comments very useful. I have gone through the link he had provided and I will try to summarize whatever I have got from it.
When to use TCP - When host is WCF and consumer is WCF as well use TCP. The communication would be much faster than HTTP.
When to use Named pipes - When host and consumer both are WCF and reside on same machine. The communication would be faster and the
access to the host would be denied from other machines.
You can refer this image for more details about choosing appropriate transport. To dig down further refer this.
I have a WCF service and a tcp binding. By the moment, the transfer mode is buffered, the default option, but I have problems with file transfers, so I have been advised that perhaps it's better to use the streamed transfer mode.
I configure my service for this transfer mode, and in the client, I only change the transfer mode from Buffered to Streamed.
Then, when I run the application, I get the following exception:
the tcp binding does not support duplex contract or the duplex
contract is not correctly set
I only change the transfer mode, so this makes me to think that perhaps streamed is not compatible with a tcp duplex contract?
Thanks.
netTcpBinding in duplex mode does not support streaming, it only supports streaming for a request/reply exchange pattern (which is not duplex). What you can try doing is removing your callback, and make a service on the client which will simulate the callback. So you have your client sending data to your 'main' service, and your main service replies by streaming to the client's service, though I have no idea how much of a good practice this is considered to be.
Can someone help to what are the major diff between netTcpBinding v/s BasicHttpBinding ?
In my current project we convert BasicHttpBinding to netTcpBinding and get performance issue, it start timing out even thou the value in BizTalk is set to 1:00:00. We couldn't figure out why ?
netTcp and basicHttp bindings use entirely different transport mechanisms: TCP instead of HTTP. In theory, the binary encoding of TCP should be faster than the text encoding of HTTP.
As discussed here, netTcpBinding may not be as fast, because of additional security overhead and/or contention:
By default, NetTcpBinding enables certain levels of security add
overhead to the message processing pipeline of the WCF runtime.
Additionally, the NetTcpBinding also enables the port sharing feature
which means that your WCF host won’t have exclusive access to the port
and instead might share it with other applications. This might get
very interesting if you are hosting your service in a Windows Server
2008 or Windows 7 environment given that there are a number of Windows
applications that rely on NetTcpBinding endpoints. Finally, the
default values for theListenBacklog and MaxConnections settings are
set to 10 which is far from optimal for a large number of clients.
Also note that without more information on what part of communication is timing out, it's difficult to say the exact cause. Remember, each side of the transaction has different timeout settings for Open, Close, and Send or Receive.
My last experience with WCF 3.0 was pretty bad, because of this I reverted to using ASMX. I now see that WCF 4.0 seems to provide a better configuration model, my only concern is that with WCF 3.0 I had a lot of timeouts on extended service calls, however with asmx these timeout values can be configured through IIS and also accept the negative integer value of -1.
Does WCF 4.0 default configuration support getting timeout values from IIS, or once again do you need to configure the timeouts to handle extended web service calls that take time to complete (could be up to 6 hours).
Thanks
In WCF you have configuration level control over timeouts on both servers and clients by editing the binding configuration. Since WCF was not designed to be coupled with IIS I don't think you can inherit the timeouts from IIS so you might have to set them in both places.
Check this link for the documentation on the basicHttpBinding element (which is used for SOAP 1.1): http://msdn.microsoft.com/en-us/library/ms731361.aspx
And this one for details on different timeout configurations in WCF: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/84551e45-19a2-4d0d-bcc0-516a4041943d/
I have personally used the timeout configurations in different .Net 3.5 projects and they worked for me.
WCF by nature is transport agnostic so the configuration has to accommodate for transport types not having timeout.
Problem in HTTP is if you have one timeout for HTTP and one explicitly for the WCF, there will be a conflict and that is why you have to define them separately.
I believe WCF is a big fudge, an being transport agnostic causing performance degradation while easing with deployment and configuration. Having said that, I think it is far superior to ASMX, IMHO :)
we hosted WCF services in IIS 5.1 wndows xp sp3 with httpBasicBinding. The data tranferered is huge in size and transfered every 1 minute. For this to less data transfer Is it possible to compress the response of WCF service by using default http compression ? Can I have some sample code / article for using http comression in WCF?
nRk
There's a project on Codeplex available, I've used it successfully in projects.
See here: http://social.msdn.microsoft.com/forums/en-US/wcf/thread/5c67b0da-9e50-4ee1-b7ac-a4733c580980/
Anyway, have you considered compressing the data before it is sent, and uncompressing it back upon reception?
Another option would be to explore the streaming capabilities of WCF: http://msdn.microsoft.com/en-us/library/ms731913.aspx