| |||||||||||||
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernelKroah-Hartman: AF_BUS, D-Bus, and the Linux kernelPosted Feb 9, 2013 21:44 UTC (Sat) by heijo (guest, #88363)Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
How about the fundamental problem of reliable multicast, i.e. the issue where someone subscribes for multicast messages, but indefinitely delays reading them, requiring an unbounded amount of memory to store them in case it actually decides to read them?
(Log in to post comments)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 9, 2013 22:58 UTC (Sat) by khim (subscriber, #9252) [Link] We are talking about in-kernel multicast support. Just kill the offender - problem solved: you can free the buffer since you know it'll never read these messages. I'm only half-joking here.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 0:07 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
A better solution - just account for these delayed messages using normal Linux RAM accounting.
Then the OOM killer can come out and kill something (hopefully the offender) and one can use something like cgroups to fine-tune the killing priority.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 14:13 UTC (Sun) by renox (subscriber, #23785) [Link]
Exactly my thoughts, this solves nicely the "lazy reader" issue but there is one other potential issue: the buggy/malicious writer which sends a big quantity of (big) messages, it's harder to avoid.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 15:46 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Surely the unruly _writer_ just blocks? Or, if they can't block, they error out when they exceed system policy limits?
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 17:56 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
I think the question here is: "Who pays for the phone call?"
The best way to deal with DBUS flood is to use kernel's RAM accounting. And then there should be a separate decision about who is going to get "billed" for the RAM.
There are various use-cases here. For example, a privileged system process should never be stopped if its client goes dead.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 10, 2013 15:53 UTC (Sun) by butlerm (subscriber, #13312) [Link]
That problem is easily solved by implementing a sender specifiable time limit on message delivery. If a subscriber doesn't read the message within the specified time interval, the message silently expires, or if it has been partially read (assuming you allow partial reads), is truncated. SCTP has something similar called PR-SCTP.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 12, 2013 11:12 UTC (Tue) by wahern (subscriber, #37304) [Link]
PR stands for partially reliable, so you've just solved the problem by redefining "reliable" as "unreliable". (Which I guess is inevitable.) And in any event, if you want to parameterize expiration, on its face that's something you would think would be far preferable to implement in user-land, where it's easy to hack on and change with experimentation, instead of having to invent an interface to last all eternity. Obviously not much of an option for PR-SCTP, but open source software doesn't need to set a protocol in stone as long as the implementing library is free, open, and portable.
Also, PR-SCTP isn't multicast. The problem with reliable multicast is dealing with a single errant process complicating life for everyone else. Do you handle that complexity in kernel or user-land?
I don't really get the need for AF_BUS at all. Why not simply invent some sort of broadcast signaling system, similar to eventfd(2), but where bad processes can't drain the signal queue. Then just use a regular shared memory scheme for transfer. Now you've derived all the benefit without requiring the kernel to implement another idiotic kind of OOM killer in the kernel, and instead it can enforce hard limits and require user-land to cope. User land will be free to make the multicast channel as reliable or unreliable as it wishes.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 12, 2013 21:11 UTC (Tue) by butlerm (subscriber, #13312) [Link]
Unless you have an infinite amount of resources, all reliable multicast systems are partially reliable. The only question is when you resort to the expedient of dropping non-responsive recipients, dropping messages to non-responsive recipients, or blocking indefinitely.
I suspect the DBUS developers did not intend to set up an electronic mail system, but rather intended the service for messages only useful if they are delivered in a bounded time. DBUS doesn't preserve messages across reboots does it?
No sane kernel implementation of reliable multicast would either. It seems pretty obvious that you must either kick out or drop messages to non-responsive recipients, with some appropriate definition of non-responsiveness, or you can't do anything useful. Blocking the sender is not a realistic option.
There is no need to kill any processes - each receiver should have a receive buffer limit, and be sent a control message when one or more messages were dropped because that limit would be exceeded.
|
|||||||||||||