Re: Write stream proxy
Re: Write stream proxy
- Subject: Re: Write stream proxy
- From: Jack Brindle <email@hidden>
- Date: Thu, 09 Oct 2008 16:09:26 -0700
- Thread-topic: Write stream proxy
Title: Re: Write stream proxy
Just a follow up to this thread. The code is now running for the most part, although there does seem to be hiccups from time to time. Most seem to happen when the proper authentication information is in the Network preferences proxy pane. Interestingly if the challenges persist to the point of having the user enter new proxy info the upload always goes smoothly. I’m still pulling some hair out over this one. I think it may be a race condition related to something Mark noted about having to send the entire message.
So as a clarification, does your comment mean that if we are sending a 1GB file, we have to send the entire file before retrying the authentication? This would explain a lot, and be rather painful in the case of 1GB or larger transfers (I believe the limit for HTTP POSTS is 2GB).
You are right about the dry-run, but the original authors didn’t really think of the proxy situation. It is an awfully good idea, though.
One other question. If the transfer is aborted mid-stream, does the write stream which was scheduled on a run loop need to be unscheduled? If not, how does that mechanism work?
Thanks for all the help!
Jack Brindle
YouSendIt, Inc.
On 9/22/08 12:07 AM, "Mark Pauley" <email@hidden> wrote:
Absolutely right Phillip, we do retain the readstream. We should update the docs to reflect as much.
Jack: you absolutely do need to re-create the streams because we may have read data from your writestream. Also note that once you pass the readstream to our API, you're free to release both the writestream and the readstream and forget about them. We keep references to them and retain them accordingly. You may need to utilize the retain / release callbacks as you set the client of your writestream to avoid leaks.
Unfortunately under HTTP we currently have to send the full payload just to get the 407, at which point we have to re-send the full payload with auth when you retry. This effectively cuts your transfer speed in half if your connection must be authenticated.
If you control the server, I suspect it would be much cheaper in some circumstances to do a dry-run message with no payload to your server that will pre-flight the auth / creds.
Make sense?
We can't do the above in a general case because the server could in theory be pernicious and only request auth for uploads or only for certain types of uploads.
On Sep 19, 2008, at 1:47 PM, Philip D. Wasson wrote:
On Sep 19, 2008, at 16:22, Jack Brindle wrote:
When creating a new stream from the same http message, do we need to
recreate the read and write streams that are combined into the
CFReadStreamCreateForStreamedHTTPRequest? In other words, when the output
stream from the CFReadStreamCreateForStreamedHTTPRequest is released during
the process, are the read and write streams I am using also released?
I suspect the answer is yes, and this one step is what is keeping my code
from working.
I now believe that when creating the new stream during the authentication
process I will need to also create the paired read and write streams, then
feed the new ones to the CFReadStreamCreateForStreamedHTTPRequest.
Even though the docs in Xcode (2.5) don't appear to explicitly say so, I believe my previous investigations revealed that CFReadStreamCreateForStreamedHTTPRequest retains the read stream you give it for the requestBody (which is why I showed releasing that stream immediately after calling CFReadStreamCreateForStreamedHTTPRequest. So once you close the reply read stream, or perhaps even sooner, it will release the request body read stream. It doesn't have a reference to the write stream, so you must release that yourself.
So yes, you should re-create the stream pair used to read the file and supply it to CFReadStreamCreateForStreamedHTTPRequest.
----------------------------------------
Philip D. Wasson
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_Mark
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden