• 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
Re: Blocking / Holding data from NKE
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blocking / Holding data from NKE


  • Subject: Re: Blocking / Holding data from NKE
  • From: Vincent Lubet <email@hidden>
  • Date: Mon, 27 Aug 2012 10:45:24 -0700


Le Aug 27, 2012 à 3:38 AM, Jean Suisse <email@hidden> a écrit :

I am writing a network analysis tool. To implement one of the requested features, I need to hold / block outgoing connections attempts from processes, pending user decision.

The idea is to limit the traffic going through all interfaces by selectively allowing only some user-selected process to establish outgoing connections and send data (all apps trying to send data will appear in a list).

One of the requirements to this project is that the connection must not be denied, but rather put on hold, so that as soon as the go is given by the user, the process can send its data, as if nothing ever occured.

My question is :
How can I hold a process outgoing network communication, without denying the connection, for quite a long time ?

What happens, for the calling process if I return EJUSTRETURN in the sf_bind_fun function ? 

- Is the socket bind operation put on hold ?

The bind operation is simply not happening. You will need to perform the actual bind operation using the address from the bind(2) call when the sf_connect_out or the sf_listen is being called.

Is there a timeout occurring for the calling process ?

No, there is no timeout on a bind(2) system call.

Filtering on the bind(2) system call may not be the best way to hold / block outgoing connections because most applications don't bother calling bind(2). 

The common pattern is for processes to call connect(2) and let the kernel pick up the source address before connecting. In that case your sf_bind_func function will not be invoked. That means that filtering on the sf_connect_out function makes more sense.

=> if so, will the NKE be notified when the requesting process gives up on the connection attempt ?

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

How long is too long? It depends on the program...

- And more importantly, will the calling process be prevented from trying to open more sockets (kernel resources are limited).

Yes, it's possible.

I am certain some of these questions must seem very bottom-line for experienced NKE developers. So, I would like to thank you for taking the time to read me and for your answers.

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.

Vincent

 _______________________________________________
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

References: 
 >Blocking / Holding data from NKE (From: Jean Suisse <email@hidden>)

  • Prev by Date: Re: ld: warning: using ld_classic
  • Next by Date: Fwd: Blocking / Holding data from NKE
  • Previous by thread: Blocking / Holding data from NKE
  • Next by thread: Fwd: Blocking / Holding data from NKE
  • Index(es):
    • Date
    • Thread