Question

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.

Answer 1

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!