Re: NSMutableURLRequest: Keeping the connection open
Re: NSMutableURLRequest: Keeping the connection open
- Subject: Re: NSMutableURLRequest: Keeping the connection open
- From: Mark Pauley <email@hidden>
- Date: Tue, 5 Apr 2011 11:31:40 -0700
Could you give me a dump of the unencrypted traffic? CFLogging the header dict, the status and the body should be enough for my purposes. It could be that we're legitimately closing the connection because of either a framing violation or a Connection: close.
_Mark
On Apr 5, 2011, at 6:07 AM, Thomas Engelmeier wrote:
>
> On 04.04.2011, at 20:20, Mark Pauley wrote:
>
>> It would appear that the remote server (or some hardware between you and the server) is shutting the connection down on you. Not really too much CFNetwork can do in that case. Do you have logs for the server? It would be interesting to know what exactly is happening from the server's point of view. RST can be a pain, they can come from anywhere :(
>
> Actually I spent another block of time implementing
> - communication on top of ASIHTTP
> - tracing also with wireshark
> - extending diagnostics
>
> The extended code looks like
>
> success = CFReadStreamOpen(readStream);
> success = CFReadStreamSetProperty( readStream, kCFStreamPropertyShouldCloseNativeSocket, kCFBooleanFalse );
>
> CFTypeRef sockets = CFReadStreamCopyProperty( readStream, kCFStreamPropertySocketNativeHandle );
>
> if ( oldStream) {
> CFStreamStatus status = CFReadStreamGetStatus( readStream );
> NSLog( @"overlapping create (Status:%i Socket:%@)", status, sockets );
> // CFReadStreamClose(oldStream);
> CFReadStreamSetClient(oldStream, kCFStreamEventNone, NULL, NULL);
>
> and logs somewhat expected values (always identical socket, socket status open):
>
> 2011-04-05 14:48:31.817 CoreSocialEntryTest[3902:207] overlapping create (Status:2 Socket:<07000000>)
> 2011-04-05 14:48:31.852 CoreSocialEntryTest[3902:207] overlapping create (Status:2 Socket:<07000000>)
> 2011-04-05 14:48:32.050 CoreSocialEntryTest[3902:207] Debug[SLBayeuxConnection.m]: -> Data:
>
> However, I see that each time the SSL is negotiated, the client sends his data, receives a response.
> Then follows an encrypted alert packet from the client, an [FIN, ACK] packet from the client and a [SYN] packet with a new port from the client, starting over with a new socket.
>
> The RST in the former traces was a red herring caused when I have a breakpoint in the client.
>
_______________________________________________
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