I have a wcf application to upload files from clients to my server. I am using NetTcpbinding and WSHttpBinding but I need to control the bandwidth, how can I accomplish this??
AFAIK, there is no built-in throughput throttling at the WCF level. You might be able to leverage the QoS features built into Windows for that, but honestly, I've never tried it. I guess you could always write your own transport channel that supports it, though.
Related
I have a windows phone 8 application, which communicates with WCF service using basicHttpBinding. The service is hosted on IIS7 (and not using windows azure)
As the service may go down for any reason, I am exploring the use of message queues to increase the reliability of the system.
I have looked at NetMsmqBinding provided in WCF - but it looks like this binding is not supported by WP8 client.
I am also looking at using RabbitMQ, but cannot find any working example with WP8 client using WCF.
Please can anyone suggest what is the best way forward? Any sample code (or links) will be much appreciated.
Thanks
First off, netMsmqBinding cannot be used across the internet. This is because it uses MSMQ which is not exposed over http.
When you're making calls to a resource across the internet, unreliability is something you need to factor into your application. Because of the number of possible problems you can encounter, it's generally not a case of if, but when, there is a failure and it's how your application deals with this which is important.
Even so, there are things you can do to minimize the reliability issues you experience, one of which does involve queuing.
Where queuing can be useful is taking large, complex, and long running processes offline. Because calls to such processes implemented synchronously often time out, you can gain a lot of reliability by making the actual processing call asynchronous.
As an example, it would be fairly common to have the web server invoke some offline process via message queuing and return to the client that their request is being processed. Because doing this is inexpensive calls are far less likely to fail. Your problem then becomes one of how to return the response to the client once the offline processing has been done.
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.
Is there any standard way of implementing some sort of a write-through buffer for a WCF call? I need a mechanism to be able to write to a bufffer or cache which gets persisted and then writes it to the service. If the service is down the call will be transfered when the service is up and running again. I know you can use WCF over MSMQ which does exactly what I need, but I wounder if there is another way of doing this, so I don't need to deploy MSMQ to the client.
Best regards,
Michael
The problem is that MSMQ is designed to do this - if you want to do this without MSMQ then you must implement your own queuing mechanism that functions like MSMQ and deploy that to the client.
Due to deployment restrictions, we can't deploy WCF on the client-side (yet) but would like to use it on the server-side.
I am interested to know if it is possible to use WCF on the server but consume it with .NET remoting on the client side. I don't have any problems with using specific bindings, transfers or protocols on the server side to make this happen.
It is definitely possible - here is a good place to start.
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.