I have a WCF Service and I want to send a message with the least characters possible.
Are there any compression methods to do this?
I want to compress it in C# and decompress it using javascript.
MTOM.
Or you could implement a custom message encoder and decoder, where you pass the data through a (de)compression engine. This implies you have control over both ends (client and service).
Unfortunately I don't know the answer to your updated question. You'd have to find some libraries that implement the same compression algorithm in both C# and Javascript. I've never done anything like that so I wouldn't know which libraries to use. You could try to manually implement something like LZW or DEFLATE, but that'll be the hard way and error-prone.
For that, you might implement one of the compression techniques explained here.
Related
Should data manipulation once data is returned either with TCP or HTTP be received as byte arrays or is it an O.K. practice to receive it as a string? I've been trying to find some professional projects on github to get my answer, but have had no luck. Some examples of HTTPClient from Microsoft on MSDN usually make use of the GetByteArrayAsync(website) method, instead of GetStringAsync(website). Is there any reason why they would use GetByteArrayAsync instead of GetStringAsync, which would make data manipulation much easier right off the bat? Are there any advantages to using GetByteArrayAsync first instead?
What moves "through the wire" are bytes, not strings.
They might be text, but can be pictures, or a zip file.
At TCP/HTTP level this is unknown, and it does not matter.
That decision belongs with a higher level.
HTTP has a bit more info than TCP, so you might have a mimetype to help you decide what those bytes are.
Even if you know it is some kind of text, you will need to know the character set. You might get that info in the HTTP header, or in the document itself, or there might be a standard saying what the encoding is.
Only then you will be able to convert to a string.
Background:
I have a PHP server hosting a RESTful API that returns an image when a function /api/GenerateImage is called. I need the fastest and lowest memory using method to achieve this.
Ideas:
I can think of a few ways of achieving this:
Write it entirely in PHP - Image requires a lot of byte manipulation and it feels bad to do this in PHP.
Write a continually running C# program and use an API to generate the image and copy the response stream to the client via PHP - Need to avoid overhead of unnecessary socket connections.
Write a C/C++ command line program that, when called, generates and stores the image in a file, which PHP reads and sends - Need to avoid overhead due to starting a program, writing to a file and then reading to it.
Write it in C/C++ and use a PHP library wrapper to call the function directly from PHP - Seems to be the fastest, but most difficult for a single function.
The two most obvious solutions to me seem absent from your set of options:
Use PHP's GD extension.
Use imagemagick.
Whether these are practical options depends on what exactly you have to do with the image. If they are just static images you don't need anything, just serve them up as files from your web server. The fact you need some code to generate the image implies that the image is dynamically generated.
If neither of these suit, then I would say: your last (4th) solution would be the fastest, but a modified version of your 3rd solution would be simplest: write a command-line program that returns the image data to stdout, and call that from PHP.
I've got some strings that I need to compress server-side in C#, then decompress client-side in JavaScript. What can I use to accomplish this?
Assuming you're fetching this data over HTTP, is there any reason you can't do this at the HTTP level? (See this article for information about HTTP compression.)
That way you shouldn't need to do anything on the client side, apart from making sure that the request includes the appropriate Accept-Encoding header. Depending on your server, you may be able to just tweak some server settings to get the compression automatically on that side too...
To be honest, it's worth breaking out WireShark to check exactly what's going up and down the wire already. It's just possible you've already got compression without knowing it :)
I am wondering if there is a straightforward way to use .NET's built in HTTP support to parse arbitrary bytes into nice HTTP requests and responses. For example, I would like to be able to pass in a byte array containing "HTTP/200 OK\r\nContent-Type:...." etc and get out some structure representing the status code, and decoded content.
I'm afraid there is not built-in support for this that you can access. This logic is embedded in internals of the HttpWebRequest-related classes of the .NET Framework.
I think the closest you can get is hosting your own web server through the System.Web.Hosting APIs, but this sounds too heavyweight for what you are describing.
I'm building an network application that needs to be able to switch from normal network traffic to a zlib compressed stream, mid stream. My thoughts on the matter involve boolean switch that when on will cause the network code to pass all the data through a class that I can feed IEnumerable<byte> into, and then pull out the decompressed stream, passing that on to the already existing protocol parsing code.
Things I've looked at:
ZLib.NET - It seems a little... Ecclectic, and not quite what I want. Would still make a decent start to build off though. (Jon Skeet's comments here hardly inspire me either.)
SharpZipLib - This doesn't seem to support zlib at all? Can anyone confirm or deny this?
I would very much prefer and all managed solution, but let's have at it... are there any other implementations of this library out there in .NET, that might be better suited to what I want to do, or should I take ZLib.NET and build off that as a start?
PS:
Jon's asked for more detail, so here it is.
I'm trying to implement MCCP 2. This involves a signal being sent in the network stream, and everything after this signal is a zlib compressed data stream. There's links to exactly what they mean by that in the above link. Anyway, to be clear, I'm on the recieving end of this (client, not server), and I have a bunch of data read out of the network stream already, and the toggle will be in the middle of this (in all likelyhood atleast), so any solution needs to be able to have some extra data fed into it, before it takes over the NetworkStream (or I manually feed in the rest of the data).
SharpZipLib does support ZLib. Look in the FAQ.
Additionally, have you checked whether the System.IO.Compression namespace supports what you need?
I wouldn't use an IEnumerable<byte> though - streams are designed to be chained together.
EDIT: Okay... it sounds like you need a stream which supports buffering, but with more control than BufferedStream provides. You'd need to "rewind" the stream if you saw the decompression toggle, and then create a GZipStream on top of it. Your buffer would need to be at least as big as your biggest call to Read() so that you could always have enough buffer to rewind.
Included in DotNetZip there is a ZlibStream, for compressing or decompressing zlib streams of data. You didn't ask, but there is also a GZipStream and a DeflateStream. As well as a ZlibCodec class, if that is your thing. (just inflates or deflates buffers, as opposed to streams).
DotNetZip is a fully-managed library with a liberal license. You don't need to use any of the .zip capability to get at the Zlib stuff. And the zlib stuff is packaged as a separate (smaller) DLL just for this purpose.
I can recommend you Gerry Shaw's zlib wrapper for .NET:
http://www.organicbit.com/zip/
As far as I know the ZLib (gzip) library doesn't support listing the files in the header. Assuming that matters to you, but it seems a big shortcoming. This was when I used the sharp zip library a while ago, so I'm willing to delete this :)
Old question, but System.IO.Compression.DeflateStream is actually the right answer if you need proper zlib support:
Starting with the .NET Framework 4.5, the DeflateStream class uses the
zlib library. As a result, it provides a better compression algorithm
and, in most cases, a smaller compressed file than it provides in
earlier versions of the .NET Framework.
Doesn't get better than that.