Re: Write stream proxy
Re: Write stream proxy
- Subject: Re: Write stream proxy
- From: Jack Brindle <email@hidden>
- Date: Thu, 11 Sep 2008 13:45:27 -0700
- Thread-topic: Write stream proxy
Awfully interesting, and makes me wonder why the approach was taken in the
first place. To do a quick reset, we have two servers we work with. The
first controls all actions. The second only handles file transfers. We do
all file I/O through NSFile functions (actually NSFileHandle if it matters).
The question I now have is why do we need a socket pair at all? For that
matter, what is the purpose of a socket pair?
We can transfer up to 2 GB of file data to the file server, which tends to
preclude in-memory functions. This is why the writeStream approach was taken
in the first place.
So, a fundamental question - the docs tell me that I need to use a write
stream to send the data (2KB at a time) to the server. Is this true, or
should I be looking at readstreams for the file transfer? It seems strange
to use a read stream to write data...
> The only reason you need to do the whole socket pair thing is if the
> data that you want to upload isn't present in one single file (or one
> single block of memory). In that case, you have a number of options:
We currently build the headers elsewhere and just write them out, then send
the file, then some completion info.
> If you do this you won't need to mess with proxies on the streams you
> create for the socket pair. Those streams are just used for internal
> communication within your program. The only stream that needs to
> deal with proxies is the main CFHTTP stream.
I think this assumes we are using one of the sockets/streams to get data
from the file. We don't. The original code uses one for talking to the
control server, and the other to send the file to the transfer server.
Mark's suggestions were also very interesting. I have just a few comments.
Our application must run on Tiger, so the CFStreamCreateBoundPair call
Is probably out. But this gets us back to the question as to whether we
really need a socket pair and what is its purpose. I'm still chewing on the
rest of his suggestions, they make a lot of sense, and are pretty close to
what we are doing now. It does get me back to the question as to why the
pipe breaks when we receive the proxy challenge on the write stream.
What I would really like is a http call set that takes care of the proxy for
us, any chance? Networking code used to be rather easy, just open a socket,
bind it, then start sending data. Looks like I've been away from it too
long.
On 9/10/08 5:18 AM, "Quinn" <email@hidden> wrote:
> At 10:26 -0700 9/9/08, Jack Brindle wrote:
>> For file transfers we do the same thing except create the dual
>> socket setup and call CFReadStreamCreateForStreamedHTTPRequest on
>> the read stream. However the read stream looks to be handled as a
>> raw stream of bits, without http-specific handling. It uses
>> CFWriteStreamWrite to send the data. No calls are made to anything
>> with the characters HTTP in the name for this stream. Am I right in
>> the feeling that this really isn't what I need to have?
>
> It depends (-: When you create a streamed CFHTTP request (by calling
> CFReadStreamCreateForStreamedHTTPRequest) CFHTTP will call the
> supplied read stream to get the bytes for the body of the request.
> This isn't HTTP at all, it's just a raw stream of bytes. A typical
> usage is, if you want to upload a file, you create a file read stream
> (CFReadStreamCreateWithFile) and pass that to
> CFReadStreamCreateForStreamedHTTPRequest.
>
> The only reason you need to do the whole socket pair thing is if the
> data that you want to upload isn't present in one single file (or one
> single block of memory). In that case, you have a number of options:
>
> A. If the data is relatively small, you can flatten it to a temporary
> file and then create a file read stream and use that. Similarly, you
> can flatten it to a temporary block of memory.
>
> OTOH, if the data is large, this approach is too inefficient.
>
> B. If you're OK with using Objective-C and the data is all present
> (that is, you don't need to be scheduled on a runloop in order to
> produce the data), you can create the data from a custom subclass of
> NSInputStream. Subclassing NSInputStream for asynchronous streams
> isn't something we support, but it should be OK for synchronous
> streams.
>
> I haven't actually tried this though (-:
>
> C. If all else fails, you can produce the data using the technique
> that you're already using, that is, create a socket pair, create a
> read stream for one member of the pair and a write stream for the
> other, and feed the data to the CFHTTP request by writing it to the
> write stream.
>
> If you do this you won't need to mess with proxies on the streams you
> create for the socket pair. Those streams are just used for internal
> communication within your program. The only stream that needs to
> deal with proxies is the main CFHTTP stream.
>
> S+E
_______________________________________________
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