Re: How to Implement Streamed HTTP Request
Re: How to Implement Streamed HTTP Request
- Subject: Re: How to Implement Streamed HTTP Request
- From: Mike Cohen <email@hidden>
- Date: Thu, 27 Apr 2006 17:06:28 -0400
I'm working on something similar now. I was previously doing all of
the communication using BSD sockets, but I need to be able to support
proxy configuration using a PAC file. I'm able to create and send the
response specifying keep-alive, but the server is rejecting it as a
non-keep-alive connection.
I'm doing something like this:
myRequest = CFHTTPMessageCreateRequest(kCFAllocatorDefault,CFSTR
("PUT"), myUrl, kCFHTTPVersion1_1);
myReadStream = CFReadStreamCreateForHTTPRequest(kCFAllocatorDefault,
myRequest);
CFHTTPMessageSetHeaderFieldValue( myRequest, CFSTR("Connection"),
CFSTR("keep-alive") );
CFReadStreamSetProperty(myReadStream,
kCFStreamPropertyHTTPAttemptPersistentConnection, kCFBooleanTrue);
CFHTTPMessageSetHeaderFieldValue( myRequest, CFSTR("Pragma"), CFSTR
("no-cache") );
CFStringRef tmp = CFStringCreateWithFormat
(kCFAllocatorDefault,NULL,CFSTR("%d"), count);
CFHTTPMessageSetHeaderFieldValue( myRequest, CFSTR("Content-
Length"), tmp);
CFRelease(tmp);
CFStreamClientContext clientContext = {0, this, NULL, NULL, NULL};
CFReadStreamSetClient(myReadStream,kCFStreamEventHasBytesAvailable|
kCFStreamEventEndEncountered,streamCallback,&clientContext);
CFReadStreamScheduleWithRunLoop(myReadStream, CFRunLoopGetCurrent(),
kCFRunLoopCommonModes);
CFDictionaryRef proxyDict = SCDynamicStoreCopyProxies(NULL);
CFReadStreamSetProperty(myReadStream, kCFStreamPropertyHTTPProxy,
proxyDict);
CFShow(proxyDict);
CFRelease(proxyDict);
CFHTTPMessageSetBody(myRequest, bodyData);
success = CFReadStreamOpen(myReadStream);
1. why is the connection not persistent?
2. Instead of using CFReadStreamOpen, can I open the socket myself
and send the serialized request so I have control over when the
socket gets closed?
3. Is there a way I can use the system proxy configuration INCLUDING
AUTOMATIC CONFIGURATION WITH A PAC FILE without using CFReadStream,
but just using either CFSocket or a raw socket (I already implemented
this using manually entered proxy host & port)?
On Apr 27, 2006, at 2:39 PM, Justin C. Walker wrote:
On Apr 27, 2006, at 05:45 , Daniel Jalkut wrote:
Hi Tommy - sorry for the delay in replying - I was out of town for
a few days.
I think you're getting confused by the use of the word "pair" in
different contexts. I'm also confused by this, so hopefully
somebody will correct us if what I'm about to tell you is wrong.
When you create a single socket, you're creating just one half of
a communication pair (say, the client half). From that single
socket, you can create a "pair" of streams: one for reading and
one for writing. The fact that there is a pair of streams doesn't
change the fact the socket itself is unconnected to anything else.
Using socketpair, you create a pair of sockets suitable for
communicating between say, a client and a server. The two sockets
represent two ends of a communications channel. Picture a long
pipe with your application code on one end, and CFNetwork on the
other end. You've created a socket pair so you can stick one
socket on your end and one on CFNetwork's end
I've lost the beginning of this thread, so I may not understand
what you are doing, but the above does not seem correct to me.
A single 'socket' gets you one endpoint of a 2-way ("full duplex")
stream. When it is connected, there are two endpoints
communicating in both directions[*]. Exactly what flows depends on
the agents at each end, of course.
The 'socketpair' call gets you a pair of sockets. Each socket acts
like the above. The point of this call is to be able to have a
process set up an environment for communication, via whatever
mechanism underlies the socket (e.g., "local", "INET",
"INET6", ...) as if the two sockets were STDIN and STDOUT,
respectively[**]. It's a "socket" analog of the "pipe" system
call, and intended for use in the same way as "pipe()" [in fact,
it's often the actual implementation of the "pipe()" call].
The issue of client and server is totally orthogonal to sockets and
how they are used. Using, e.g., TCP, two 'agents' can blast data
at each other over a single connection, and the only thing that
will hold the data back is the normal stuff involving available
buffer space, cpu cycles, and network bandwidth. Using a pair of
sockets won't have a noticeable impact (of course, that 'absolute'
statement should be interpreted loosely).
If I'm missing the point, never mind :-}
Regards,
Justin
[*] One can imagine a socket interface to a protocol that only
implements half-duplex communication, but that is an exception, and
pretty hard to find in the wild.
[**] There are other uses, but mirroring "pipe()" is (or was) the
main impetus.
--
Justin C. Walker, Curmudgeon-At-Large
Institute for the Enhancement of the Director's Income
--------
Experience is what you get
when you don't get what you want.
--------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40mcdevzone.com
This email sent to 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