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.
Related
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.
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 :)
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.
I am looking at using MSMQ as a solution to do asynchronous execution in my upcoming project. I want to know the differences between using WCF and frameworks like MassTransit or even hand written MSMQ client to place/read task off MSMQ.
Basically the application will be several websites (internal through LAN or external through the Internet) reading/writing data through a service layer (be it WCF or normal web service). Then this service layer will do one of two things: 1. write data to database 2. and/or trigger the background process by placing a message in the queue. 3. obviously it can also retrieve data from database. The little agent (a windows service) on the other side of the queue will monitor the queue and execute based on the task command.
This architecture will be quite easy to scale (add more queues and agents) and easy to implement compared to RPC or distributed execution or whatever. And the agent processing doesn’t need to be real time. And the agent and service layer are separate applications except they share the common domain objects and Repositories etc.
What do you think? Architecture suggestions for the above requirements are welcomed. Thank you!
WCF adds an abstraction over MSMQ. In fact, once you define compatible contracts (operations must be OneWay), you can switch out MSMQ in the config, transparently. (For instance, you could switch to normal HttpWS or a NetTcp binding.)
You should evaluate the other WCF benefits, like security and so on, to see how those fit in with your needs. Again, they should be reasonably transparent of the fact you're using MSMQ underneath. For instance, adding SOAP security and so on should "just work", independent of using MSMQ.
(Although, IIRC, you still need to login to the desktop on each machine that uses MSMQ, with the service account that will use MSMQ, to generate the certificate in the machines local profile. And then, it doesn't work very well from IIS6, since user profiles aren't loaded. A real pain in general, but nothing to do with WCF specifically.)
Apart from that:
Have you looked at SQL Server Service Broker? After using MSMQ + WCF and SSSB, I think that SSSB is vastly easier to configure and manage. SSSB works with T-SQL commands over any SQL client (I use it from Mono, on Linux, with transactions). It'll also give you transactional send/receive, even remotely (I think MSMQ 4 now allows this). It really takes a lot of the pain away from message queuing, and if you're using SQL Server already...
SSSB is often overlooked since the SQL Management Studio doesn't have GUI designers for it all, but it isn't hard and is a great option. The one downside is that if you want local send capability (i.e., queue message when network is down), you'll need to run a local SQL Express instance.
Your architecture seems sound and reasonable. However you should consider using the WCF net MSMQ transport over hand coded MSMQ classes. WCF wraps this common functionality into a nice programming model. Also I believe there is some improvements in the protocol used by wcf compared to basic System.Messaging
Have a look at the value-add over plain MSMQ:
http://readthedocs.org/docs/masstransit/en/latest/overview/valueadd.html
In summary, you get a lot of messaging concepts clearly presented in the API with MassTransit; to an extent you wouldn't have if you hand-coded it or used WCF.