Apple

Begin forwarded message:

Jean,
Le Aug 27, 2012 à 12:16 PM, Jean Suisse a écrit :
So, I should use the sf_connect_out function. However, on this document :
"http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/kpi_socketfilter.h?txt" [the address is OK]
it is written, about sf_connect_out :
@result Return: 0 - The caller will continue with normal processing of the connection. Anything Else - The caller will rejecting the outbound connection.
Thus, I may not be able to hold the connection.
You have found a bug in the documentation. In fact when a socket filter sf_connect_out function returns EJUSTRETURN, the error code is converted to 0 (zero) before connect(2) returns to the caller.

Yes, if you hold a connection too long, many program will give up and close the socket and your sf_detach will be called.

In this situation, what happens to any swallowed mbuf I could have for the-said connection ? Obviously, I should not re-inject them. So how can I free them properly ?

Yes, you should free the mbufs you have stashed away.

Delaying an outgoing connection based on user input is really tricky. Delaying the data exchange may have less side effects but some apps will give up the connection as well if not data is being sent or received.

Well, process wishing to establish a connection are supposed to be in a waiting list on the side of the app. The user can then select the one or the ones he/she wishes to proceed. So, I can still remove them off the waiting list when sf_detach is called.

I could also intercept outgoing data in the sf_data_out_func and swallow them. The issue is that it may represent a lot of data to hold on to. And mbufs are limited…
It is reasonable to assume that the data sent by a process will be limited. If I hold the mbufs, they aren't going out and the process is likely to be waiting for its answer. Hence the finite number of mbufs to hold on to in this situation.
However, there are many many process that could potentially want to send data…

Using sf_data_out_func seems to be the only available option to put connection attempts on hold (so that the process can resume when the user decides so. If this decision happens in within a reasonable timeframe). However, for this solution, I need to swallow mbufs, which means that I will have to decide of a limit of emitted mbufs from the process beyond which I will have to close the connection without waiting for the user to take action. In this situation, how do I close the socket and release the mbufs properly ?
You cannot close the socket from the kernel but you can disconnect the socket by using the sock_shutdown() KPI function.

Vincent