lkml.org 
[lkml]   [2012]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: AF_BUS socket address family
    > What you really don't get is that packet drops and event losses are
    > absolutely fundamental.

    The world is full of "receiver reliable" multicast transport providers
    which provide ordered defined message delivery properties.

    They are reliable in the sense that a message is either queued to the
    other ends or is not queued. They are not reliable in the sense of "we
    wait forever".

    In fact if you look up the stack you'll find a large number of multicast
    messaging systems which do reliable transport built on top of IP. In fact
    Red Hat provides a high level messaging cluster service that does exactly
    this. (as well as dbus which does it on the deskop level) plus a ton of
    stuff on top of that (JGroups etc)

    Everybody at the application level has been using these 'receiver
    reliable' multicast services for years (Websphere MQ, TIBCO, RTPGM,
    OpenPGM, MS-PGM, you name it). There are even accelerators for PGM based
    protocols in things like Cisco routers and Solarflare can do much of it
    on the card for 10Gbit.

    > As long as receivers lack infinite receive queue this will always be
    > the case.
    >
    > Multicast operates in non-reliable transports only so that one stuck
    > or malfunctioning receiver doesn't screw things over for everyone nor
    > unduly brudon the sender.

    All the world is not IP. Dealing with a malfunctioning receiver is
    something dbus already has to deal with. "Unduly burden the sender" is
    you talking out of your underwear. The sender is already implementing
    this property set - in user space. So there can't be any more burdening,
    in fact the point of this is to get rid of excess burdens caused by lack
    of kernel support.

    This is a latency issue not a throughput one so you can't hide it with
    buffers. A few ms shaved off desktop behaviour here and there makes a
    massive difference to perceived responsiveness. Less task switches and
    daemons means a lot less tasks bouncing around processors which means
    less power consumption.

    Alan


    \
     
     \ /
      Last update: 2012-06-30 15:41    [W:4.034 / U:1.492 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site