Dnia Monday 02 of June 2008, Gerrit Renker napisał:
> | > It was for this part that I looked at netlink. This goes into the
> | > direction of a new API or at least API extensions.
> |
> | We basically need a callback from code that can access struct sock...
> |
> | > (...)
> | > For per-socket statistics there is indeed a need for a notification
> | > mechanism. If a synchronous mechanism is sufficient, then something
> | > like the current CCID-3 getsockopt(DCCP_SOCKOPT_CCID_{RX,TX}_INFO) can
> | > be used.
> |
> | Synchronous mechanism is acceptable but callback (at least as an option)
> | would be way nicer.
>
> I have been looking around for alternatives - there are some
> very good solutions for such aspects in the SCTP subsystem.
>
> They implement the subscription of event notifications on a socket for
> all sorts of events.
>
> A socket option performs this subscription, notifications are then passed
> along with data (I think also without, have not dug deep enough into the
> sources), via recvmsg(). This is the inverse path to qpolicies: the
> ancillary data is passed via cmsg(3) wrappers to the user.
>
> To distinguish events from normal (ancillary) data, SCTP sets the
> flag fields to MSG_NOTIFICATION.
>
> There are two good papers on this (the second one is a bit older):
> http://www.bsdcan.org/2008/schedule/events/91.en.html
> http://lwn.net/2001/features/OLS/pdf/pdf/sctp.pdf
>
> The sources are in net/sctp, the lksctp project is hosted at
> http://sourceforge.net/projects/lksctp
>
> I think that this approach is elegant and has something to offer for
> DCCP as well. What do you think?
>
I also thought about such a solution but I didn't state it because I thought
it is even more hackish than the one below. Mostly because it
interleaves "real data" with events (and there is no logical connection
between the two as opposed to sending scenario). But if it is used in SCTP
then maybe the whole idea is not that bad...
Anyway, I'll have a look at the documents and at the SCTP implementation.
> | Ok, but if we are at hackish ideas what about this one: use dccp_ioctl to
> | wait on a mutex. If an event occurs we release mutex thus allowing
> | dccp_ioctl to finish execution and consequently informing user that
> | something interesting has just happened - what it exactly is would have
> | to be determined by other means.
>
> I am trying to think in terms of how much documentation this would need
> in order to explain to someone how to use it. It seems feasible, but to
> me a bit complicated.
>
The basic idea is the same as above. The difference is that it would overload
ioctl, not recv. But maybe we should use recv. Not because it is in any way
better but just because it is already used that way in SCTP and has a few
documents describing the approach.
--
Regards,
Tomasz Grobelny
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
