OkHttp does a great job of transparently handling GZIP content encoding. When I call response.body().contentLength() I get the decoded size of the response.
How can I get the number of bytes actually transferred in the HTTP response?
Alternately, getting the value from the original Content-Length header would do.
I am trying to keep track of how many bytes I have downloaded over a metered connection.
Look at EventListener, which tracks bytes transmitted over the network.
https://square.github.io/okhttp/events/
Related
I'm searching for weeks now to find a solution how to use chunked transfer encoding in a Java client without coding my own myHttpURLConnection.
The HttpUrlConnection of Java expects a fixed chunk size, which is not usable for me. The data consists of several messages that are different in size and must be sent in neartime to the server. The system currently (in Prelive/UAT state) works based on having fixed 1024 byte chunks but since most messages are significantly shorter, this is a waste of band width not acceptable in PROD.
Furthermore, messages larger than 1024 bytes would be chopped apart so a) the server would need to assemble them again and b) the last part of the message would not be send until enough data is available for filling 1024 bytes (even worse, not neartime anymore).
Does anybody have an idea how to workaround the restriction of the HttpUrlConnection of Java (non compliant with RFC2616 as it does not fully implement it) without having to code everything on top of URLConnection?
I did not find any possibility to hook into the needed funcs for just setting a new chunk size for each heap of data.
My current option: douplicate all HTTPUrlConnection code and modify the parts dealing with CHUNKED (e.g. having some flush() function to adjust the chunk size and send what's there).
I have connected to a REST server using the Java object RestTemplate. The REST responds with the big data, but my program can not receive JSON with length over 10000 chars. Please suggest how to increase the length of JSON received data.
The problem is likely that you are sending the data in a GET request, so it's sent in the URL. Different browsers have different limits for the URL, where IE has the lowest limist of about 2 kB. To be safe, you should never send more data than about a kilobyte in a GET request.
To send that much data, you have to send it in a POST request instead. The browser has no hard limit on the size of a post, but the server has a limit on how large a request can be. IIS for example has a default limit of 4 MB, but it's possible to adjust the limit if you would ever need to send more data than that.
How to download first 125 bytes and 125 last byte file via HTTP protocol ?
I believe you want to send an appropriate Range header. See the HTTP/1.1 spec for more information. Be aware that not all servers will support this, mind you. You may need to transfer the whole file, just to get to the last 125 bytes. Of course, you can get just the first 125 bytes by requesing the whole thing, and then only reading the first 125 bytes before killing the connection.
In theory I believe you should be able to use:
Range: 0-124,-125
Note that this will give interesting results if the full response would be less than 250 bytes...
Accept-Ranges: bytes
Range: bytes=-255
send content-range in request headers for specific range of content as response. but for which the webserver has to support range requests
Hope everyone of you doing great.I really need your help.My scenario is given below.
1-I am getting a continuous data (byte array[]) from my camera .
2-Now sending those byte[] through UDP but i have to halve that array because i can't send that big array. (P.S i can't use JMF as its not supported at my device(server side) so have to send byte[] manually through UDP)
3-I am receiving those byte [] chunks at client side.
Now i have following requirement.
-I want a player at the client side which plays my these byte [] chunks but in continuous way.(At client side i can use JMF)
Now i don't know how should i combine all these byte[] chunks at client side so that my video gets play continuously.
Please help as you guys always do.
Best regards
ZB
As an option, you may consider vlcj for video streaming.
Examples how to stream media from camera with VLC player, which may be also of some interest.
If you are transmitting over UDP I assume you are aware of the standard caveats regarding ordering and dropped packets.
I would send the data in the following fashion.
Define a datagram format which has a header and payload with the header being something quite simple like
<packetnumber><timestamp><payloadlength>
<payload>
So you'd create you chunk which is an array of bytes, calculate the payload length, current packet number and timestamp before appending the chunk. Then transmit the whole array and when it's received you can remove the packet number, timestamp and use the payload length to retrieve the data.
Then load the payload into buffer. I'd be tempted to create an object which has the packet number as a key and an array of bytes, then have a doubly linked list of these objects as the buffer. You use the packet number to see where to insert into list and to play back you just keep getting the object with the lowest packet number.
You'll need to define some control data for packet number reseting etc and flow control.
I may have made this more complex by ignoring common libraries but this is the logic I'd follow.
I am writting a .Net/C# client to a Java Server on Solaris.
The Java server is writting Raw byte data in a Gziped format which I need to extract, but I am having trouble to read the data in the right buffer sizes. I read the message not-deterministicly incomplete or complete and can not read the second message in any case.
I am reading the bytes using the NetworkStream class with the DataAvailable property.
My guess is that it could be related to a little/big endian problem.
Do I need to use a special conversion to change the data from big into little Endian? Do I need to read the necessary bytes using the gzip header?
I used to use the same server with an uncompressed protocol before and had no problem using a StreamReader with the ReadLine function before, but that protocol was purely text based.
Edit: Unfortunately I have no choice as the remote server and protocol is given. Is the endiness part of the GZip format or do I only need to convert the header accordingly? The uncompressed data are pure UTF8-encoded strings with line breaks as delimiters.
The GZIP format is not complex. It is available in all its glory in a simple, accessible specification document, IETF RFC 1952.
The GZIP format specifies the bit-order for bytes. It is not tunable with a flag for endianness. The producer of a GZIP stream is responsible for conforming to the spec in that regard, and a consumer of a GZIP stream, likewise.
If I were debugging this, I would look at the bytes on either end of the wire and verify that the bytes going in are the same as the bytes coming out. That's enough to put aside the endian issues.
If you don't have success transmitting a GZIP bytestream, try transmitting test data - 16 bytes of 0xFF, followed by 16 bytes of 0xAA, etc etc. And then, verify that this is the data coming out the other end.
I'm sorry, I don't know what you mean by I read the message not-deterministicly incomplete or complete and can not read the second message in any case. Second message? What second message? The endianness shouldn't affect the amount of data you receive.
It feels to me that you don't have confidence that you are successfully transmitting data. I would suggest that you verify that before working on endian issues and GZIP format issues.