I am currently working on an Owin self-hosted web service that runs on my machine and that allows peers (other machines) to download files from its virtual directory with microsoft's BITS. The downloads will work with relatively small files, but whenever I have to download large files (over 2Go) I get this error from BITS:
"The server does not support the necessary HTTP protocol. Background
Intelligent Transfer Service (BITS) requires that the server support
the Range protocol header."
I was wondering if there was a way to enable the Range Requests in Owin or if I have to implement manually the "data chunking" in the requests I receive. Because changing the content of every request to have the header "Accept-Ranges: bytes" doesn't seem to work (I assumed it would not magically worked, but I tried it anyway).
I couldn't find a lot of information on what I am trying to do besides finding out how to know if a server is supporting the range requests.
There was this question that seemed to look similar to mine, but was more focussed on setting the headers properly. It doesn't really show if/how the code splits the file before returning the response. There was also something about IIS, but my web service doesn't run on IIS, it runs on the client's machine and is instanciated by a windows service.
I found a solution to my problem. With a little bit more research on the subject, I discovered this article which sums up really well the problem I had, which is that requests going trough ASP.NET Http Handlers do not support Range-specific requests. So I will have to manually implement support for the range specific requests in my web service.
Related
I have my own WinForms c# application and want to add some API functionality. I also have up and running Windows Server 2012 with IIS that is used for third-party application.
The problem is I can't wrap my mind what would be the most effective (= scalable, secure, manageable, powerful but simple enough) way to grab GET and POST requests in my desktop c# app (and respond to them). There're too many options range from c# web-server embedded library (simplest solution) to the newest ASP.net-based frameworks (most complex ones require too much learning).
I think it would be reasonable to avoid setup another c#-based server just to deal with HTTP requests and use the power of existing IIS instead.
Could you please advise specific library, sample code or walkthrough how to deal with HTTP requests in WinForms through IIS but without overwhelmingly complex ASP solutions?
IIS only listen to http.sys so IIS application pool will only handle the request delivered from http.sys.
This link is about how IIS handle these requests
[What is request-processing pipeline?
The special IIS pipeline decide that you can't force IIS listen to your Winform application directly.
Now that http client is not capable, may I know how did your winform application receive http request?
I think you could host an web app in IIS then proxy these request to IIS web app. You need make some code change in winform application so that IIS would help you handle the incoming GET/POST http requests.
I ended up with ASP.NET app with regular API controller, that is how to those things are supposed to be built. Works great. Adding API to WinForm was definitely bad idea.
I have a windows service running in a production environment that I need to perform some diagnostic work on. The service listens on a specified port, receives and processes a TCP request, and issues a TCP response.
What I'd like to do is intercept this request and response so I can log it to a database. However I cannot recompile the code and need to make as few changes to the server as possible.
I seem to recall a past instance where a colleague was able to create an interceptor DLL and drop this into the root folder of a WCF or Web API service in order to accomplish a similar task. Would it be possible to accomplish something like that with this TCP service?
As long as the app uses System.Net.Socket, you can use the built in .net network tracing via app.config, docs from Microsoft here.
Adding source System.Net.Socket and System.Net with maxdatasize 1024 will cause it to log the first 1024 bytes of each send and receive.
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth. Almost all the examples or information I have found are about using web sockets for Client/Server Side communication. I am having trouble figuring out how to set this up. I have considered using WebSocketHost as apart of Microsoft.ServiceModel.WebSockets, but then I am unsure how to bind it to a local port and not a URL.
Does any one have any suggestions
Thanks
I am trying to use web sockets to allow two Windows services on different machines to pass data back and forth.
You can open sockets on both machines using WebSockets as you found. The examples mention clients and servers because this is the typical usage, however the API really doesn't care. As long as each side has a listener and a sender they can communicate.
However I would like to mention that this isn't as simple as it sounds because both machines aren't always available. Sometimes one or the other is busy or the network is blocked or something else is going on, or the listener is too busy to respond right away, so you're going to end up needing some sort of queuing on both sides.
If you're doing a process based operation where one side tells the other "I want X" and it's a big operation like producing a document, I've found it much more resilient to build a queue in a database and toss the request in there, then wait for the other side to update the record to say it's done.
If they're smaller, faster requests, MSMQ would be more appropriate if you have it available.
However back to your original question, if you want to use it, any of the client-server examples should work just fine. The API doesn't care.
You can use SignalR Self-Host you really don't want to create your own WebSockets framework since this this will take a long time.
Here is a link on how to start a OWIN server in Windows services.
Hosting WebAPI using OWIN in a windows service
And how to set signalR in self host
Tutorial: SignalR Self-Host
You can accomplish this with Memory Mapped Files.
Inter-Process Communication with Memory-Mapped Files
I have a windows service which monitors a directory and whenever it detects a new file it will send that file to my web service for processing. I've now noticed that it's become a bit of a bottle neck sending the file using the web service request, so I was trying to work out what the alternatives are?
I've thought of having the Windows Service doing the processing directly (which I'd ideally like), but this isn't an option. Would it be better to be using WCF? In 90% of deployments the Web Service is on the same server as the Windows Service, but there is that 10% where it's on different servers. Just not sure what the best approach would be here...
EDIT: I'm sending the file as a byte[] to the Web Service, this is what I am wanting to somehow speed up. So the question I have is, would using another approach help speed this up, such as using WCF and a different protocol? I understand there is always an overhead, but trying to minimize this.
WCF & Bindings: Changing to WCF offers several bindings you can use that are more efficient to transmit data in a LAN, e.g. NetTcpBinding or Named Pipes (local only). So using WCF is a good step if you don't want to introduce bigger changes into your application.
Hybrid approach:
However, the best way to speed up at least for the 90% of deployments that host both components on the same machine is to remove the process boundary in these cases. As you mention, you've already thought about that. So just in case that the reason for putting the idea aside are the 10% of deployments that would require a distributed installation: By using an interface with an implementation for local procession and one for remote transmission, you could implement a configurable approach that supports both scenarios (90% very efficient, 10% at least not slower as before).
Scaling down data sizes:
Another - obvious - way to speed things up is to filter or compress the file contents before transmitting them to the service.
File path instead of contents:
As I understand your environment, the machines that host the services are at least close to each other (LAN, no firewall issues, ...). So it might also be a viable option not to transmit the file contents to the service, but to notify the service of the file path and have the web service access the file directly. Though not a very beautiful way with certain downsides (e.g. account of web service must be able to access the file, path must also be accessible from the web service) you'd at least get rid of the inefficient transmission of the files and substitute that with a protocol that is built for file access. Also in the 90% of installations where both services run on the same machine, the web service would do a local file access that should be very fast.
From time to time we need to test why a certain request coming from our MQ to a WCF service failed. I need to be able to debug the service and find out where it went wrong and resolve the issue. The only information i have is the XML request that was sent to the service. Before we moved to WCF i used a custom tool to send the request to my ASMX debug instance but since we moved to WCF I dont seem to have that option. All the clients i have tried only allow you to fill in the fields through a UI and this is not an option when dealing with huge requests.
Is there a free or open source client that will allow me to do this? I have searched and tried loads but none seem to do it.
Alternatively is there a tutorial or article on writing a test client of this kind? Again i have searched but there seems to be a lack of information on WCF clients and a huge amount on the services.
tl;dr; Im looking for a WCF test client that will allow me to paste in an XML request and send it to a WCF service or a tutorial that will start me in the right direction.
Of course it is not free, but one of our teams is using Altova XMLSpy for that purpose and it works fine.
You can also check (Not sure they will allow you to edit SOAP, but have a try):
SoapUI
WCF Storm
Also check Web Service Studio 2.0 I have tried it will allow you to edit requests.
Not sure I totally understand what you're looking for:
to see the MSMQ messages, you should open the MMC snapin for MSMQ administration on your server where the MSMQ queues live - is that what you're looking for?
in order to create and send out arbitrary XML messages, have a look at SoapUI which is available in a free (and already very capable) version, or alternatively look at SoapBits