Persistent HTTP connections...
Persistent HTTP connections...
- Subject: Persistent HTTP connections...
- From: Michael Ledford <email@hidden>
- Date: Mon, 11 Feb 2008 13:46:55 -0500
- Delivered-to: email@hidden
- Delivered-to: email@hidden
Hello all,
I have some questions about persistent HTTP connections going through
CFNetwork that I haven't found answered here before.
1) My first question is the behavior that persistent HTTP connections
undergo with CFReadStreamCreateForHTTPRequest(). While looking into
using persistent connections I looked at the GET Example code to see
how it is achieved. To prove to myself that things were working as
advertised I used tcpdump to examine the exchange. I am seeing
something very interesting and it is puzzling me.
13:11:45.224259 IP local.56698 > remote.http: S 3480064110:3480064110
(0) win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp 812998842
0,sackOK,eol>
13:11:45.264207 IP remote.http > local.56698: S 2814808401:2814808401
(0) ack 3480064111 win 65535 <mss 1460,nop,wscale 0,nop,nop,timestamp
1108312541 812998842,sackOK,eol>
13:11:45.264330 IP local.56698 > remote.http: . ack 1 win 65535
<nop,nop,timestamp 812998842 1108312541>
13:11:45.267709 IP local.56698 > remote.http: P 1:113(112) ack 1 win
65535 <nop,nop,timestamp 812998842 1108312541>
13:11:45.324022 IP remote.http > local.56698: . ack 113 win 65535
<nop,nop,timestamp 1108312541 812998842>
13:11:45.325079 IP remote.http > local.56698: P 1:211(210) ack 113
win 65535 <nop,nop,timestamp 1108312541 812998842>
13:11:45.325125 IP local.56698 > remote.http: . ack 211 win 65535
<nop,nop,timestamp 812998843 1108312541>
13:11:50.319981 IP remote.http > local.56698: F 211:211(0) ack 113
win 65535 <nop,nop,timestamp 1108312551 812998843>
13:11:50.320099 IP local.56698 > remote.http: . ack 212 win 65535
<nop,nop,timestamp 812998853 1108312551>
13:17:47.302927 IP steel.56698 > o.iwanttops.com.http: P 113:225(112)
ack 212 win 65535 <nop,nop,timestamp 812999566 1108312551>
13:17:47.326342 IP steel.56698 > o.iwanttops.com.http: F 225:225(0)
ack 212 win 65535 <nop,nop,timestamp 812999566 1108312551>
13:17:47.330630 IP steel.56711 > o.iwanttops.com.http: S
729168448:729168448(0) win 65535 <mss 1460,nop,wscale
0,nop,nop,timestamp 812999567 0,sackOK,eol>
13:17:47.343759 IP o.iwanttops.com.http > steel.56698: R
2814808613:2814808613(0) win 0
13:17:47.372379 IP o.iwanttops.com.http > steel.56711: S
3392226912:3392226912(0) ack 729168449 win 65535 <mss 1460,nop,wscale
0,nop,nop,timestamp 1108313265 812999567,sackOK,eol>
13:17:47.372445 IP steel.56711 > o.iwanttops.com.http: . ack 1 win
65535 <nop,nop,timestamp 812999567 1108313265>
13:17:47.375236 IP steel.56711 > o.iwanttops.com.http: P 1:113(112)
ack 1 win 65535 <nop,nop,timestamp 812999567 1108313265>
13:17:47.419592 IP o.iwanttops.com.http > steel.56711: . ack 113 win
65535 <nop,nop,timestamp 1108313265 812999567>
13:17:47.421030 IP o.iwanttops.com.http > steel.56711: P 1:211(210)
ack 113 win 65535 <nop,nop,timestamp 1108313265 812999567>
13:17:47.421069 IP steel.56711 > o.iwanttops.com.http: . ack 211 win
65535 <nop,nop,timestamp 812999567 1108313265>
13:17:52.422614 IP o.iwanttops.com.http > steel.56711: F 211:211(0)
ack 113 win 65535 <nop,nop,timestamp 1108313275 812999567>
13:17:52.422701 IP steel.56711 > o.iwanttops.com.http: . ack 212 win
65535 <nop,nop,timestamp 812999577 1108313275>
So what you see is the GET Example code issuing a persistent HTTP
request (13:11:45.224259). The server is waiting 5 seconds on the
idle connection and closing (13:11:50.319981). In the GET Example the
stream is not closed until after a new request is made
(13:17:47.302927). But notice that CFNetwork pushes data across the
wire to the closed connection before it sends its FIN, as in the code
a new stream is created first and opened. I have compared this
behavior to Safari and Firefox. Safari works as above except the
stream appears to be closed after a certain timeout period has
expired, the GET Example does not close until either the application
ends or another request is generated. Firefox works as I would
expect, having the client complete the closing handshake right after
the server has sent its FIN.
Would this be considered a bug on CFNetwork's part? I understand that
the stream that receives a FIN can still send data but I'm not
convinced it applies in the HTTP protocol. It was created with
CFReadStreamCreateForHTTPRequest(). While it's only a few bytes
should it be tighter? Is there something that signals that the other
side of the connection has closed? Usually I would think this is the
kCFStreamEventEndEncountered, but it appears that this can either be
the closure of the connection or end of a successful persistent HTTP
message.
2) The second question is somewhat related to the first question. As
per the GET Example and documentation persistent connections are held
as long as the stream that abstracts it is still open. If there are
multiple persistent streams open, how do you know which persistent
stream the new stream is enqueued on and therefore which stream
should be closed?
Sincerely,
Michael
_______________________________________________
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