I'm trying to figure out if it's possible to slow down the server when it's sending multipart/xmixed-replace responses. I want my client to try to rate limit a motion jpeg stream. I've found a lot of documentation about what the server sends in an HTTP response but nothing about what the client sends.
What does the client send, if anything, after each part in a multipart/x-mixed-replace response? If it doesn't send anything, does the server just keep piling on the parts?
I'll start by admitting I don't know the answer to your question. Now then, I would expect that the client sends nothing between parts. The reasoning is that the server doesn't need to know anything else from the client. If the client was sending data, it'd be more like a pipelined request than a multipart response. Consider for example a multipart email message.
On the server side, my interpretation is that the server sends the parts as they become available. Since I read your blog I have a mild idea of what you're trying to do, so I'll keep making things up.
I think the design you're going for is two separate functions, one to read the jpegs from the stream into a private in-transit buffer, and a public 'completed image' buffer, in which it keeps the most recent complete image. The second component reads only from the 'complete image' buffer when it finishes processing the last complete buffer it handled. Essentially, a ring buffer of size=1, with some safety/atomicity in moving the incomplete buffer -> completed buffer.
Somehow I feel none of that helped.
At the HTTP level I dont think the client sends anything. The server assumes that as long as the connection is open it can keep sending the response.
I dont think there is an easy HTTP-level solution to the problem because there is no "ack" concept in the client-server exchange.
There are obviously TCP-/IP level solutions to this problem.
I am wondering if the client can do something differently when it actually receives the server's response headers and recognizes that the response is multipart - whether it can then abort the connect and open a new non-keep alive one and just get the parts one by one...
Actually I think the multipart thing is a red herring because the concept of multipart is just to delineate content types within the same message body. So from a server perspective (in terms of the rate at which content is sent) it is not really different from sending a single big chunk of data.
So, I am wondering if you can the Range header to only request a specific range - one "part" at a time.
Start counting bytes from the end of the response headers. When you reach the end of the first part, note the number of bytes read and close the connection. Send a request for the same document but specify the starting Range as the bytes at the end of chunk. Again, read the response, when you reach the end of the part, add the current response bytes to the previous, close the connection and repeat ad nauseam...
Haven't tried it, but sounds like it would work provided the server supported range headers and provided you were able to do some patching on the client side.
Might be easier to write a client-side proxy that rate limits by dropping packets ...