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.
Related
I am looking in for the best way to implement the RabbitMQ consumer by using .Net Client which should be run as windows service.
I referred the RabbitMQ documentation and found the way to consume messages by using .Net client (https://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html).
My current scenario is like, RabbitMQ is installed in AWS VM machine. I have to install dotnet client consumer service resides in On-premise network which should consume messages.
Which one is the best way, to always listen the Queue (AMQP protocol) or HTTP API which should get messages on demand (https://pulse.mozilla.org/api/).
Please advise.
Thanks,
Vinoth
I believe the answer is "neither." You should have your message queue as a back-end service behind the firewall, and expose your application functionality through a set of carefully-specified web services. The web services, which are exposed through the firewall but can communicate to services behind the firewall, would produce messages that would be transmitted to the server. Any services needing to produce or consume messages would need to do so via the web services, which would perform safety/security checking prior to forwarding the request on to the AMQP server.
If you need to expose AMQP directly to clients (i.e. that is the purpose of your app), then the recommendation is to do so via STOMP. I think a valid use case for exposing AMQP directly over the internet would be a rare thing to come across. The security implications of doing so would be immense.
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.
WCF has the following binding options:
http(s)
net.tcp
MSMQ
Couple of questions:
AFAIK, http(s) is actually a higher level protocol on top of TCP protocol, and net.tcp is in fact TCP protocol. So why do we have them both? Why not just have a single TCP protocol?
Could MSMQ be used across machine boundary?
If I want to have other binding options, what should I do?
Thanks.
The netTcpBinding is indeed a "lower level" protocol, and as such, it's also a tad faster than http. It works great in intranet/local network environment - inside your company.
But the netTcpBinding doesn't cross firewalls and routers very easily - you would have to start opening ports and that's something that has lots of security implications and thus is often hard to get done, especially in larger companies.
The http bindings of WCF works over port 80 - which is open on just about any firewall - so these bindings offer you more reach - your clients and folks from outside the company can talk to a service like this a lot more easily than to one that uses netTcpBinding.
The beauty of WCF is this: you can have a single service, but you can expose two endpoints - one using netTcpBinding (fast, binary encoding) for local clients - and a second 'basicHttpBinding` endpoint for clients calling from outside your LAN. There's nothing in the service implementation code that needs to know about this, nor do you have to program differently whether you're using nettcp or http. WCF handles all this for you.
MSMQ is a totally different beast - while netTcp and http bindings work in a "connected" fashion - you call the service and wait for an answer - the MSMQ binding is a queue-based system. In this case, you drop a request into a queue - and you're done right away. Some time later, the queue will be processed by some kind of a worker process or program, and something will be done. And you might be notified in some way (e-mail, response message on another queue or something) - but the a) calling the service, b) processing the message and c) getting a response are totally decoupled and can happen within seconds - or it could take days. And YES! of course MSMQ works over machine boundaries!
After developing mini project with WCF duplex (Chat Service | Sms Service), I got a Point that maybe not be correct!!
I believed Duplex theory is good and useful but there is a lot problem about using Wcf Duplex. (like reliable session, Time-out exceptions, Client address-Management on server side, proxy management on Client Side)
am I think wrong ? am I miss something?
For more Information I Used wsDualHttpBinding not tcpBinding.
If you need bidirectional communication and you want to use WCF, duplex channels are the way to go. You just need to design your application correctly and correctly handle all problems you have described. If you feel that these problems are overhead and make things even worse you can always use network programming directly (sockets) or handle bidirectional communication by yourselves exposing separate service on server and another on client (where first call from client inform server about clients address) - this scenario will suffer from the same communication problems as WsDualHttpBinding.
WsDualHttpBinding itself is special kind of duplex communication. I personally don't like it because people very often misuse it. The problem is that this binding uses two separate connections - one from client to server and second from server to client. That is big difference to net.tcp where only connection initiated from client to server is used. Obviously using WsDualHttpBinding over internet (= you don't have control over client machines) becomes much more complicated because each client must configure its firewall (in computer, on home internet gateway, etc.) to allow connection on some port. Also if you want to run more then one instance of application on the same client machine, each instance must use its own port.
Just a technology update, now that .NET 4.0 is out.
I write an application that communicates to the server through what is basically a message bus (instead of method calls). This is based on the internal architecture of the application (which is multi threaded, passing the messages around).
There are a limited number of messages to go from the client to the server, quite a lot more from the server to the client. Most of those can be handled via a separate specialized mechanism, but at the end we talk of possibly 10-100 small messages per second going from the server to the client.
The client is supposed to operate under "internet conditions". THis means possibly home end users behind standard NAT devices (i.e. typical DSL routers) - a firewalled secure and thus "open" network can not be assumed.
I want to have as little latency and as little overhad for the communication as possible.
What is the technologally best way to handle the message bus callback? I Have no problem regularly calling to the server for message delivery if something needs to be sent...
...but what are my options to handle the messagtes from the server to the client?
WsDualHttp does work how? Especially under a NAT scenario?
Just as a note: polling is most likely out - the main problem here is that I would have a significant overhead OR a significant delay, both aren ot really wanted. Technically I would love some sort of streaming appraoch, where the server can write messags to a stream while he generates them and they get sent to the client as they come. Not esure this is doable with WCF, though (if not, I may acutally decide to handle the whole message part outside of WCF and just do control / login / setup / destruction via WCF).
For bidirectional communications, your best bet is NetTcpBinding, rather than the http bindings, if they're available.
This has the advantage of only requiring that the client can initiate a connection with the server.
I would go with Windows Azure Service Bus. See my answer in the following question:
WCF, 4.0, Bidirectional
Take a look at Windows AppFabric, good place to start is Here. It fundamentally wraps up WCF and WF into an application server, with WCF activation supported through WAS. Its where I would host this type of app. It offerd full duplex connection orientated, p2p or sessions between client and server. Don't confuse the Windows appfabric with Azure appfabric, (formely called Azure Service Bus).
As regards bindings above, both NetTcpBinding and WsDualHttp offer callbacks, but the ws binding you get a lot for your cash, especially if it's a mixed programming environment and you have to flatten the wsdl to make interop work. I also think that WsDual is easier on routers traversal, although I understand talking to friends, that Windows AppFabric mitigates this, with new Relay Services, (which i've not seen, and I think have now been renamed).
Hope that helps.