Are they any classes or libraries to read a gzipped stream from a server? For example, Java has the GZIPInputStream and GZIPOutputStream classes to read from a gzipped stream. Does iPhone SDK have such libraries or are there any external libraries that we can use?
Is this a web server, and can you tell it that the content encoding is gzip? If so, apparently NSURLRequest accepts gzip encoding transparently. In other words, you can make a request which looks like it's going to get the uncompressed data, the server can deliver gzip compressed data, and when you read it you'll get it decompressed already. You just need to be able to tell the server what's going on, really.
Related
React/Next front-end + Node.js and MongoDB on the back?
How would video storage work?
You can use post requests to send files to your remote server. You backend code should read request data and then store the file onto the disk or any object storage like s3. Most backend web frameworks have many libraries to store files received in an HTTP request directly to s3
Most of the web development frameworks have the capability to guess the mimetype but here since you know it's video/mp4 you can just save it.
I must warn you if you are trying to upload huge files it might be a better idea to use chunked uploads. This gives you ability to pause and resume and is robust to network failures.
I wanted to know which kind of protocol apache beam uses to read and write to cloud storage. Is it HTTPS or Binary(Blob).I tried to google it but I did not find. I know gsutil command uses HTTPS protocol.
You are mixing 2 things: Transport layer and data encoding.
Does Google use HTTP transport? YES, for all the API. HTTPS or gRPC (HTTP/2) are commonly use.
Does Google use binary encoding to speed up the transfert? As said before, transport can be HTTPS or gRPC. HTTPS is commonly use for REST API, and transport JSON text format. Of course, you can exchange files in binary format (GZIP for example to compress and speed up the transfert). gRPC is a binary protocol. You don't exchange JSON, but binary representation of the data that you want to exchange. And thereby, the file transfert is also in binary mode.
Now, what use Beam? As often, the Google libraries use gRPC behind the scene, and thus, the encoding is binary. If you perform yourselves REST API call, with JSON, and HTTP will be use for that; but file content is, when it can (depends on your request accept content header), transferred in binary.
EDIT 1
For BEAM, I had a look to the source code. You have here, for example, the creation of GoogleCloudStorageImpl object.
If you have a look to this full class name: import com.google.cloud.hadoop.gcsio.GoogleCloudStorageImpl;. Ok, let's see the hadoop package!!
The Javadoc is clear: JSON API is used. to confirm that, I went to the source code, and YES, the JSON format is used for the API communication.
BUT, keep in mind that is the API communication, the metadata around the file content. The file content should be sent in binary format (plain text of b64 encoding should be strange).
Is there a way in Play to pass data compressed with Gzip over WebSocket channels? I read in https://www.playframework.com/documentation/2.3.1/GzipEncoding about GzipFilter. Is there a way to use it with WebSocket?
Besides my server also accepts HTTP requests but I don't want to apply GZIP to them. Is there a way to use Gzip ONLY WITH WebSocket, excluding HTTP?
AFAIK there is some compression extension for websocket connections. (https://datatracker.ietf.org/doc/html/draft-tyoshino-hybi-permessage-compression-00).
In some browsers this should be fixed by now and enabled by default (Chrome).
In others (Firefox, WebKit) it is not (yet): https://bugzilla.mozilla.org/show_bug.cgi?id=792831 and https://bugs.webkit.org/show_bug.cgi?id=98840
As long as client and server support this there shouldn't be any problem just to enable Gzip.
You can configure when Gzip is used (at least to some degree). For example if you have an JSON API and you also serve normal HTML, you can decide to Gzip only the JSON data:
new GzipFilter(shouldGzip = (request, response) =>
response.headers.get("Content-Type").exists(_.startsWith("application/json")))
I am developing an iPhone app which need connection to server to fetch huge data at regular interval.So need to know which way is better socket connection or using libXML
Thanks
libXML isn't a data transfer library, and sockets don't handle XML, so if you are trying to download and process large XML documents, I'd say you need both, not one or the other.
Also, I'd be extremely wary of transferring "huge" data sets directly to an iPhone. At the very least, I'd use compression and give the user some warnings before transferring data over a 3G link.
Whats you mean by Huge data.. whats would be the size.\n
Its better First you test with max data which is chance to come from server.
Allow me to be more specific...
If I want to send files, but am required to wrap them in SOAP, wouldn't I use http? I am seeing a surprisng lack of info on this online.
Sending files via SOAP doesn't have anything specifically to do with FTP. To send a file through a SOAP interface, you might base64 encode the file and stuff the whole thing into a SOAP string parameter. However, this might only be appropriate if your file size has a reasonable upper bound.
If your files can be an unbounded size, you might investigate using a different transport protocol to transfer the actual file data (eg. HTTP or even FTP), then use SOAP to transfer a pointer to the file (such as its URL). Some implementations of SOAP cannot handle arbitrary large messages.
Pretty vague question but if you're using web services you can use MTOM http://en.wikipedia.org/wiki/MTOM (SOAP Message Transmission Optimization Mechanism)
I don't know your environment but there are examples of this using .NET / WCF if you Google it.
Two standard ways of sending files along with SOAP messages are:
SOAP with Attachments
MTOM
MTOM supports either using MIME attachments or base64 encoding the file into the body, where as SOAP with Attachments only supports MIME attachments.