Re: Unexpected (?) behavior in socket filter (sf_connect_out)
Re: Unexpected (?) behavior in socket filter (sf_connect_out)
- Subject: Re: Unexpected (?) behavior in socket filter (sf_connect_out)
- From: Jean Suisse <email@hidden>
- Date: Fri, 28 Sep 2012 09:20:47 +0200
The behavior is expected.
When you return EJUSTRETURN from the first call to connect_out, this happens in the application context. The application then thinks the connection has been established successfully because the connect(2) system call returns 0 to the application.
The second call to connect_out happens in a kernel thread that has called sock_connect(). This time around the application does not get the ENETDOWN because from it viewpoint, the connection is established and it hasn't actually issued this 2nd connect.
So there is no way to tell the application the connection has actually failed.
Thank you for shedding light (again) on this point.
After focusing for so long on *holding* a connection request, I lost track of the fact it was actually a ruse: from the app's perspective, the connection is always successful and the delay happens elsewhere. It may already have started to send data for all I know.
Before asking the question, I tried several approaches, such as returning various error codes (that was a waste), or triggering a call call to sock_shutdown() from a timer routine a few µsec after denying the connection. I spent considerable time setting up all the infrastructure to handle this particular point and it didn't work either since the socket never connected in the first place….
I should have asked first.
Thank you for your reply.
Jean
|
_______________________________________________
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