Re: kCFStreamPropertyHTTPAttemptPersistentConnection
Re: kCFStreamPropertyHTTPAttemptPersistentConnection
- Subject: Re: kCFStreamPropertyHTTPAttemptPersistentConnection
- From: "Tommy Tian" <email@hidden>
- Date: Wed, 29 Mar 2006 18:56:11 -0800
I test "GET Example" in /Developer/Examples/Networking/ on the Tiger,
and use tcpdump to check it, yes, that is a persistent conntion.
I also test "POST Example" in /Developer/Examples/Networking/ on the
Tiger.of coure I also change code to use this new model, but it still
NOT a persistent connection.
Any idea?
thanks
tommy
On 3/28/06, Quinn <email@hidden> wrote:
> At 18:26 -0800 27/3/06, Tommy Tian wrote:
> >I've verified that isPersistent is true, but CFNetwork is still closing the
> >TCP stream after each transaction.
>
> This has been covered on the mailing list already. I've included a
> copy of the relevant posts below.
>
> S+E
> --
> Quinn "The Eskimo!" <http://www.apple.com/developer/>
> Apple Developer Technical Support * Networking, Communications, Hardware
>
> At 10:47 -0500 15/6/04, Marc Epard wrote:
> >Date: Tue, 15 Jun 2004 10:47:20 -0500
> >From: Marc Epard <xxx@yyy>
> >Subject: kCFStreamPropertyHTTPAttemptPersistentConnection
> >To: macnetworkprog <email@hidden>
> >
> >I'm using CFNetwork for HTTP and I'd like to have persistent connections
> >because I'm doing several transactions in a row. Before calling
> >CFReadStreamOpen, I do this:
> >
> >bool isPersistent = CFReadStreamSetProperty(responseStream,
> > kCFStreamPropertyHTTPAttemptPersistentConnection,
> > kCFBooleanTrue);
> >
> >I've verified that isPersistent is true, but CFNetwork is still closing the
> >TCP stream after each transaction.
> >
> >I'm making sure to read the entire response. I've tried keeping a reference
> >to a stream around and not releasing it each time and I've tried not calling
> >CFReadStreamClose. Still, CFNetwork closes the stream.
> >
> >I've used tcpdump and tcpflow to verify that both ends are including the
> >Connection: Keep-Alive header and determined that it is the CFNetwork end
> >that initiates the TCP close rather than the server. This is on 10.3.4.
> >
> >Any suggestions?
> >
> >Thanks.
> >
> >-Marc
>
> At 9:44 -0500 19/8/04, Marc Epard wrote:
> >Date: Thu, 19 Aug 2004 09:44:46 -0500
> >From: Marc Epard <xxx@yyy>
> >Subject: Re: kCFStreamPropertyHTTPAttemptPersistentConnection
> >To: macnetworkprog <email@hidden>
> >
> >In case someone searches for this in the future:
> >
> >I talked to some Apple engineers at WWDC and found out the trick to get
> >persistent HTTP connections to work in Panther:
> >
> >You must call CFReadStreamOpen to issue a subsequent request before calling
> >CFReadStreamRead to read *any* of the response for the previous request.
> >
> >Issuing the next request before calling CFReadStreamClose on the previous
> >response is not sufficient.
> >
> >[...]
> >
> >-Marc
>
> At 10:05 -0700 19/8/04, Jeremy Wyld wrote:
> >Date: Thu, 19 Aug 2004 10:05:10 -0700
> >From: Jeremy Wyld <xxx@yyy>
> >Subject: Re: kCFStreamPropertyHTTPAttemptPersistentConnection
> >To: macnetworkprog Programming <email@hidden>
> >
> >Let me fill in the details.
> >
> >CFNetwork on Panther is very aggressive about reaping the HTTP
> >sockets. If another request is queued before all the bytes are
> >received on the previous request, the persistent connection will be
> >maintained. The problem is that the act of reading could be the
> >call to close down your persistent connection. This is why the
> >described method will work. The open will cause the queueing, and
> >the persistent connection is still open until the read.
> >
> >CFNetwork on Tiger has been changed to be less aggressive. An
> >underlying, persistent connection is open as long as the last stream
> >on that connection. Calling open before the previous request's
> >close will get the new request enqueued on the persistent
> >connection. "GET Example" in /Developer/Examples/Networking/ has
> >been changed on the Tiger CD to use this model.
> >
> >jeremy
> _______________________________________________
> 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
>
_______________________________________________
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