In WCF, you can create a one-way TCP Connection. How is this different from UDP?
Regarding WCF, [OperationContract(IsOneWay=true)] means that the method will not block until a response/acknowledgement appears from the callee. The underlying protocol is nonetheless TCP with all the nice features like retry, error checking etc.
See also the MSDN example
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!
Do tcp sockets have a built in method for calculating data corruption?
Thanks
Yes, the TCP protocol has a checksum. That checksum is small and using a weak algorithm, though. You cannot trust it with your life. It might be enough for youm or not. There are papers about it failing.
Note that sockets are a distinct concept from the TCP protocol. I assume you meant TCP, not sockets.
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
Reading about WCP (woof, what a monster of a subject), and just into the earlier stages of what transports are available. I note that TCP is available, but not UDP. Is this because UDP is not always reliable...lossy with packets ?
Thanks,
Scott
No official reason for that. Who knows may be we will have netUDPBinding in coming releases.
But most probably they gave priority to TCP as it is reliable.
I would certainly think so. UDP is useful for streaming video or audio, not for reliable messaging.