When do you actually use TCP as a binding element and when do you use HTTP?
I want to know scenarios and performance issues.
TCP is must faster as compared to http. Even tcp is more secure and reliable.
Please refer http://msdn.microsoft.com/en-us/library/ms733769.aspx for more detailed information.
Actually choosing binding depends on many factors and reading above article will give you insight in more dept.
TCP will send less "valueless" data than Http. Http will add a lot of data when serializing it.
You may use TCP in a local network or a vpn.
Here you can see a chart of how to choose between these bindings:
http://bloggingabout.net/blogs/dennis/archive/2006/12/01/WCF-Binding-decision-chart.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 multiple applications (the producers) that produce messages to be processed by another application (the consumer). The messages will be sent through an ActiveMQ broker running on the same server. I don't have access to the applications' code, therefore the messages will be produced by executing a script (I currently don't know which language to use). The consumers will be Java application that will process the received messages.
I'm looking for an efficient transport that fits my use case. The VM transport cannot be used here. Also, I would like to avoid opening a TCP connection with the broker every time the producer script is executed (i.e. I would like to avoid using the TCP transport). I thought that UDP may be a good fit unless you know another transport which is more appropriate.
Thanks,
Mickael
There are pros and cons of both the TCP and UDP protocol
1)If ordering of messages and reliable-delivery of messages doesn't matter to you then UDP might be a nice choice,moreover in UDP it can also happen that duplicate messages are delievered to broker.
2)Using TCP offers reliable-delivery of messages along with ordering, but if you want to eliminate the stream Transport delay of TCP then you might think against it.
There are couple of others as well which you can retrospect based on your requirements
NIO protocol(USed in case of high traffic requirements)
HTTP protocol(In case you want to bypass firewalls)
Hope this helps!
Good luck!
If I was to implement a server to handle multiple clients connecting simultaneously would it be better to use TCP?
Not taking efficiency into account (I know know UDP is quicker, but unreliable).
In UDP you can't have sockets for each client connection?
Because in UDP the socket is identified by only the destination port number (right?).
In Java, I know it is easy to create a multi-threaded server to handle multiple clients at the same time in TCP. But can it be done in UDP? I imagine that it would be very complicated.
I'm just trying to get an understanding of UDP here (I don't want to actually implement anything).
It depends on what kind of server you are developing. If you need your clients to stay connected and ready to receive data from server(for example a push service) you should implement it using TCP. If you want to implement a simple request-response service, then UDP is better choice.
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.
Can anyone tell be where to use the UDP protocol except live streaming of music/video? What are default usecases for UDP?
UDP is also good for broadcast, such as service discovery - finding that newly plugged in printer.
Also of note is that broadcast is anonymous, you don't need to specify target hosts, as such it can form the foundation of a convenient plug-and-play or high-availability network.
UDP is stateless and is good for applications that have large numbers of clients connecting to a server such as time servers or DNS. The fact that no connection has to established and maintained reduces the memory required by the server. There is no handshaking involved and so this reduces the traffic on the network. On the downside, if the information transferred requires multiple packets there is no transmission control to ensure that all packets arrive and in the correct order - but in games packets lost are probably better than late or disordered.
Anything else where you need performance but can survive if a packet gets lost along the way. Multiplayer games come to mind, for example.
A very common use case is DNS, since the overhead of creating a TCP connection would by far outweight the actual payload.
Additional use cases are NTP (network time service) and most video games.
I use UDP to add chat capabilities to our applications. No need to create a server. It is also useful to dispatch events to all users of our applications.