On Tue, May 28, 2013 at 05:45:06PM +0200, Jason A. Donenfeld wrote: > Oh, I see: > > case HOOK_CONNECT: > m_get_sockaddr(&m, (struct > sockaddr*)&q_connect.local); > m_get_sockaddr(&m, (struct > sockaddr*)&q_connect.remote); > m_get_string(&m, &q_connect.hostname); > m_end(&m); > filter_dispatch_connect(id, qid, &q_connect); > break; > > > So basically, a filter writer has to note the local/remote sockaddr > and connect it up with its qid, store that state information > somewhere, and then re-correlate the qid on the dataline situation? > Blah, that sounds a bit tedious -- I wouldn't enjoy programming for > it.
Well, we won't force you to. > Also -- this exposes local and remote sockaddrs and the connect > hostname, but not much else, such as labels, authentication status, > tls status, etc. Are there plans to introduce a better state > mechanism? Also, as a nitpick, sockaddr is size-less, so the filter > can't know with total certainty which size to cast it back to. The plan is to eventually have something powerful, efficient and easy to use, just as the rest of the daemon. But as gilles said already we have to focus on other tasks at the moment. Eric. -- You received this email because you are subscribed to mailing list: [email protected] To unsubscribe, send mail with subject: [[email protected]] unregister
