I couldn't find an exact example of what I'm looking for.
I have a REST/WCF endpoint that takes in a Stream and returns a Stream. I am able to do "live" streaming of the request, by that I mean that the incoming stream gets read by the service as it is written to by the client (using a shared buffer stream in the service).
I would like to achieve the same thing on the outgoing stream but all the examples I found write all the data to a local stream then return it back to the client.
How can I access the underlying stream of the response and start writing to it, allowing the client to start reading from it without exiting my service method?
Is it even possible to achieve what I need with WCF and HTTP streaming?
Related
I have a service (A) that retrieves JSON from another service (B) and sends it back to the client.
The HttpContent.ReadAsAsync<object>() API works fine, however it seems this needlessly requires more memory allocation. Afterall, we already have a representation of the JSON bytes via HttpContent.ReadAsStreamAsync().
What would be the most efficient way to forward the body from service B to the client, without needing to deserialize?
I am not using .NET Core, so the Response.Body stream isn't available.
You should restream response from Service B to the client using Response.OutputStream
I have an HTTPListener based .NET webserver, which generates data on request and outputs it. I am using StreamWriter to write to the output stream. When I write the data, not all of it gets received in Chrome, but all of it gets sent in the code. If I go to view source, it only shows part of the data that was sent.
It almost seems like some kind of timeout, or it getting too big, or something. Is there something that needs to be set in the HTTPListener or the request context?
As per the comments:
Call Flush on the stream before it is sent.
I need to create a WCF Service that will have a download file function. This WCF will be consumed by a Delphi application.
The problem: The files that will be downloaded are very large and may cause memory problems on Delphi side. So far, I have this code:
[OperationContract]
byte[] DownloadFile(string filePath);
But this code will cause the client app to hold all data in memory which can be an issue.
I have read that WCF is capable of streaming data as you can read at: How to: Enable Streaming
But I have a question regarding this piece of code cut from MSDN:
[OperationContract]
Stream GetStream(string data);
On the client side I want to pass a TFileStream to the function. By using TFileStream every byte read will go directly to the disk. But the function RETURNS a stream and what I want will not be possible since the stream will not a parameter to the function.
How can I download a file from a WCF service directly to the disk?
I have found that relying on "built-in" streaming capability in WCF when working with other (non-.NET) clients is a big source for strange problems...
Basically we solve this kind of scenario by defining:
[OperationContract]
string DownloadFile(string filePath);
The method generates a HTTP(S) url and returns it...
This way any http-capable client can work with the data in a robust fashion...
BEWARE that this makes the server a bit more complicated since you now need to have some mechanism to generate (and serve HTTP GET on) URLs (security, "globally" unique, only usable for a limited time etc.).
BUT the big advantage is that any client out there (mobile or some strange embedded device or whatever you might encounter) will be able to implement this scheme as long as it has http-support available (Delphi has some very good http-client options).
First of all, I'm not sure whether you can consume a streaming WCF service at all in Delphi 2010. If you can, then it works as follows:
The WCF service must be a streamed service, which means that you need to set the transferMode of the binding to Streamed or StreamedResponse. If you want to pass in a string as parameter, it must be StreamedResponse, otherwise, the parameter must be a stream as well.
Having a streamed service also means that there can be no method that does not return a stream or void. It is, for example, not possible to have the following two methods in the same service when it is a streamed service.
Stream GetStream(string s);
int GetInteger(string s);
Also it is not possible to have:
Stream GetStream(string s);
in a service which is configured to be Streamed, as the parameter would have to be a stream, too.
It is not possible to call the method with a stream which will be "filled", even if you make the method take a Stream parameter - not the real instance of Stream is passed back and forth at that point, but the content is actually copied back and forth.
In Delphi you'd get a stream as a result of the method call. You can then copy the contents of that stream into a TFileStream as you'd do if the source was another stream in Delphi. Code for that can be googled. Basically Adriano has posted something that should work. Basically: Read from the source stream, write to the destination stream until everything was read and written, or you could try something like that:
stream1 := wcfServiceClient.GetTheStream();
try
stream2:= TFileStream.Create('to.txt', fmCreate);
try
stream2.CopyFrom(stream1, stream1.Size);
finally
stream2.Free;
end;
finally
stream1.Free;
end;
Again: This works only under the assumption that you can access a WCF streamed service from Delphi as you'd access it from C# or VB.NET.
Hihi all,
I am able to return stream from my WCF restful json webservice, everything works fine. But when I mixed the stream with another piece of data (both wrap into a custom class), upon consuming the webservice from my client, it gives an error message of "An existing connection was forcibly closed by the remote host".
Any advice how can I achieve the above? What it's required for my webservice is to allow downloading of a file with the file length as an additional piece of information for validation at the client end.
Thanks in advance! :)
There are various restrictions while using Stream in WCF service contracts - as per this MDSN link, only one (output) parameter or return value (of type stream) can be used while streaming.
In another MSDN documentation (this is anyway a good resource, if you want to stream large data using WCF), it has been hinted that one can combine stream and some input/output data by using Message Contract.
For example, see this blog post where author has used explicit message contract to upload both file name & file data. You have to do the similar thing from download perspective.
Finally, if nothing works then you can always push the file length as a custom (or standard such as content-length) HTTP header. If you are hosting in IIS then enable ASP.NET compatibility and use HttpContext.Current.Response to add your custom header.
I'm using the System.Net.HttpWebRequest class to implement a simple HTTP downloader that can be paused, canceled and even resumed after it was canceled (with the HTTP Range request header).
It's clear that HttpWebRequest.GetResponse() is when the HTTP request is actually sent to the server, and the method returns when a HTTP response is received (or a timeout occurs). However, the response body is represented with a Stream, which leaves me wonder whether the response body is actually transmitted with the response header (i.e. it's already downloaded when GetResponse() returns), or is it only downloaded on-demand, when I try to read from the response stream? Or maybe when I call the HttpWebResponse.GetResponseStream() method?
Unfortunately the msdn documentation doesn't tell, and I don't know enough about the HTTP protocol to be able to tell.
How do chunked transfers and the like behave in this case (that is, how should I handle them in my C# application)? When is actually the response data downloaded from the server?
This all depends on TCP, the underlying protocol of HTTP. The way TCP works is that data is sent in segments. Whenever a client sends a segment to the server, among the data sent is information about how much additional data is it ready to receive. This usually corresponds to some kind of buffer on the client's part. When the client receives some data, it also sends a segment to the server, acknowledging the received data.
So, assuming the client is very slow in processing the received data, the sequence of events could go like this:
Connection is established, the clients says how much data is it ready to receive.
Server sends one or more segments to the client, the total data in them at most the amount client said it is ready to receive
Client says to the server: I received the data you sent me, but don't send me anymore for now.
Client processes some of the data.
Client says to the server: You can send me x more bytes of data
What does this mean with regards to GetResponse()? When you call GetResponse(), the client sends the request, reads the HTTP header of the response (which usually fits into one segment, but it may be more) and returns. At this point, if you don't start reading the response stream (that you get by calling GetResponseStream()), some data from the server is received, but only to fill the buffer. When that is full, no more data is transmitted until you start reading the response stream.