• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Persistent HTTP connections...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Persistent HTTP connections...


  • Subject: Persistent HTTP connections...
  • From: Michael Ledford <email@hidden>
  • Date: Mon, 11 Feb 2008 13:46:55 -0500

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


  • Prev by Date: Re: DHCP Renew
  • Next by Date: Re: Porting Winsock DHCP Server; is OS/X ignoring Broadcast UDP in recvall()?
  • Previous by thread: Message-ID: <email@hidden>
  • Next by thread: 10.5 and NT4 nbsession problem
  • Index(es):
    • Date
    • Thread