My application consists of a WCF web service and a silverlight client. I need to transfer data on the order of GBs. Is it possible to send compressed data so that it can be uncompressed by the client when it is received? What classes can I make use for this?
I never had to use it but maybe you should take a look at SharpZipLib (An open source dll for compression)
Here's also 3 links about WCF compression:
http://bloggingabout.net/blogs/ramon/archive/2008/11/06/wcf-and-http-gzip-deflate-compression-and-silverlight.aspx
http://weblogs.asp.net/cibrax/archive/2006/03/29/441398.aspx
http://frenk.wordpress.com/2009/11/08/gzip-compression-between-wcf-web-service-and-silverlight/
Related
I am a WPF newbie and has little experience with C# thread programming. I am assigned a C# WPF application with multi-threading. The requirements for that application is to upload local big files to a
destination folder named "ABC" that sits directly under the root disk driver (e.g. C:\ABC) on a remote server that runs under
Windows platform. I do not know the directions to go. Please advise. Thank you.
Follows are details about the requirements:
Because each uploaded file size is big, there needs a separate thread to run the upload file function.
I plan to use thread programming with async/await and Task object. Any idea?
In WPF I do not know which WPF control to use for upload function. Please help.
For destination folder "ABC", do I need to set its access permission explicitly?
I should use async/await and Task, or BackgroundWorker class?
Update:
WPF application not WCF application. Sorry for my typo.
To transfer large files using WCF service over HTTP, you can use the following types of bindings:
wsHttpBinding
basicHttpBinding
In wsHttpBinding, we can set the TransferMode attribute as Buffered, but there is a disadvantage in using this approach for large files, because it needs to put the entire file in memory before uploading/downloading, A large buffer is required on both the web client and the WCF service host. However, this approach is very useful for transferring small files, securely.
In basicHTTPBinding we can use the TransferMode attribute as Streamed so that the file can be transferred in the form of chunks.
For more information follow this article:
WCF Streaming: Upload/Download Files Over HTTP
and for transfering files over TCP/IP read below articls:
WCF TCP-based File Server
Sending Files using TCP
Large Message Transfer with WCF-Adapters Part 1
I'm trying to use WCF web service in C# to send the bitmap data of an image to the client, I plan to send this as an object. I want to understand the nature of web service.
My question is how does this work with a large file? such as 10MB? Does web service work in one single request/response to send all 10MB worth of bitmap data? What if a network error occurs? will the client have to reissue the request?
The reason I ask this is I have been working with Socket and often when it comes to large file, I break it down to trunk of manageable size (such as 4kb) and then send it, if one succeed then I'm sending the next 4kb until all the data are transferred.
Thanks again.
The same principle can be applied here. You can send it in chunks. Related post you might find usefull - wcf upload/download large files (i.e. Img, mp3) in chunks with windows service
How can I send the service a ref of a big file on the cliet's computer by a stream object and then start download piece by piece it from the client's computer (I decide how much MB I transfer every sec)? Do I have any limitations when I use it?
IIS doesn't support streaming - it buffers the whole request.
CodeProject article: WCF 4.5 fixes this
Until then, if you use IIS, the whole file will be stored in server memory before it is passed to your service.
The solution for now is to send the file in chunks - each chunk sent in a separate service call.
This would also help with your bandwidth throttling. This is not built into WCF - you have to do it yourself. You can throttle each chunk either on the client or on the server.
Can REST web service (which usually produces e.g. simple JSONs) both handle and return big binary input/output data?
I mean, to call a REST service by a HTTP POST providing big file and afterwards reading the big result back? Is REST ok for that? ("Big" = few megabytes)
With text serializers such as JSON and XML you would get about 33% increase of the size of the files over the wire as the binary data needs to be Base64 encoded. There are more optimized protocols such as MTOM to handle this scenario. WCF supports MTOM out of the box.
REST architectures are quite capable of using HTTP to serve up application/octet-stream, which is just a stream of bytes. HTTP can quite reliably serve very large files.
Since REST is primarily a service over HTTP, standard advantages and limitations of HTTP apply to REST services too. You can send large files of few MBs as POST to REST API in a way similar that one uploads a large file to a web app.
I am working on a web service interface, where my WCF application works both as a Client and a Service. There are multiple Java clients that need to connect to my web service. I will need to accept stream of images and documents and send back stream of converted images.
I would also need to connect to other Java services to send the image streams as a payload to be stored in a database. I am new to web services, is there good documentation on how to enable streaming contracts between WCF and Java clients and vice verse.
If I want to return other information along with the stream of (group) images to the client, how would I do that? Like the size of each image, the offset in the stream, so they can separate images.
Thanks
In order to return additional information with your images you will need to define a DataContract which contains the metadata elements as well as a collection to contain your images. Perhaps representing your image collection as a byte array rather than just returning a raw stream of images? There are several ways to address the issue, however the best solution depends on your design requirements.